概述
空閒之餘用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左右。超出這個範圍就開始出現波動
未完待續。。。。