在之前的兩篇文章中，基本上介紹瞭如何錄製腳本和生成併發用戶，同時還對測試報告中的幾個圖表做了簡單的說明。今天這篇文章做爲這個系列的最後一篇，將會介紹如何通過測試報告來查看系統的運行情況，找出影響性能的因素，以及如何去進行優化。
首先，看一下這張併發用戶的圖：
這是在優化之前我生成的測試報告的截圖，通過這張圖可以看到這個測試過程長達24分鐘（這在之前的無數次測試中算是具有代表性的了），
而併發用戶峯值是從4--15分鐘，持續時間近11分鐘。就目前而言，其執行的測試時間和高峯持續時間肯定要比discuz（php）要差了不少，因爲dz那邊基本上也就是10多分鐘就‘完活’了。這裏先把這張圖放一放，看一下平均事物響應時間這張圖, 如下：
可以看出目前最耗時的操作就是“發主題(posttopic)”了，我們通過在該圖上點擊鼠標右鍵，然後選中merge graphs來進行圖表合併，這裏將併發用戶（上圖）與本圖進行合併：
合併之後的圖如下，：
首先可以肯定的是在並發上來時（1000用戶，posttopic基本上處於最高位，同時查看主題(showtopic)，顯示版塊(showforum)也有‘走高趨勢’）。直到並發過去了之後，用戶數下來了，這幾個操作的響應時間才又快了起來。其實到這裏，我認爲可以將posttopic作爲優化起點，然後依次是showtopic,showforum事務。注意我這裏用的是‘事務’而不是頁面，原因很簡單，比如posttopic事務內部包括：發主題和跳轉到showtopic頁面這兩個操作（回想一下我在第一篇中的說明）。爲了看的更‘清楚’，這裏有必要加入幾張圖，如下：
然後點擊“opengraph”按鈕，加入這四個圖，這時我們將web page breakdown打開並定到posttopic_transaction，看一下這個事務中相應
操作的執行情況，如下：
首先一個‘發現’，就是這個頁面串不僅僅有之前所說的“發主題”，“顯示主題”，還包括另一個ajax請求，且其耗時達到15秒，而這是之前沒有想到的，按說不應該在這個事務中出現。換句話說，發主題事務給ajax加載背了‘黑鍋’（注:後來經過測試發現，這個請求是在頁面加載時就發出了，而原本可以在用戶鼠標點擊之後再加載），如下：
接着再看一下發主題成功之後，跳轉回“顯示主題頁面”（showtopic）的操作情況：
而下面是posttopic，提交post請求時的處理時間（19秒，雖目前可以接受，但估化之後，這個時間被大幅提升）：
看來光就提交而言，posttopic還是比showtopic快，看來之前的優化順序要做一下調整，將posttopic與showtopic這兩個頁面放在同一優先級上進行優化了。下面接着再看一下showtopic這個transaction的執行情況，如下圖：
一看嚇一跳，怎麼這個頁面裏也有那個ajax加載呀，看來問題不那個簡單了，下面再看一下showtopic頁面的加載時間：
看來這個ajax加載已經像狗皮膏藥一樣粘在我們產品身體上，趕緊把問題打給相關的開發者吧，呵呵。
在完成了這些事務分析之後，還有一個問題，就是對吞吐量的觀察，因爲如果吞吐量（Throughput）的曲線隨着Vuser數量的增加沒有增加，而是呈現出比較平的直線，說明當前的網絡速度不能夠滿足目前的系統的要求，網絡造成了瓶頸。爲了排除這種可能性，有必要看一下吞吐量這張圖，如下：
圖表顯示還是正常的，鬆了口氣（必定是100兆帶寬呀）。下面就開始專門優化一下相應的頁面和數據訪問操作了。
這裏，我還是使用了的profiler來觀察有那個sql操作被頻繁執行，如下圖：
注：這裏爲了簡化篇幅，直接將最終的觀察結果列了出來。
首先是頻繁的在線表操作更新，方法名稱:OnlineUser.UpdateAction(…),經過優化，該操作在showforum,showtopic,posttopic頁面中的調用次數從兩次變成了一次。
接着是對獲取用戶信息的操作,方法名稱：User.GetShortUserInfo()，方法因爲在傳參時使用了不當的參數，導致在更新用戶積分時還需要被執行一到兩次。
更新用戶積分：Users.UpdateUserCredit(), 這個操作主要用在了posttopic頁面中，因爲其原來的設計時傳參無法做到通用，導致後續開發者不得不再寫一個效率不高的方法來滿足自己的需要，影響了提交主題頁面的執行效率。
當然除了上述三個主要問題外，還有一些別的問題，這裏就不一一列舉了。當然這些問題都通過重構優化加以解決了（包括之前的ajax請求問題）。所以最終我們看到的優化之後的結果如下（注:爲便於對比，我將優化前和優化後的截圖一起發上來）：
首先是優化前：
優化後：
可以看出主要的頁面性能都被提升上來了，特別是posttopic 這個事務，從65提到了26。這裏要特別說明的是，在寫本文之前，我們還在持續優化程序性能， 所以說“面對優化，只有起點，沒有終點”。
下面是優化前和優化後的1000併發cpu使用率的截圖：
優化後的cpu使用率：
同時，這裏再附上一張對discuz進行壓力測試時其在1000併發用戶時的cpu運行截圖：
而discuz的測試報告截圖如下：
好了，基本上的流程就介紹完了，下面介紹個小插曲，以免讓別人犯跟我一樣的錯誤。
在前一輪優化中，因爲我們的產品有彈窗發主題和非彈窗發主題兩個設置，而就在對非彈窗發主題時出了岔子，導致我在這個功能測試上花一近1天的時間找原因，如下圖：
當然因爲我們的這個功能用的是一個頁面，即posttopic, 而在這個頁面的cs中，“非彈窗下”使用了這個方法：SetMetaRefresh(5)
其作用就是在發主題成功後，先不跳轉到showtopic頁面，而是暫停在本頁上5秒中（來顯示‘提交成功’這類的信息字樣，如下圖）：
然後再用meta元素跳轉到showtopic，而就是這5秒，人爲的降低了頁面的響應時間，而lr就真‘誠實’地將這5秒也照單記錄了下來，導致在這個事務上響應時間高的嚇人。而discuz在後臺有相應的開關來控制是否顯示‘提交成功’。當然現在我們已在後臺加入了類似的設置。
另外還有一點就是，通過優化一些重要的頁面，還可能帶來其它頁面執行效率上的提升，必定難做的工作做快了，系統就能騰出手來加快其它工作的執行速度了，呵呵。
其實在lr中，這類東西只是冰山一角，只要你有lisence，你能看到的東西會更多，比如你可以看到cpu上下文切換對系統吞吐量的影響，如下圖：
還有如果進行數據庫壓力測試，設置集合點，參數化等很多有用的功能。
好了，今天的內容就先到這裏了，繼續優化程序去:)
作者: daizhj, 代震軍
Tags: loadrunner,壓力測試,discuznt