ApacheJMeter吞吐量整形计时器性能很差

Question

[我正在使用ApacheJMeter的吞吐量整形计时器插件来对自适应应用程序进行动态压力测试（当资源需求变化时，应用程序会改变其行为）。

我的配置（附件）如下：

seconds  0 -  4  : ramp up to 1000 requests per second (RPS)
seconds  5 -  14 : 1000 RPS
seconds  15 - 19 : ramp up to 5000 RPS
seconds  20 - 29 : 5000 RPS
seconds  30 - 34 : ramp up to 15000 RPS
seconds  35 - 44 : 15000 RPS
seconds  45 - 49 : ramp down to 5000 RPS
seconds  50 - 59 : 5000 RPS
seconds  60 - 64 : ramp down to 1000 RPS
seconds  65 - 74 : 1000 RPS
seconds  75 - 79 : ramp down to 0 RPS

为了执行测试，我在具有16核（每个3GHz）和32GB RAM的Ubuntu 18 LTS上使用以下命令：

$ jmeter/bin/jmeter -n -t ~/JMeterTests/$1.jmx -l ~/TestResults/$2.jtl

[不幸的是，当我开始测试时，CPU使用率立即飙升至100％，并且请求产生许多错误：

这里肯定是错误的，因为我在该计算机上使用JMeter发送10000 RPS时，甚至没有达到10％的CPU使用率。我不知道出了什么问题-有人可以帮忙吗？

测试文件在附件3中。

非常感谢。

Answer 1

您在Ultimate Thread Group中仅定义了300个线程（虚拟用户）。

这意味着仅当响应时间为20毫秒或更短时，您才能每秒300个用户达到15000个请求。

从您的摘要程序中，我可以看到平均响应时间为55毫秒，最大响应时间为876毫秒，这意味着即使假设被测系统每秒能够处理该数量的请求，这300个用户绝对还不够。

所以建议是：

1. 请务必遵循JMeter Best Practices
2. 迁移到Concurrency Thread Group，如果当前数量不足以达到/维持所需的吞吐量，则可以启动额外的线程，可以通过Feedback Function与吞吐量整形计时器连接，请查看Using JMeter’s Throughput Shaping Timer Plugin文章以了解更多详细信息如果需要。
3. 您在这台机器上使用JMeter并每秒进行different 10k请求的事实并不一定意味着您可以在当前测试和将来的测试中每秒产生10k请求，这只是一个问题。 JMeter配置，操作系统配置，测试计划详细信息，等等。