吞吐量值是否与JMeter中请求的响应时间相关？

Question

我得到了以下结果，即使我增加了线程数，吞吐量也没有变化。

场景＃1：

线程数：10

加速期：60

吞吐量：5.8 / s

平均值：4025

方案＃2：

线程数：20

加速期：60

吞吐量：7.8 / s

平均值：5098

场景＃3：

线程数：40

加速期：60

吞吐量：6.8 / s

平均：4098

我的JMeter文件由一个包含单个GET的ThreadGroup组成。

当我执行一个响应时间更快（小于300毫秒）的endpoit请求时，我可以实现每秒超过50个请求的吞吐量。

你能看到这个瓶颈吗？

响应时间和吞吐量之间是否存在关联？

Answer 1

在理想情况下，如果以2倍的比例增加线程数 - 吞吐量应该增加相同的因子。

实际上＆＃34;理想＆＃34;场景难以实现，因此它看起来像是您应用程序中的瓶颈。识别瓶颈的过程通常如下：

• 修改测试配置以增加负载逐渐，以便从1个虚拟用户开始，并在5分钟内将负载增加到100个虚拟用户
• 运行测试并查看Active Threads Over Time，Response Times Over Time和Server Hits Per Second个侦听器。通过这种方式，您可以将不断增加的负载与增加的响应时间相关联，并确定性能开始降低的点。有关详细信息，请参阅What is the Relationship Between Users and Hits Per Second?

• 一旦你弄清楚saturation point是什么，你需要知道阻止你的应用程序提供更多请求的原因，原因可能是：

  • 应用程序只缺少资源（CPU，RAM，网络，磁盘等），请务必监控上述资源，这可以使用JMeter PerfMon Plugin
  来完成
  • 基础架构配置不适合高负载（即应用程序或数据库线程池设置不正确）
  • 问题在于您的应用程序代码（低效算法，大型对象，慢速数据库查询）。可以使用profiler tool
  获取这些项目
  • 还要确保您关注JMeter Best Practices，因为JMeter可能无法快速发送请求，因为JMeter负载生成器端资源不足或JMeter配置不正确（太低）堆，在GUI模式下运行测试，使用监听器等）

Answer 2

JMeter user manual状态很简单：

  

吞吐量=（请求数量）/（总时间）

现在假设您的测试包含仅一个GET，那么吞吐量将关联您的请求的平均响应时间。

通知Ramp-up period：60将开始创建超过1分钟的线程，因此它将增加执行的总时间，您可以尝试将其减少到10或等于线程数。

但是您可能有其他可能影响总时间的采样器/控制器/组件。

同样在您的情况下，特别是在场景3中，可能有些请求失败，那么您不会计算成功交易的吞吐量。