我使用JMeter在Kubernetes中进行基于HTTP的性能测试。每个JMeter示例都有超过80 GB的内存。
一切正常，但是每隔10分钟，请求率就会从每秒约101个请求下降到每秒约95个请求：
summary + 3116 in 00:00:30 = 103.9/s Avg: 20 Min: 0 Max: 293 Err: 0 (0.00%) Active: 20 Started: 20 Finished: 0
summary = 58661 in 00:10:13 = 95.6/s Avg: 29 Min: 0 Max: 2625 Err: 23 (0.04%)
summary + 2883 in 00:00:30 = 96.0/s Avg: 24 Min: 0 Max: 2330 Err: 0 (0.00%) Active: 20 Started: 20 Finished: 0
summary = 61544 in 00:10:43 = 95.6/s Avg: 28 Min: 0 Max: 2625 Err: 23 (0.04%)
summary + 3097 in 00:00:30 = 103.2/s Avg: 20 Min: 0 Max: 319 Err: 0 (0.00%) Active: 20 Started: 20 Finished: 0我不知道为什么请求率在下降。我还测量了JMeter和SUT之间的延迟，但是我看不到任何增加的延迟或任何东西。而且，JMeter和SUT之间的HTTP响应代码总是200。内存使用量是~ 30 GB，所以每个示例都有足够的内存。每个示例的CPU使用量是~80%。
有什么想法吗？
2条答案
按热度按时间sqyvllje1#
如果不查看Kubernetes、JMeter、应用等的资源消耗情况，很难说出问题出在哪里，因此您需要设置对包括JMeter JVM metrics在内的所有内容的适当监控。如果您没有任何监控工具链，可以考虑使用JMeter PerfMon plugin。
如果您需要猜测，可能是由于Garbage Collection，如Concurrent, High Throughput Performance Testing with JMeter中所述
zpqajqem2#
你检查日志了吗？线程数不足可能是问题所在。我认为你正在尝试实现恒定的RPS。如果是这样，我建议ThroughputShapingTimer插件与ConcurrencyThreadGroup一起使用。ConcurrencyThreadGroup会为这种情况动态分配新线程。我发送的文档解释了如何使用它。
另一方面，30 GB内存支持100 RPS太疯狂了。如果你不依赖Jmeter，我强烈建议你使用ddosify。你可能会使用3- 4 MB内存来支持100 RPS。下面是一个支持100 RPS的简单命令：