测试背景:线上某app的接口耗时较长,项目组经过针对性优化后想在线上进行验证,特申请线上压测验证,如果可以的话,项目组建议做下接口的摸高测试。
测试方案:针对项目的需求,提前定制好了测试方案与测试指标,并通过邮件进行了评审。大致为以下测试场景:
在200RPS下,该接口相应时间不超过1秒,场景运行5分钟。
在400RPS下,该接口响应时间不超过1秒,场景运行5分钟。
摸高测试根据前面压测结果,现场设计梯度加压场景。
于是乎针对测试方案,开始脚本编写及调试验证工作,压测工具还是采用的JMeter,那么限制RPS怎么做到呢?
目前看JMeter有两种方式,一种是采用Throughput Shaping Timer定时器,另一种是采用Constant Throughput Timer.
两种方式脚本结构图:
需要说明下,JMeter自带的SleepTest、JavaTest 请求非常实用.
下面说说遇到的“坑”。
采用方式一的方式,场景的执行时间由线程组、Throughput Shaping Timer二者中设置的最小时间决定;如果采用方式二,场景的执行时间则是由线程组设定的执行时间决定。
如果是用分布式压测,脚本设置的限制的RPS要除slave机个数,比如我们要限制200RPS,分布式压测下用了4台slave机器,则脚本中设置的限制RPS值为 200RPS / 4 = 50 RPS
最开始脚本的调试及验证,宝路都是用的单台JMeter机器,脚本限制RPS也都OK,结果晚上在生产上压测却发现RPS根本没限制住。变相导致直接对接口进行了摸高压测。
如果平时在专属测试环境还好说,但是在线上压测,想的悲观一些的话是有一定风险的,关联系统较多,我们不清楚到底能否抗住大并发。其实无论怎样,线上压测一定要做好监控,做好备案,如果服务器宕机要有对应的应急预案,及时恢复生产。
本文内容不用于商业目的,如涉及知识产权问题,请权利人联系博为峰小编(021-64471599-8017),我们将立即处理