jmeter - 无法通过运行 Jmeter 脚本来实现预期的吞吐量，因为预期的吞吐量更多但变得非常少

无法通过运行 Jmeter 脚本来实现预期的吞吐量，因为预期的吞吐量更多但变得非常少。

通过以每秒 1000 个请求（业务 SLA）为目标运行 Jmeter 脚本，因此使用了“恒定吞吐量计时器”或“吞吐量整形计时器”，如下面的查询中所建议的那样。

恒定吞吐量计时器：目标 - 60,000/分钟（60 秒） - 所有活动线程，线程（用户） - 200，加速 - 1 秒，持续时间：1 小时。或用户 - 2000 或尝试使用 10,000 个用户。

结果：执行结束时吞吐量显示为 50/秒，平均响应时间为 50 秒。

在这两种情况下，“吞吐量”都在 50 秒左右，平均响应时间在 30 秒左右。

当查看服务器指标时 - CPU 和内存消耗非常少，只有 3% 左右。

因此，预期的“吞吐量”很高，因为服务器资源使用不多，如果“吞吐量”很低，并且不断地用 Forever 发送请求以查看是否可以获得 500 个响应代码错误，它只会增加平均响应时间并降低吞吐量但不会收到 500 个响应代码错误。

在获得套接字异常一段时间后，Jmeter 正在运行但在服务器端没有出现故障的连接重置问题。

在这里经历了类似的查询，但无法理解何时服务器资源使用不多，并且根据服务器平台 SLA，它支持 1000 RPS 但无法通过 Jmeter 实现。

根据 CTT 计算：RPS * / 1000

1000 * 50000/1000 = 50000（是否应该提供高达 50K 的线程？但是我们的 SLA 仅适用于 200 个用户）。

标签： jmeter

可能是您的服务器响应速度不够快。低 CPU 和内存消耗意味着服务器有足够的空间，但是应用程序服务器配置可能不正确，因此服务器没有充分利用其硬件资源。另一个原因可能是应用程序代码中使用的算法效率低下，您可以使用分析器工具查看执行负载时发生的情况
JMeter 可能无法足够快地发送请求。确保运行 JMeter 的机器没有过载，以非 GUI 模式运行 JMeter 测试，并且通常遵循JMeter 最佳实践。如果一台机器无法创建所需的负载，您也可以尝试在分布式模式下运行 JMeter。