K6 html压力测试报告中参数详解以及常见问题解析

好多同学在使用k6时也许认为最难的是编写javascript测试脚本，其实对于任何压测工具的使用，编写好脚本只是最最最基本的要求而已。压测的重点是通过测试报告能够分析出性能问题并提供解决方案，而这就需要我们大家理解报告中参数的准确含义并通过参数的显示数据能够进行问题定位！在这里我列举了k6报告中常用的参数含义以及一些典型问题的定位思路，希望能够帮到大家！

一、HTTP 请求各阶段耗时指标​​

1. ​​http_req_duration​​

• ​​含义​​：​​HTTP 请求总耗时​​，从请求开始到完整接收响应的时间（包含 http_req_sending、http_req_waiting、http_req_receiving）。
• ​​计算公式​​：http_req_sending + http_req_waiting + http_req_receiving。
• ​​分析重点​​：
  • ​​系统整体性能​​：若该值过高，表明请求处理链路存在瓶颈（如网络延迟、服务器处理慢）。
  • ​​百分位数（p90/p95）​​：反映高延迟请求的分布（例如 p(90)=500ms 表示 90% 请求耗时 ≤500ms）。

2. ​​http_req_waiting​​

• ​​含义​​：​​服务器处理时间​​（TTFB, Time to First Byte），即从发送请求到接收到服务器第一个字节的耗时。
• ​​关键场景​​：
  • 若该值过高 → 服务器处理能力不足（如 CPU 过载、数据库查询慢）。
  • 示例：avg=150ms 表示平均等待服务器响应 150ms。

3. ​​http_req_connecting​​

• ​​含义​​：​​TCP 连接建立时间​​，从发起请求到完成 TCP 握手的时间。
• ​​问题定位​​：
  • 高值 → DNS 解析慢或网络路由问题（如跨地域请求）。
  • 示例：max=100ms 表示最慢一次 TCP 连接耗时 100ms。

4. ​​http_req_tls_handshaking​​

• ​​含义​​：​​TLS/SSL 握手时间​​，仅在使用 HTTPS 时出现。
• ​​优化方向​​：
  • 高值 → 服务器证书配置问题（如密钥过长、未启用会话复用）。
  • 示例：avg=50ms 表示平均 TLS 握手耗时 50ms。

5. ​​http_req_sending​​

• ​​含义​​：​​请求发送时间​​，从开始发送请求头到完成发送请求体的耗时。
• ​​影响因素​​：
  • 请求体大小（如上传大文件时该值较高）。
  • 通常较低（毫秒级），若异常高 → 客户端网络问题。

6. ​​http_req_receiving​​

• ​​含义​​：​​响应接收时间​​，从接收第一个响应字节到完整接收响应体的耗时。
• ​​关联因素​​：
  • 响应体大小（如下载大文件时该值显著升高）。
  • 示例：avg=200ms 表示平均接收数据耗时 200ms。

​​二、请求阻塞与迭代整体耗时​​

1. ​​http_req_blocked​​

• ​​含义​​：​​请求阻塞时间​​，包括 DNS 查询、TCP 连接等待、TLS 握手前的等待。
• ​​常见原因​​：
  • 高值 → 客户端资源不足（如线程池耗尽）或网络防火墙拦截。
  • 示例：p(95)=300ms 表示 95% 的请求阻塞时间 ≤300ms。

2. ​​iteration_duration​​

• ​​含义​​：​​单次迭代总耗时​​，包含脚本逻辑执行（如多个 HTTP 请求）和 sleep() 等待时间。
• ​​与 http_req_duration 区别​​：
  • 一个迭代可能包含多个 HTTP 请求（如登录→查询→登出）。
  • 示例：avg=1.2s 表示用户完整操作链路的平均耗时。

​三、指标关联分析与性能问题诊断​​

​​指标组合​​	​​暗示的性能问题​​	​​优化建议​​
http_req_waiting ↑ + http_req_duration ↑	​​服务器处理瓶颈​​	优化代码逻辑、扩容服务器资源
http_req_connecting ↑ + http_req_tls_handshaking ↑	​​网络或加密层问题​​	检查 DNS、启用 HTTP/2、优化 TLS 配置
http_req_blocked ↑	​​客户端资源竞争​​	增加测试机资源、减少并发 VU 数
iteration_duration >> Σ http_req_duration	​​脚本逻辑或等待时间过长​​	减少 sleep()、合并请求

四、实际报告数据解读示例​​

http_req_duration........: avg=250ms min=100ms max=400ms p(90)=350ms http_req_waiting.........: avg=200ms min=90ms max=380ms http_req_connecting......: avg=10ms min=0s max=50ms http_req_tls_handshaking.: avg=30ms min=0s max=100ms http_req_blocked..........: avg=40ms min=1μs max=150ms iteration_duration........: avg=1.3s min=1.1s max=2.0s

• ​​主要问题​​：
  • http_req_waiting（200ms）占 http_req_duration（250ms）的 80% → ​​服务器响应慢​​。
  • iteration_duration（1.3s）显著高于单个请求耗时 → 脚本存在非请求耗时（如 sleep() 或计算逻辑）。
• ​​优化方向​​：
  1. 检查服务器 CPU/数据库性能；
  2. 减少迭代内等待时间。

总结​​

• ​​请求阶段指标​​（如 http_req_waiting、http_req_connecting）用于定位网络或服务器层问题。
• ​​总耗时指标​​（如 http_req_duration、iteration_duration）反映端到端性能体验。
• ​​百分位数分析​​（p90/p95）比平均值更能暴露高延迟场景。
  建议结合 Grafana 等可视化工具实时监控趋势，参考官方文档：k6 Metrics