這兩天在為進行過調優后的服務器做性能測試，在對其中一個詳情頁面進行壓力測試的時候，測試結果為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的縮寫，也就是事務數/秒。它是軟件測試結果的測量單位。一個事務是指一個客戶機向服務器發送請求然后服務器做出反應的過程�？蛻魴C在發送請求時開始計時，收到服務器響應后結束計時，以此來計算使用的時間和完成的事務個數，最終利用這些信息來估計得分�？蛻魴C使用加權協函數平均方法來計算客戶機的得分，測試軟件就是利用客戶機的這些信息使用加權協函數平均方法來計算服務器端的整體TPS得分。
注：Loadrunner中還有很多其他的評測參數，不過我個人認為TPS更具代表性，因此只在此用TPS作為評核依據。
文章來源于領測軟件測試網 http://www.kjueaiud.com/