性能测试爬坑之路9(集合点2)

 

关住 公 纵 号 “  阿蒙分享    ”  获得学习资料及趣味分享 

 

我们的目的不是模拟真实场景得出性能指标,所以只需要测试集合点接口就好

 

一个脚本中可以有多个集合点,

性能测试爬坑之路9(集合点2)_第1张图片

集合点和事务的顺序

事务里面包含的是请求的响应时间和成功率,还有一个作用就是建模评估用的

事务统计的时间是事务标记夹着的代码块所消耗时间,所以集合点不能出现在事物代码块中

集合点策略设置:

性能测试爬坑之路9(集合点2)_第2张图片

选中用户设置  【Disable VUser】 设置的意思是  

其他用户互相等待,这几个用户无需等待直接请求  (必要性不大)

性能测试爬坑之路9(集合点2)_第3张图片

点击【policy】

性能测试爬坑之路9(集合点2)_第4张图片

翻译:当 100% 的运行用户到达集合点的时候释放

理解一二选项首先回到虚拟用户增加策略上来

比如每15秒增加5个用户增加到30个用户

到第一个15秒的时候所有的运行虚拟用户为5个

到第二个15秒(就是30秒)的时候所有运行的虚拟用户为 10 个

等到了(6*15)秒时所有的运行虚拟用户数量才跟所有虚拟用户数量相等

性能测试爬坑之路9(集合点2)_第5张图片

性能测试爬坑之路9(集合点2)_第6张图片

建议大家选择第二种策略

结合点的禁用【disable rendezvous】

性能测试爬坑之路9(集合点2)_第7张图片

这里有一批响应时间的数据点

性能测试爬坑之路9(集合点2)_第8张图片

我们看到中间一个数据点都没有,原因是,这段时间就是集合点等待的时间,他根本没有办法发请求,所以根本没有相应时间

所以这个响应时间不能用于用户感知的响应时间的参考的

所以用集合点进行性能测试的时候这些响应时间根本没必要去关注,因为他根本没有太大的参考意义

我们关注的是系统承受不承受的了,这个模块有没有问题,我们关注的是系统后台的问题,前端收集到的信息都没有太多的实用性,

性能测试

你可能感兴趣的:(压力测试)