记一次生产压测遇到的“坑”

发表于:2020-7-07 11:24  作者:leebaul   来源:宝路测试手记

字体: | 上一篇 | 下一篇 |我要投稿 | 推荐标签: 软件测试 压测

  2020年6月19日凌晨宝路这边刚刚完成一次生产压测,现在刚睡醒的我,还在朦胧中,一想到压测遇到的问题便困意全无,洗了把脸,决定就打开电脑准备写下测试总结。
  测试背景:线上某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),我们将立即处理

评 论

论坛新帖

顶部 底部


建议使用IE 6.0以上浏览器,800×600以上分辨率,法律顾问:上海瀛东律师事务所 张楠律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2020, 沪ICP备05003035号
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪公网安备 31010102002173号

51Testing官方微信

51Testing官方微博

扫一扫 测试知识全知道