百度壓測，分析性能拐點
- 2019 年 10 月 3 日
- 筆記
概述
空閑之餘用jmeter對百度進行了一次壓測，目的是分析一下性能的拐點，驗證一下理論知識
操作
第一次實驗：200並發
並發200，不限迭代次數，同時在請求下面加RPS定時器。
目的是在200執行緒下，將RPS逐步增加到1000/S,並持續運行一段時間。
在執行緒下面添加TPS，HPS，響應時間三種監聽器
啟動jmeter，運行一段時間之後我們觀察一下監聽器的數據圖表。
RPS 在793/s的時候，出現拐點，請求曲線的角度開始收窄
TPS在 720/s左右開始出現劇波動，前期一直保持平穩上升，可以認為這是吞吐量的一個拐點
另外，在1:03秒的時候，也就是TPS達到 907/S 的時候，事物開始出現錯誤。此時短暫出現百度頁面打不開的情況。
1：可以認為此處就是一個性能瓶頸
2：有可能是百度對ip的訪問量做了限流，防止爬蟲
3：有可能是我當前環境的問題，包括頻寬，記憶體，cpu等等資源的限制，後期都需要考慮進去
觀察分析聚合報告
在性能穩定的情況下，才可以套用公式去計算出最大並發數
1：穩定狀態下，最大 RPS= 793/S
2：穩定情況下，響應時間大約長期保持在 160 ms
3：穩定情況下，峰值並發數大約是 793*160=126
4：穩定情況下，峰值並發=平均並發 + 3*√平均並發，所以得出平均並發大約是 96
第二次實驗：100並發
這一次我們把執行緒數收緊，只給100並發。以此觀察執行緒數降低的情況下，壓力會不會變小
觀察到，請求數依然在790-800這個區間變緩
結論
此當前環境下，不論是本機資源，還是百度設置了限流等原因，我們的最大請求數只能維持在790-800，最大TPS維持在700-730之間，最大並發數在130左右。超出這個範圍就開始出現波動
未完待續。。。。
