第一部分， 測試執行
先看一圖，再看下文
這個當然就是壓力過程中帶寬的使用率了，我們的帶寬是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、多方面結合緩存機制
不知道以上的分析結果是否準確，但讓我從性能分析的思路上又走出了一個絕地，不要放過每一個細節，也許那就是拐點。