這里lr就可以運行壓力測試了，同時我們可以從下圖中看到正在測試過程中的各項參數，如下圖（注意紅字標注部分）：
從上圖中的“并發用戶”圖中，答道可以看到，大經銷商在5分鐘時，并發用戶數達到了1000的‘上限’，而在“響應時間”中我們看到“發主題”操作的執行曲線在3分鐘時創出響應時間的‘高峰’，且其執行時間普遍高于其它頁面。而就在3分鐘時并發用戶數開始接近于1000，看來大并發對于發主題操作的壓力不小呀。其實在正常環境下，用戶要求的響應時間維護在3-8秒左右，而像上圖所posttopic_transaction中的“平均值”卻達到了26秒多，顯然是不可接受的，但正如我在前一篇中所說的那樣，這次測試是抱著一種將“服務器”壓死的目的來測試的，所以設置的參數基本上已接近那臺1u服務器所能承受的上限了，當然這會上平均頁面的響應時間變得‘過長’，但我認為正是這種‘慢動作’的‘假象’才能讓系統處于‘疲于奔命’的情況，也才能讓其問題能夠暴露的更全面一些。當然除了這種加大并發和工作量的方式之后，在lr中還可以通過設置‘集合點’的方式來制造更大的壓力，只不過后者更傾向于對那些正在改進或已改進的程序代碼進行壓力測試的情況，我會在后面優化程序的時候加以說明。
注：這里有必要介紹一下什么是“點擊率（Hits/sec）”, 即每秒點擊數，是在場景或會話步驟運行過程中VUser每秒向WEB服務器提交的HTTP請求數. 而上圖中就是0--5分鐘這段采樣時間內VUser平均每秒發送的HTTP請求數。而這個值的圖表‘走勢’是與系統的‘吞吐量（Throughput）’相對應的，這一點會在生成測試報告時加以解釋說明。
一般在這個時間，我會在到達1000并發用戶（圖中4分鐘左右）時，習慣性的去看一下服務器的cpu，內存和網絡情況，因為這時如果cpu處于長時間100%時就是已到了系統瓶頸了，下面就是此時服務器端的cpu，內存使用情況：
上圖中，我們看到cpu經常在100%的使用率上徘徊，并且一旦到了100%的高峰上時，就會持續一段時間，大約為3-5秒，然后就會迅速下跌。這說明系統在此時‘可能’出現了資源爭用情況，比如內存，文件或數據庫等，而此時圖中內存使用情況并不高，可以排除內存方面的問題，還有就是此時的網絡情況也并未造成擁塞（如下圖：經常處于20-50%的狀態下），所以網絡方面的因素也應該予以排除了。
那么就只剩下文件訪問和數據庫方面的問題了。因為在discuznt中使用了配置文件方式來設置系統參數，并且其文件被加載之后就被static方式進行聲明，所以一旦系統運行起來之后，就不會頻繁訪問文件了，這一點在之前的“Discuz!NT之配置文件類”中已做過說明，所以最后就剩下數據庫方面的因素了。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
