百度壓測，分析性能拐點

概述

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

 

 未完待續。。。。