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根本沒限制住。。。。。變相導致直接對接口進行了摸高壓測。
如果平時在專屬測試環境還好說，但是在線上壓測，想的悲觀一些的話是有一定風險的，關聯繫統較多，我們不清楚到底能否抗住大併發。其實無論怎樣，線上壓測一定要做好監控，做好備案，如果服務器宕機要有對應的應急預案，及時恢復生產。