记一次生产压测遇到的"坑"

1.背景

     2020年6月19日凌晨宝路这边刚刚完成一次生产压测,现在刚睡醒的我,还在朦胧中,一想到压测遇到的问题便困意全无,洗了把脸,决定就打开电脑准备写下测试总结。

     线上某app的接口耗时较长,项目组经过针对性优化后想在线上进行验证,特申请线上压测验证,如果可以的话,项目组建议做下接口的摸高测试

2.测试方案

针对项目的需求,提前定制好了测试方案与测试指标,并通过邮件进行了评审。大致为以下测试场景:

  • 在200RPS下,该接口相应时间不超过1秒,场景运行5分钟。

  • 在400RPS下,该接口响应时间不超过1秒,场景运行5分钟。

  • 摸高测试根据前面压测结果,现场设计梯度加压场景。

3.压测实战

于是乎针对测试方案,开始脚本编写及调试验证工作,压测工具还是采用的JMeter,那么限制RPS怎么做到呢?目前看JMeter有两种方式,一种是采用Throughput Shaping Timer定时器,另一种是采用Constant Throughput Timer.

两种方式脚本结构图:

image

   需要说明下,JMeter自带的SleepTest、JavaTest 请求非常实用.  下面说说遇到的“坑”。。。。。。

  • 采用方式一的方式,场景的执行时间由Throughput Shaping Timer中设置的Duration时间决定;如果采用方式二,场景的执行时间则是由线程组设定的执行时间决定。
  • 如果是用分布式压测,脚本设置的限制的RPS要除slave机个数,比如我们要限制200RPS,分布式压测下用了4台slave机器,则脚本中设置的限制RPS值为 200RPS / 4 = 50 RPS

     最开始脚本的调试及验证,宝路都是用的单台JMeter机器,脚本限制RPS也都OK,结果在线上压测却发现RPS根本没限制住。。。。。变相导致直接对接口进行了摸高压测。

如果平时在专属测试环境还好说,但是在线上压测,想的悲观一些的话是有一定风险的,关联系统较多,我们不清楚到底能否抗住大并发。其实无论怎样,线上压测一定要做好监控,做好备案,如果服务器宕机要有对应的应急预案,及时恢复生产。

posted @ 2020-06-23 16:12  宝路  阅读(160)  评论(0编辑  收藏