第一部分， 測試執行
先看一圖，再看下文
這個當然就是壓力過程中頻寬的使用率了，我們的頻寬是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的頻寬，如果再擴從的話也不大現實，所以還是要靠優化程式著手。
最後，我給開發提出的建議，還是需要對程式、頁面等進行優化，優化硬體還有待考量，優化建議如下：
1、降低頁面的請求次數
2、優化頁面中各個元素的容量大小，結合page speed和yslow工具進行優化測試
3、多方面結合快取機制
不知道以上的分析結果是否準確，但讓我從效能分析的思路上又走出了乙個絕地，不要放過每乙個細節，也許那就是拐點。
效能測試瓶頸分析
在效能測試過程中，瓶頸猶如功能測試的bug，瓶頸的分析猶如bug的定位。效能測試工程師好比醫生，看到病象，定位 效能瓶頸的定位更像庖丁解牛，層層解剖，最後定位問題之所在。下面分享乙個記憶體洩漏的瓶頸分析。病象 tps波動非常大 狂打超時日誌 偶爾有500錯誤。看到這個現象，其實說明不了什麼問題，就象...
效能測試瓶頸分析
在效能測試過程中，瓶頸猶如功能測試的bug，瓶頸的分析猶如bug的定位。效能測試工程師好比醫生，看到病象，定位 效能瓶頸的定位更像庖丁解牛，層層解剖，最後定位問題之所在。下面分享乙個記憶體洩漏的瓶頸分析。病象 tps波動非常大 狂打超時日誌 偶爾有500錯誤。看到這個現象，其實說明不了什麼問題，就象...
效能測試瓶頸分析
在效能測試過程中，瓶頸猶如功能測試的bug，瓶頸的分析猶如bug的定位。效能測試工程師好比醫生，看到病象，定位 效能瓶頸的定位更像庖丁解牛，層層解剖，最後定位問題之所在。下面分享乙個記憶體洩漏的瓶頸分析。病象 tps波動非常大 狂打超時日誌 偶爾有500錯誤。看到這個現象，其實說明不了什麼問題，就象...