ApacheJMeter吞吐量成形计时器性能非常差

我正在使用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

为了执行测试，我在Ubuntu18LTS上使用以下命令，每个3GHz和32GB RAM有16个内核：

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

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

这里肯定出了点问题，因为我使用JMeter时，这台机器发送10000 rpm，甚至没有达到10%的CPU使用率。我想不出哪里出了问题，有人能帮忙吗

测试文件在附件中

---

非常感谢。

您在终极线程组中只定义了300个线程虚拟用户

这意味着只有在响应时间为20毫秒或更短的情况下，您才能在300个用户的情况下达到每秒15000个请求

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

因此，建议如下：

一定要跟上 迁移到可以启动额外线程的位置，如果当前数量不足以达到/保持所需的吞吐量，它可以通过连接吞吐量成形计时器，如果需要，请查看文章以了解更多详细信息。 您从这台机器上使用JMeter，并且在不同的测试中每秒有10k个请求，这并不一定意味着您将能够在当前测试和将来的测试中每秒生成10k个请求，这是JMeter配置、操作系统配置、测试计划细节等的问题。 正如本文所指出的，通过在linux配置中更改以下参数可以解决此问题：

a使用以下命令增加了本地端口范围：

echo 1024 65000 > /proc/sys/net/ipv4/ip_local_port_range

b按如下方式重新使用插座：

sudo sysctl -w net.ipv4.tcp_tw_reuse=1

注意，应考虑Dmitri T.给出的上述提示。将并发线程组与反馈功能结合使用有利于整个测试计划。 接下来，对配置所做的更改对于生产系统来说可能不健康。关于那件事，我不能发表任何有根据的声明。 最后，请注意，您必须在分布式测试环境中的所有测试服务器中应用配置更改

编辑：

---

另外请注意，配置后用户的最大值仍然是有限的，仅比之前高。

谢谢您的回复。我迁移到了带有反馈功能的并发线程组，它似乎按预期工作。线程根据需要动态分配。不幸的是，我的问题仍然存在。为了检查，如果配置的RPS太高，我在每个段中将它们减少90%。现在，我的测试服务器的CPU使用率没有达到100%，但是，尽管如此，测试还是产生了26,7%的错误。经过测试的基础架构可以处理更多的负载，并且在较小的测试过程中只报告5%到10%的CPU使用率。知道为什么测试会产生这么多错误吗？有趣的是：看看这个。它显示了测试计划的3次执行，每次错误都发生在同一地点。错误发生在测试计划减少服务器负载时。有什么想法吗？实际上错误总是如下：非HTTP响应代码：java.net.NoRouteToHostException/Non-HTTP响应消息：无法分配请求的地址不可用我认为这与此处的网络配置有关。这可能吗？