這兩天在爲進行過調優後的服務器做性能測試，在對其中一個詳情頁面進行壓力測試的時候，測試結果爲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作爲評覈依據。
隨筆有些是自己寫的，有些是根據網上的東西自己整理的，文章基本都是別人的，只是爲方便查看複製到那裏
