1.背景
2020年6月19日凌晨宝路这边刚刚完成一次生产压测，现在刚睡醒的我，还在朦胧中，一想到压测遇到的问题便困意全无，洗了把脸，决定就打开电脑准备写下测试总结。
线上某app的接口耗时较长，项目组经过针对性优化后想在线上进行验证，特申请线上压测验证，如果可以的话，项目组建议做下接口的摸高测试
2.测试方案
针对项目的需求，提前定制好了测试方案与测试指标，并通过邮件进行了评审。大致为以下测试场景：
在200RPS下，该接口相应时间不超过1秒，场景运行5分钟。
在400RPS下，该接口响应时间不超过1秒，场景运行5分钟。
摸高测试根据前面压测结果，现场设计梯度加压场景。
3.压测实战
于是乎针对测试方案，开始脚本编写及调试验证工作，压测工具还是采用的JMeter，那么限制RPS怎么做到呢？目前看JMeter有两种方式，一种是采用Throughput Shaping Timer定时器，另一种是采用Constant Throughput Timer.
两种方式脚本结构图：
需要说明下，JMeter自带的SleepTest、JavaTest 请求非常实用. 下面说说遇到的“坑”。。。。。。
- 采用方式一的方式，场景的执行时间由Throughput Shaping Timer中设置的Duration时间决定；如果采用方式二，场景的执行时间则是由线程组设定的执行时间决定。
- 如果是用分布式压测，脚本设置的限制的RPS要除slave机个数，比如我们要限制200RPS,分布式压测下用了4台slave机器，则脚本中设置的限制RPS值为 200RPS / 4 = 50 RPS
最开始脚本的调试及验证，宝路都是用的单台JMeter机器，脚本限制RPS也都OK，结果在线上压测却发现RPS根本没限制住。。。。。变相导致直接对接口进行了摸高压测。
如果平时在专属测试环境还好说，但是在线上压测，想的悲观一些的话是有一定风险的，关联系统较多，我们不清楚到底能否抗住大并发。其实无论怎样，线上压测一定要做好监控，做好备案，如果服务器宕机要有对应的应急预案，及时恢复生产。