JMeter理解提升

Fra*_*ith 42 testing performance jmeter

这是我的测试计划线程属性的配置:

Number of Threads (users): 100
Ramp-up Period (in seconds): 10
Loop Count : Forever
Delay thread creation until needed: No
Scheduler: No
Run Code Online (Sandbox Code Playgroud)

我将测试过夜,总持续时间为14小时7分钟(约50820秒).加载jtl文件后,摘要报告中显示的样本数为1050975.我尝试计算,但我无法理解它是如何产生这么多样本的.

如果Ramp-up Period是JMeter创建每次迭代的线程数所花费的时间,并且如果测试的持续时间是50820秒,那么我应该只有508200个样本(50820/10*100).我不知道循环计数是如何或是否影响这一点.

rsp*_*rsp 64

线程组中的加速是JMeter开始线程总数所需的时间.在您的情况下,这意味着每隔0.1秒,一个新线程在10秒后开始提供100个正在运行的线程.这100个线程背靠背地执行测试迭代,因此在增加之后,100个线程在测试期间连续运行.

  • 对于测试自动缩放很有用 - 例如对于*大多数*网站,您不太可能立即从0到100个并发用户.并发用户更有可能逐渐增加(从而使自动缩放系统有时间响应).Ramp-up可以测试此场景. (12认同)
  • 为什么我们需要加速?我们不能马上开始吗?我的意思是人们选择有时间崛起的原因是什么? (2认同)

Adn*_*nan 21

Ramp-up Period - 所有请求启动的时间范围(以秒为单位).Number of Threads输入中指定的所有线程都将在其中开始Ramp-up period.

例如:

100个线程和100秒加速:每秒JMeter将启动1个线程,直到所有线程在100秒启动时启动.

100个线程和50秒加速:每秒启动2个线程.

100个线程和200秒斜坡上升:2秒,1个线程开始.

现在,

样本或请求生成与Thread生成的概念不同.在这种情况下,100个线程在10秒内启动.这里的关键因素是吞吐量.根据JMeter词汇表:

吞吐量计算为请求/时间单位.时间从第一个样品的开始到最后一个样品的结束计算.这包括样本之间的任何间隔,因为它应该代表服务器上的负载.

公式为:吞吐量=(请求数)/(总时间).

这里是执行样本或请求的数量,1050975测试持续时间是50820秒.因此,这与吞吐量有关.输出1050975请求50820s意味着整个测试中的平均吞吐量是近似值20.5/s.

要控制Throughput或者Transactions per second有非常方便的JMeter插件,称为Constant Throughput Timer.

恒定吞吐量计时器引入可变暂停,计算使总吞吐量(以每分钟样本数)尽可能接近给定数字.当然,如果服务器无法处理它,或者如果其他计时器或耗时的测试元素阻止吞吐量,则吞吐量会降低.


Jme*_*est 12

加速期告诉JMeter需要多长时间才能"提升"到完整数量的线程.

@Little Chicken Understanding 1是正确的.

如果使用10个线程,并且加速时间为10秒,则JMeter将花费10秒钟来启动并运行所有10个线程.

在前一个线程开始后,每个线程将开始1秒.


小智 6

例如

  1. 1000 个目标线程和 1000 秒的加速:JMeter 将每秒添加一个用户
  2. 1000 个目标线程和 100 秒的加速:JMeter 将每秒增加 10 个用户
  3. 1000 个目标线程,50 秒启动:JMeter 将每秒增加 20 个用户