用于 API 性能测试的摘要报告中的 AWS cloudwatch“延迟”指标和 jmeter“平均”指标

Question

在使用 JMeter 对 AWS 中 ELB 上的 API 进行负载/性能测试时，我看到了
AWS 云观察 Latency metric = 10 ms（似乎不错）和 JMeter 的摘要报告中 Average metric = 3000 ms（似乎很糟糕）。

API 返回 1MB 的 JSON 数据，但我不明白为什么会有这么多数字差异，这个 api 性能可以接受吗？ 如果 SLA 说有 100 毫秒的 API 响应时间。

Answer 1

您正在研究不同的指标：

• 延迟：JMeter measures the latency from just before sending the request to just after the first response has been received.
• 经过时间：JMeter 测量从发送请求之前到收到最后一个响应之后所经过的时间。

因此延迟包含在响应时间中，即所谓的Time To First Byte 和经过时间是Time to Last Byte。我的期望是您应该坚持 JMeter 报告的内容，这样您就不会与来自不同来源的指标混淆，JMeter 至少是开源的，因此您对如何计算指标有信心。

如果 3 秒的响应时间太长，您可以开始调查原因，可能是：

1. 您的 API 服务器只是过载了，请使用上述 Amazon CloudWatch 或 JMeter PerfMon Plugin 检查 CPU、RAM、网络、磁盘使用情况
2. 您的应用程序配置可能还没有为高负载做好准备。大多数 Web/应用程序/数据库服务器默认值仅适用于应用程序开发和调试（同样适用于 JMeter），因此您很可能需要调整基础架构。
3. 您的应用程序使用非最优算法。使用profiler tools 检查它在哪里花费时间、什么是“最重”的方法、数据库调用持续多长时间等。
4. 此外，如果您的应用程序位于 ELB 之后，JMeter 可以缓存其中一个入口节点的 IP 地址，并且您的所有请求将只针对一台主机。为避免这种情况，请将DNS Cache Manager 添加到您的测试计划中。

参考资料：

• JMeter Glossary
• JMeter Best Practices
• The DNS Cache Manager: The Right Way To Test Load Balanced Apps