通过运行Jmeter脚本无法实现预期的吞吐量，因为预期的吞吐量更高，但获得的吞吐量却很少

Question

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

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

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

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

Jmeter: Scenario to test 5 users with ramp up 1 hour to trigger 10 thousand requests

unable to increase average throughput in jmeter

1. 通量整形计时器：反映了如上所述的设置。

在这两种情况下，“吞吐率”均约为50 /秒，平均响应约为30秒。

查看服务器指标时-CPU和内存消耗仅占3％左右。

因此，由于服务器资源使用不多，因此预期的“吞吐量”很高，如果“吞吐量”很低，并与Forever连续发送请求以查看是否会收到500个响应代码错误，那么这只会增加平均响应时间并减少吞吐量，但未收到500个响应代码错误。

一段时间后出现套接字异常，连接重置会在运行Jmeter的地方出现问题，但在服务器端看不到任何故障。

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

根据CTT计算：RPS * / 1000

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

Answer 1

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