這兩天在為進行過調優後的伺服器做效能測試，在對其中乙個詳情頁面進行壓力測試的時候，測試結果為110tps，對於這一結果我們是非常不滿意，隨後又在多個不同的模組下進行測試，結果都非常的相近，然而在壓力測試過程當中，伺服器的資源消耗非常低，由此我們可以看出，伺服器遠遠未達到壓力的極限，而應用程式應該不會有問題，如果是程式問題，伺服器資源絕對不會有那麼多空閒。
問題到底出在**呢？我們web伺服器的架構為nginx+lighttpd，於是我們一層層進行單獨測試，發現結果仍然是一樣，4核的伺服器cpu資源損耗僅處於20%左右，我們又對單一的靜態頁面做壓力測試，發現結果仍然是差不多，並沒有太大的提公升。無論動態還是靜態頁面，結果都一樣，這就更加肯定了我們的結論。排除了應用程式的問題，那問題就應該出在io那塊，再通過磁碟監控，發現磁碟io的損耗也非常的低，但是我們卻有乙個意外的發現，多次測試的結果中，網路io的流量都是處於12m左右。
看到這裡，我們心裡就豁然開朗了，問題原來是在這裡，我們一直都把重心關於於伺服器本身的效能調優上，卻偏偏忘記了網路頻寬的因素，雖然我們測試伺服器的網絡卡是100/1000m網絡卡，然而我們卻是將伺服器部署於百兆區域網內，而100m頻寬的實際傳輸速度剛好是介於12m左右，由於我們終於發現瓶頸是在於網路頻寬，而非是伺服器本身的效能上。於是二話不說，我們立刻將所有的測試伺服器以及客戶機都連線在同一千兆網內，盡可能降低網路頻寬的限制。
成功搭建好環境之後，再進行測試，結果果然如我們所料，靜態頁面的測試中，最快的模組測試達到了600tps上線，而此時的網絡卡流量已經達到了50m左右，而由於多個模組的頁面大小並不相同，tps的結果也各不相同，但是網絡卡的流量卻都處於50m上下，然而1000m網的理論速度是可以達到120m左右，50m的實際速度遠遠未到此數，也許達不到理論速度，但是相差應該也不會太多，於是我們嘗試從兩台伺服器之間互相copy大檔案測試一下實際速度有多少，而最終的結果也是和我們測試web伺服器的結果一樣，也是在50m上下，因此又一次證明了io是乙個瓶頸，只是還無法確定是磁碟io還是網路io，由於時間比較緊，我們就並未在此問題上多做糾纏，因為這只是對靜態頁面的測試，實際執行過程當中，真正的瓶頸應該是在應用上，因此我們再次將重心轉移到動態頁面的請求上。
再一次對動態頁面進行壓力測試，這次我們對各個模組測出的平均結果處於200tps上下，而網路流量僅僅處於30m左右，此時伺服器的資源佔用率已經處於 80-90%之間，基本已經是處於滿負荷狀態，純動態頁面200tps，不算高，程式本身還有很大優化的空間，不過五一過後就要正式上線，此時再進行優化已經來不及，不過對於純動態請求200tps的結果，其實我已經相對滿意了，因為考慮到實際應用場景，在最有可能出現峰值的情況下，實際大部分使用者只會訪問比較少數相同的頁面，而我們對於同一頁面的請求都進行了靜態化的處理，實際上除了第一次請求外，其他的請求都是直接訪問靜態頁面，因此實際能承受的壓力遠遠不止於此。
最後，我們針對實際應用場景，通過loadrunner模擬真實訪問情景，結合所有的測試對系統進行綜合的測試，對各種情況進行百分比設定，盡量模擬真實情況，測試的結果處於400-500tps，而網路流量也到了之前測試的上限值，再考慮到實際情況中，客戶端對靜態資源還會進行快取，應該還會有相對大的提公升，本次的結果相對真實，而我也比較滿意，在下一版本中，應該會針對應用程式再次進行優化，相信還會得到乙個不小的提公升。
最後，在此對tps進行一下解釋（摘自網上的解釋，懶得自己寫了，我是個懶人）：
tps是transactionspersecond的縮寫，也就是事務數/秒。它是軟體測試結果的測量單位。乙個事務是指乙個客戶機向伺服器傳送請求然後伺服器做出反應的過程。客戶機在傳送請求時開始計時，收到伺服器響應後結束計時，以此來計算使用的時間和完成的事務個數，最終利用這些資訊來估計得分。客戶機使用加權協函式平均方法來計算客戶機的得分，測試軟體就是利用客戶機的這些資訊使用加權協函式平均方法來計算伺服器端的整體tps得分。
注：loadrunner中還有很多其他的評測引數，不過我個人認為tps更具代表性，因此只在此用tps作為評核依據。
磁碟陣列 頻寬和IOPS對效能影響
陣列的瓶頸主要體現在2個方面，頻寬與iops 單位時間傳輸的資料量，和單位時間完成的i o數 頻寬 儲存系統的頻寬主要取決於陣列的構架，光纖通道的大小以及硬碟的個數。所謂陣列構架影響儲存系統頻寬，指的是儲存系統內部架構會存在一些內部頻寬，類似於pc的系統匯流排，儘管陣列的構架因不同廠商不同型號的產品...
效能測試分析之頻寬瓶頸的疑惑
第一部分，測試執行 先看一圖，再看下文 這個當然就是壓力過程中頻寬的使用率了，我們的頻寬是1gbps的，合計傳輸速率為128mb s，也正因為這個就讓我越來越疑惑了，不過通過壓力過程中的各項資料我又不得不相信。在看看測試頁面的大小和請求，如下圖所示 這是通過httpwatch檢測得出來的，頁面傳輸內...
在jmeter測試中模擬不同的頻寬環境
預設情況下，jmeter發請求是盡自己最大努力的的發，但與真實情況卻有差別。jmeter給出不兩個選項來模擬不同的網路速度 分別控制http和https。預設的引數值為0，也就是不限制速度。cap是 characeters per second 的首字母縮寫，當你編輯大於0時，頻寬將會根據你的設定限...