在实际压测前,我们还需要对场景做适当的调整。
从 ThreadGroup中看,我们的 Thread会在某个时间点同时起多个,而日常场景中我们需要的可能是一个递增的梯度加压的方式。
为了实现梯度递增,我们就需要借助于插件 UltimateThreadGroup
先看下 UltimateThreadGroup插件的面板信息,如下:
-
参数解释:
-
StartThreadsCount:当前行启动的线程总数
-
InitialDelay/sec:延时启动当前行的线程,单位:秒
-
StartupTime/sec:启动当前行所有线程达峰值所需时间,单位:秒
-
HoldLoadFor/sec:当前行线程达到峰值后的稳定加载时间,单位:秒
-
ShutdownTime:停止当前行所有线程所需时间,单位:秒
-
文字的描述还是稍显晦涩, UltimateThreadGroup插件有个很好的地方就是下方的图表,它会根据你的设定而展示出趋势图,那么现在我们设定如下参数:
-
StartThreadsCount:100
-
InitialDelay/sec:10秒
-
StartupTime/sec:200秒
-
HoldLoadFor/sec:100秒
-
ShutdownTime:10秒
从插件的趋势图我们可以看到在延迟10秒后100个线程在200秒时间内逐步从0递增至100,然后持续100秒的时间,最后在10秒的时间内有逐步从100递减到0。
当然你还可以继续添加 ThreadSchedule,趋势图会帮你绘制出综合的线程运行趋势:
1) 选择插件 UltimateThreadGroup
2)将写好的Jmeter脚本整体移至 UltimateThreadGroup下
3)现在我们需要的场景是:
- 开始我们需要在60秒的时间内起是10个thread,然后保持运行
- 接着我们继续在60秒的时间内再起10个thread,然后和开始的10个线程一起保持运行100秒后结束
具体设置如下:
1.$ jmeter n
t
RegisterLogin
.
jmx
2)在grafana中查看运行数据
从数据中简单的分析,可以看到:
线程数在设定的120秒时间内均匀的从0递增至20
错误率在38分30秒的时候出现剧增,而这个时候的线程数为5,说明在 ActiveUser达到5的时候系统出现了问题造成错误率陡增。
从错误率和响应时间来看,结果较差的接口主要集中在下单流程这块,而首页的响应时间也很大,很可能是因为首页相关的表数据是和订单的表数据有关联的,因而订单的响应时间增加也会造成首页的耗时增加。
- 插件添加后在如下位置选择
打开后的面板如下:
现在可以设置当平均响应时间大于200ms持续10秒,平均延迟时间大于300ms持续10秒或者错误率大于1%持续5秒时测试停止。
可以看到当我们的响应时间持续10秒超过200ms时,测试自动停止了。
总结
客户端方面的电商压测实战学习暂时到这里了,后面如果还想继续深入学习就需要关注服务端的指标了,依然可以结合 docker+grafana+prometheus的方式来监控服务端的各项指标进行分析。
更多技术文章分享请点击链接
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)