性能测试的结果统计时我们一定会关注TPS,TPS代表的是每秒事务数,每个事务对应的是我们的请求。虽然JMeter能够帮我们把每个请求统计成一个事务,
但有时候我们希望把多个操作统计成一个事务,JMeter也考虑到了这种需求,我们可以用个逻辑控制器中的事务控制器来完成。
添加路径:【添加/逻辑控制器/事务控制器】
勾选Include duration of timer and pre-post processors in generated sample:是否包括定时器、预处理和后期处理延迟的时间。一般不建议选择,因为选择会把一些额外时间算入总时间。
集合点:
让所有请求在不满足条件的时候处于等待状态,Jmeter中可以通过同步定时器 Synchronizing Timer 来完成。
Number of Simulated Users to Group by:按组分组的模拟用户数;
timeout in milliseconds:Timout的意思是等待请求多久后,不管线程数有没有到达设置的并发数量都开始运行测试。
场景设计一:
线程数设置为6,集合点为3,超时为0,点击运行,用户将会分成了2组进行并发,每次是3个用户;
场景设计二:
线程数设置为6,集合点为8,超时为0,点击运行,需要手动stop。原因:不够并发数且超时为0;
场景设计三:
线程数设置6,集合点设置为4,超时为0,点击运行,发现只有4个请求,然后一直都没有停止,需要手动stop。原因:第一组够集合点,一起并发,第二组只有2个,不够集合点。
场景设计四:
线程数设置6,集合点设置为6,超时为0,点击运行,有6个请求。分1组执行。
场景设计五:
线程数设置6,集合点设置为4,超时为5000,点击运行,先有4个请求,为第一组,5秒后,出现后2个请求,为第二组,共6个;
结论:
Timeout in milliseconds: 如果设置为0,Timer将会等待线程数达到了"Number of Simultaneous Users to Group"中设置的值才释放。也就是说,如果线程数不足集合点中设置的数,就会一直等待,需要手动stop。
如果大于0,那么如果超过Timeout in milliseconds中设置的最大等待时间(毫秒为单位)后还没达到"Number of Simultaneous Users to Group"中设置的值,Timer将不再等待,释放已到达的线程。
也就是说如果线程数不满足集合点中设置的值,则在timeout中设置的时间后继续执行不足的那些线程。
Timeout in milliseconds默认为0。所以当timeout设置为0,但是线程数又不满足集合点中设置的值时,就会一直等待,不执行请求,需要手动stop。
同步定时器是在每一个采集器之前执行的,不管定时器的位置是在采集器之前还是之后,都是在采集器之前执行。
如果一个线程中存在多个采集器,同步定时器和这些采集器在同一级(同一节点下),则同时作用于这些采集器。
如果需要一个定时器单独对应某一个采集器,可以在采集器的子节点中创建定时器