性能測試分析之帶寬瓶頸的疑惑

　　第一部分， 測試執行

　　先看一圖，再看下文

　　這個當然就是壓力過程中帶寬的使用率了，我們的帶寬是1Gbps的，合計傳輸速率為128MB/s，也正因為這個就讓我越來越疑惑了，不過通過壓力過程中的各項數據我又不得不相信。

　　在看看測試頁面的大小和請求，如下圖所示：

　　這是通過httpwatch檢測得出來的，頁面傳輸內容的大小為652154Byte，請求數為149次，也就是說加載一次頁面就大概需要請求這么多次請求，傳輸這么大的內容，當然這里剔除緩存機制來分析的。

　　場景設計：

　　1、并發用戶200

　　2、每20秒加載10個用戶

　　3、全部用戶加載完成之后，持續運行10分鐘

　　監控目標：TPS、響應時間、點擊率、吞吐率、內存、CPU和網絡帶寬

　　測試分析結果如下圖：

　　這里的可以得出平均點擊率為11952.139次/s，而吞吐率為73178737byte，大約為73MB/s，TPS：720/s，這里的錯誤后面再說。

　　這里的響應時間很顯然沒有上去，說明壓力沒有傳到頁面上，而上面的錯誤也同時可以證實，報錯基本都是請求被拒絕，也就說后面沒有請求導致頁面沒有壓力，響應時間就無效了。

　　通過監控得到系統資源占用率數據有：

　　CPU：25～30%

　　內存：20%

　　網絡帶寬：70～95%

　　通過Httpwatch在壓力過程監控的頁面響應時間為：6.454s

　　通過結合虛擬用戶、點擊率、吞吐率和響應時間的曲線圖分析得出如下總結：

　　當虛擬用戶加載到150的時候，點擊率和吞吐率此時處于峰值，且網絡帶寬達到90%以上，當虛擬用戶繼續加載的時候，點擊率和吞吐率均都開始下降，此時場景運行開始報錯，提示信息為服務器連接被拒絕。通過分析，處于峰值只有網絡帶寬，為90%以上，而對比此處的吞吐率值恰為95MB/s左右，1Gbps的網絡帶寬傳輸速率為128MB/s，從而表明由于吞吐量過大，占用了大量的帶寬資源，導致后續的虛擬用戶無法得到服務器的資源，而致使請求被拒絕。從最后的頁面響應時間來看，系統的壓力并沒有被承接到頁面上，而是由于過大的吞吐量吞噬了網絡帶寬，導致最終無法有效地完成測試任務。

　　第二部分，測試分析

　　如上的結果確實是證實了網絡帶寬不夠用，抱著這個不大相信的疑問，我在群里跟大家討論了一番，當然大家的給出結論也都是一致，也有建議修改系統的參數，釋放所有的帶寬等;還有就是分析頁面，當然這個我個人認為是比較切實的路徑，畢竟1Gbps的帶寬，如果再擴從的話也不大現實，所以還是要靠優化程序著手。

　　我又繼續通過httpwatch工具對其他門戶網站首頁進行檢測，發現頁面容量差不多，但是從請求上來講，騰訊和同花順的首頁請求都只有80左右，而我們的卻有149個請求，這里的請求數就直接決定于點擊率的多少，從這里我們就可以發覺，并不是對所有的壓力測試來說，每秒鐘的點擊率越高，對應的吞吐率越大就說明系統的性能越好，必須相對請求數而言來進行分析。從另一個層面上來說點擊率越高是說明程序效率好，但是從本身來講，如果一個頁面本身的請求就很多，那最后的點擊率必然會大，大到最后的結果就是頁面內容累計容量就越大，導致傳輸帶寬的不斷放大，當然就帶寬不夠用了。如果一定程序上降低了單個頁面的請求數量，那頁面的執行效率必然會越高，而需要結合整體頁面的容量大小來衡量。

　　最后，我給開發提出的建議，還是需要對程序、頁面等進行優化，優化硬件還有待考量，優化建議如下：

　　1、降低頁面的請求次數

　　2、優化頁面中各個元素的容量大小，結合Page Speed和YSlow工具進行優化測試

　　3、多方面結合緩存機制

　　不知道以上的分析結果是否準確，但讓我從性能分析的思路上又走出了一個絕地，不要放過每一個細節，也許那就是拐點。

原文轉自：http://www.anti-gravitydesign.com