3

我使用“jp@gc - Stepping Thread Group”为 500VU 运行了性能测试。我注意到，从 200VU-500VU 负载开始，直到运行结束 25 分钟，命中/秒始终为 20-25，误差为 0.04%。

我知道我可以通过使用限制 RPS 和恒定吞吐量计时器来控制命中/秒，但我没有应用或启用。

我的问题是
1. 运行好还是坏？2. 500VU 负载的 hits/sec 应该如何？3. Blazemeter 引擎是否根据其效率确定命中/秒？

4

2 回答 2

1
  1. 确保正确配置步进线程组
  2. 如果 200 和 500 VU 的吞吐量相同，那就不好了。500 VU 的理想系统吞吐量应高出 2.5 倍。如果您不确定是您的应用程序还是 BlazeMeter 引擎应受责备，您可以在Engine Health负载测试报告选项卡上的测试时间范围内检查 BlazeMeter 的实例运行状况。

  3. 据我所知，BlazeMeter 依赖于 JMeter 吞吐量计算算法。根据JMeter 词汇表

    吞吐量计算为请求/时间单位。时间从第一个样本开始到最后一个样本结束计算。这包括样本之间的任何间隔，因为它应该代表服务器上的负载。公式为：Throughput = (number of requests) / (total time).

于 2016-10-07T15:11:29.953 回答
1

命中并不总是吞吐量的最佳衡量标准。原因如下：通过服务器上与缓存项管理相关的被测应用程序的设置，可以极大地改变命中数。一个例子：假设你有一个非常复杂的页面，页面上有 100 个对象。只有顶级页面本质上是动态的，其余项目作为页面组件，例如图像、样式表、字体、javascript 文件等......在没有缓存设置的模型中，您会发现必须请求所有 100 个元素，每个元素都会在报告和服务器统计信息中产生“命中”。这些将显示在您的点击数/秒模型中。

现在优化缓存设置，其中一些信息在客户端缓存很长一段时间（标志图像和字体为一年），一些为一周的构建间隔期限（驻留在 CDN 或客户端），只有动态顶部级别 HTML 保持未缓存。在此模型中，除了在部署构建后立即为大多数用户播种 CDN 的时间段外，在服务器上仅生成一次命中。有时，您将有一个新的 CDN 节点与不同地理区域的用户一起使用，但在第一个用户播种缓存之后，其余的将从 CDN 提取，然后缓存在客户端。在这种情况下，您的每秒有效点击量在 CDN 和 Origin 服务器上都会大幅下降，尤其是在您有回头客的情况下。

深思熟虑。

于 2016-10-07T15:31:27.790 回答