電商平臺的搶購活動，12306春運搶票，微信搶紅包等，相信大家一定不會陌生，這些都是高併發的應用場景，那怎樣去模擬這些場景來驗證我們的系統抗壓能力呢？
壓測維度及方案
我們最先想到的例如Jmeter,loadrunner等壓測工具，一上來先擼幾百個執行緒，然後分析各種結果圖，聚合報告，伺服器CPU佔用率, 記憶體，IO 等各種指標，其實併發多少個虛擬使用者，不同的公司產品有不同的策略，對於產品效能的要求也應該是逐步進階的，不同的使用者量有不同的要求
首先: 對於使用者量，應該統計幾個維度：註冊人數，線上人數，併發使用者數，針對秒殺活動，一般情況
併發使用者數 = 線上人數 * 0.8
複製程式碼更理想的併發的虛擬使用者數應該是根據以往的運營資料來推測，假設系統的註冊人數為5000人，活動線上人數為1250人，併發數為：1250*0.8=1000
其次：一次http的請求，從客戶端發起，可能要經過負載均衡服務，閘道器，tomcat服務，所以併發瓶頸可能發生在其中任何一個節點，壓測策略
- 壓測空實現的介面（程式碼中無相關耗時操作和sql操作），
- 在壓測其它介面，對比這兩種壓測結果，可能會更有利於我們分析是哪個節點對效能影響較大，從而有針對性的優化
- 分析壓測結果，壓測結果一般需要關注幾個重要指標：吞吐量，錯誤率，響應時間（遵循2-5-10原則）
壓測流程
基於以上分析，我們具體的壓測流程如下：
壓測空介面
先壓測空介面，jmeter新建執行緒組，併發使用者數設定為1000，迴圈1次，並增加集合點，新增檢視結果樹，圖形結果，聚合報告, TPS檢視
壓測結果如下：成功100個，失敗900個，介面報錯返回500
重新使用110個執行緒壓測，失敗10個，介面報錯返回500，可推測某個節點可能對執行緒數量做了限制，分析後，發現閘道器工程做了訊號量限制,最大100，檢視閘道器工程的application.yml檔案，修改相關引數配置，例如增大至5000：
再次使用jmeter併發1000個執行緒，壓測結果如下：吞吐量=241.1/sec ，平均響應時間<5s，錯誤率=0.00%，基本符合壓測要求
壓測業務介面
對相關業務介面，使用jmeter單次併發1000個執行緒，發現部分請求會報超時：
jmeter該介面的平均響應時間，為33s，考慮有可能是超過了伺服器設定的超時時間，首先檢視nginx超時時間,發現超時引數為30s，修改至60 s, 重新併發，問題解決，壓測結果如下：
聚合報告：
Linux伺服器相關指標：
壓測前：
壓測期間：
測試結論： 吞吐量= 27.6/sec不滿足要求,90%使用者響應時間=33.356s,響應時間>5s，不符合要求,壓測瞬間伺服器cpu佔用率較高
模擬現實
因為現實情況下，壓力是持續一段時間存在的，所以需要對介面進行一段時間的壓測，jmeter執行緒組上需要勾選Scheduler,然後在Scheduler Configuration上設定Duration持續時間:
總結：
介面的壓測需要根據產品，專案的要求來制定具體的壓測策略，壓測結果需要關注吞吐量，響應時間，錯誤率，資源利用率，但對系統的效能測試不僅僅是單介面的壓測，還涉及的負載加壓測試，穩定性測試，全鏈路壓測等等，以適應產品的效能要求。