建立基线

这个实验真的在VM上帮忙

这个盒子不是帕德，而是KubeVirt发布的虚拟机。Linux内核是单独运行，systemd实际上管理服务，docker不是模仿真的是dock engine。docker run放置在的容器实际上是过程成为docker exec道docker logs也照样运行。

以前这个实验是在派达里进行的。因为是完全剥夺了内核权限的盒子。托运容器的阶段被堵住了，所以直接解压缩了图像存档。通过看学习了。现在不需要绕道了。

有两件事需要知道。

第一次启动需要不到1分钟。 VM启动并安装docker 因为这个。比脚踏练习（一般40秒）慢。
没有浏览器预览。通过VM进入的连接是评分端口只有一个打开。如果启动了Web服务器，在VM中curl请确认。

目标

在实际的集装箱上挂载负载，抽取RPS·p50·p95·p99·错误率，重复三次，包括波动幅度的可重现的基准线/root/lt1/制作成。

为什么重要

如果没有基准线，“变慢”的话是欣赏。而且基准线仅凭数字是不够的。因为如果没有同时性是多少，发送了多少个，什么时候发送，就无法在下个月进行比较。选择指标的标准也很明确。在10,000个请求中，9,900个是50ms，100个是3,000ms时，平均值是79.5ms，实际上没有一个请求收到79.5ms的响应。而且即使慢的100个翻倍变差，平均值也只会从79.5ms → 109.5ms移动。所以不要只用平均值来判断，而是一起看p50·p95·p99，最后再重新测量三次，只称比波动幅度更大的差异为“变化”。

读取附加工具输出的方法

这个图像中hey里面有。输出有三个步骤，之后的步骤都是从这些步骤中读取值。

Summary:节的Requests/sec:行→处理量。行的最后一个字段是值。
Summary:节的Average:行→平均延迟（秒）。第二个字段是值。
Latency distribution:节的95% in 0.0086 secs同一行→氛围水。第三个字段是值。
Status code distribution:节的[200] 2000 responses同一行→按状态代码的数量。第二个字段是数量。

请完整地保存整个输出。评分仪会将大家填写的值与这个原件再次进行比较。

阶段

首先mkdir -p /root/lt1请做好。

启动负载对象容器。名称准确为lt-web，端口是主机127.0.0.1:8085→集装箱80 然后，curl -s -o /dev/null -w '%{http_code}' http://127.0.0.1:8085/必须加200。\n对象必须在响应时间内有尾巴。大多数情况下，用Python制作快速和每十二次左右一次慢的服务器。python:3.12-alpine请放入容器中。用nginx返回静态文件的话，一个只需要1ms，平均值和p95的值就相同了，6级就没有理由用了。
烟雾执行结果/root/lt1/smoke.txt存储在。总回复必须达到50件以上，Requests/sec·Latency distribution·Status code distribution三个节必须都放在文件里。
将热身和本测量分开。/root/lt1/warmup.txt(热身)和/root/lt1/run1.txt分别保存(本测量)，run1.txt的总响应应为200件以上。
/root/lt1/metrics.json 写五个字段：rps，p50，p95，p99，error_rate. 前面的四个值是run1.txt中读取的值原样(秒单位)，error_rate不是2xx，而是响应数÷总响应数的比例(0~1)。
/root/lt1/errors.txt 在上面写三行：non2xx=（净水），total=（净水），rate=（百分比，小数点后第二位）。前两个值在状态代码分布中必须与感应值完全相同。
/root/lt1/why.md 在上面写三行和说明：average_s=(run1.txt的Average)，p95_s=(run1.txt的95%氛围水),ratio=(p95 ÷ 平均，小数点后第二位)。然后只看平均数，说明一下错过了什么，请包括“平均”这个词在文中说明。
在同样的条件下再测量两次/root/lt1/run2.txt，/root/lt1/run3.txt制作，/root/lt1/runs.csv整理如下。格式为第一行标题run,rps,p95，接着数据行正好3个(1,<rps>,<p95>形状），最后spread=排队。spread是(最大RPS − 最小RPS) ÷ 最小RPS × 100，小数第一位。
/root/lt1/baseline.json 在上面写六个字段：rps，p95，error_rate，concurrency，requests，measured_at.rps必须是3次测量的中位数(中间值)，error_rate必须为0.01以下（出现错误的状态的数字不能成为基准线）。

参考

执行示例：hey -n 100 -c 2 http://127.0.0.1:8085/ > /root/lt1/smoke.txt 2>&1.-n银总请求数，-c是同时性。
取值：grep -i 'Requests/sec' run1.txt | awk '{print $NF}'，grep '95% in' run1.txt | awk '{print $3}'，grep 'Average:' run1.txt | awk '{print $2}'.
状态代码总和是awk '/Status code distribution/{f=1;next} f && /responses/ {gsub(/[][]/," "); t+=$2} END{print t}' run1.txt可以算作罗。
中位数是cut -d, -f2 runs.csv | sort -g这是后面的中间值。
常见的错误1：runs.csv用数字开始使用标题。数据行超过3个，失败。
常见的错误2：四舍五入后适当写下价格。评分仪会在原始输出中重新计算，确认是否在5%以内。

放置负载对象集装箱

启动负载对象容器。名称准确为lt-web，端口是主机127.0.0.1:8085→集装箱80 然后，curl -s -o /dev/null -w '%{http_code}' http://127.0.0.1:8085/必须加200。\n对象必须在响应时间内有尾巴。大多数情况下，用Python制作快速和每十二次左右一次慢的服务器。python:3.12-alpine请放入容器中。用nginx返回静态文件的话，一个只需要1ms，平均值和p95的值就相同了，6级就没有理由用了。

名称必须准确为lt-web，将主机127.0.0.1的8085端口连接到容器80。如果主机端小于1024，就无法绑定，所以使用高端口，容器内部是root，所以可以直接使用80。目标不是静态文件服务器，而是响应时间有尾巴的服务器——这样才能用自己的测量值看到第6步中平均值和p95的分歧。

通过烟雾运行确认工具输出

烟雾执行结果/root/lt1/smoke.txt存储在。总回复必须达到50件以上，Requests/sec·Latency distribution·Status code distribution三个节必须都放在文件里。

结果全部保存到/root/lt1/smoke.txt中。要保留总结、延迟分布、状态代码分布这三部分，所以重定向时不能只剪掉一部分。请发送至少50件以上。

热身和本测量分离

将热身和本测量分开。/root/lt1/warmup.txt(热身)和/root/lt1/run1.txt分别保存(本测量)，run1.txt的总响应应为200件以上。

单独创建warmup.txt和run1.txt。第一个请求测量的是没有缓存和连接的状态，因此如果混合到本测量中，分布会受到污染。本测量必须有200个以上才能看到分布。

将5个核心指标整理成JSON格式

/root/lt1/metrics.json 写五个字段：rps，p50，p95，p99，error_rate. 前面的四个值是run1.txt中读取的值原样(秒单位)，error_rate不是2xx，而是响应数÷总响应数的比例(0~1)。

/root/lt1/metrics.json的值必须是从run1.txt中直接读取的值。编造的话会在与原始值对比的过程中花费时间。错误率为比例（0~1），在状态代码分布中计算不为2xx的数量。

用手计算错误率

/root/lt1/errors.txt 在上面写三行：non2xx=（净水），total=（净水），rate=（百分比，小数点后第二位）。前两个值在状态代码分布中必须与感应值完全相同。

在/root/lt1/errors.txt中写入non2xx / total / rate三行。前面的两个值必须精确地与整数相匹配，rate是百分比。将状态代码分布分段的个数全部相加就是total。

平均值和p95的排序比较

/root/lt1/why.md 在上面写三行和说明：average_s=(run1.txt的Average)，p95_s=(run1.txt的95%氛围水),ratio=(p95 ÷ 平均，小数点后第二位)。然后只看平均数，说明一下错过了什么，请包括“平均”这个词在文中说明。

在/root/lt1/why.md中写上average_s / p95_s / ratio三行和为什么缺少平均值的说明。ratio是p95除以平均值的值。请从run1.txt中读取值。

3次重复测量和波动幅度

在同样的条件下再测量两次/root/lt1/run2.txt，/root/lt1/run3.txt制作，/root/lt1/runs.csv整理如下。格式为第一行标题run,rps,p95，接着数据行正好3个(1,<rps>,<p95>形状），最后spread=排队。spread是(最大RPS − 最小RPS) ÷ 最小RPS × 100，小数第一位。

在同样的条件下，再制作run2.txt、run3.txt，并整理到runs.csv中。波动幅度是最大值和最小值之间的差值除以最小值的百分比。小于这个值的差值不能称为改善。

确定基准线

/root/lt1/baseline.json 在上面写六个字段：rps，p95，error_rate，concurrency，requests，measured_at.rps必须是3次测量的中位数(中间值)，error_rate必须为0.01以下（出现错误的状态的数字不能成为基准线）。

/root/lt1/baseline.json 不仅要放入数字，还要一起放入测量条件，以便以后进行比较。代表值是3次中中间值，出现错误的状态的数字不能作为基准。