我使用“jp@gc - Stepping Thread Group”对 500VU 进行了性能测试。我注意到，从 200VU-500VU 负载开始，在 25 分钟内，直到运行结束，点击次数/秒始终为 20-25，误差为 0.04%。
我知道我可以通过使用限制 RPS 和恒定吞吐量计时器来控制命中/秒，但我没有应用或启用。
我的问题是
1. 跑步是好是坏？
2. 500VU 负载的 hits/sec 应该如何？
3. Blazemeter 引擎是否根据其效率确定命中/秒？
【问题讨论】：
标签： performance jmeter performance-testing load-testing blazemeter
Engine Health 选项卡上的测试时间范围内检查 BlazeMeter 的实例运行状况。 据我所知，BlazeMeter 依赖于 JMeter 吞吐量计算算法。根据JMeter glossary
吞吐量以请求/单位时间计算。时间从第一个样本开始到最后一个样本结束计算。这包括样本之间的任何间隔，因为它应该代表服务器上的负载。 公式为：
Throughput = (number of requests) / (total time).
【讨论】：
点击并不总是吞吐量的最佳衡量标准。原因如下：通过服务器上与缓存项管理相关的被测应用程序的设置，命中数可能会发生巨大变化。一个例子：假设你有一个非常复杂的页面，页面上有 100 个对象。只有顶级页面在本质上是动态的，其余项目作为页面组件，例如图像、样式表、字体、javascript 文件等......在没有缓存设置的模型中，您会发现必须请求所有 100 个元素，每个元素都会在报告和服务器统计信息中产生“命中”。这些将显示在您的 hits/second 模型中。
现在优化缓存设置，其中一些信息在客户端缓存很长一段时间（徽标图像和字体为一年），一些为一周的构建间隔期限（驻留在 CDN 或客户端中）并且仅动态顶级 HTML 保持未缓存。在此模型中，除了在部署构建后立即为大多数用户播种 CDN 的时间段外，在服务器上仅生成一次命中。有时，您会有一个新的 CDN 节点与不同地理区域的用户一起使用，但在第一个用户播种缓存之后，其余的将从 CDN 中提取，然后缓存在客户端。在这种情况下，您的每秒有效点击量在 CDN 和 Origin 服务器上都会大幅下降，尤其是在您有回访用户的情况下。
值得深思。
【讨论】：