首先我們通過腳本編輯界面上的“工具”菜單項，選擇該菜單的第二項“Create Controller Scenario(創建控制場景)”，如下圖：
這時，lr會彈出一個窗口，我們只要在select scenario type項中的number of vusers設置成1000，這樣我們就可以用1000併發用戶來測試我們上文中所執行的操作了，如下圖：
注:之前在上文中設置腳本執行次數爲5，這裏又做了1000的併發用戶，所以最終我們要創建的“主題數”等於：1000*5 = 5000，而這5000主題要在10分鐘左右的時間裏創建完成，壓力不小，呵呵。
完成了這個設計並點擊"ok”之後，我們就可以看到我們所設置的場被“創建”出來了，這裏我們只要點擊"start scenario”就可以啓動壓力測試了，如下圖：
這裏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之配置文件類”中已做過說明，所以最後就剩下數據庫方面的因素了。
注：如果大家有人能搞到正版lisence的話，就不用這麼麻煩了，因爲lr會自動收集這方面的信息，可以在生成報造時給我們提供在測試周期內的cpu,內存，網絡方面的詳細結果，以便於我們在‘決策’時有準確的數據進行參考。而我本人這種做法只是權宜之計，且在準確性上也要打上‘折扣’。
如果一切正常的話，這個測試會在10分鐘後運行完畢，這時我們就可以點擊‘控制場景’中的工具條上的這個圖標來生成測試報告了（終於到了採摘‘勝利果實’的時候了），如下圖：
這樣lr就會將剛纔的測試過程生成一份報告，下面就來介紹一下這個報告（關於如何分析報告以及優化程序，因爲內容較多，不可能在本文中詳細介紹，只能在下一篇中說明了），如下圖：
下面就是其報告首頁的介紹（注意紅框和說明）：
而在首頁還有一個信息就是靜態統計，如下圖（紅框部分）：
其中：
Maxinum Running Vusers:就是模擬的最大運行用戶數(951)人，這裏爲什麼不是1000，我想主要還是與測試過程中的服務運行狀態和lr測試機本身的情況所決定的，這個值會隨你不斷反覆測試而有所變化的。
Total Throughput(bytes):即吞吐總量，是在測試過程中場景執行時從Server上接收到的數據總量（以字節爲單位，千萬別看錯單位，要不心臟不好的TX肯定會暈過去了，呵呵）。
Average Throughput(bytes/second):即每秒吞吐量，即在場景執行期間每秒從Server上接收到的數據量的值。這個值一般與網絡帶寬相比較，用以判斷目前的網絡帶寬是否是瓶頸。
Total Hits:總點擊率，在場景或會話步驟運行過程中VUser向WEB服務器提交的HTTP請求總數.
Average Hits per Second:每秒點擊數，即在場景或會話步驟運行過程中VUser每秒向WEB服務器提交的HTTP請求數.
看了這些參數，其實我一般很少看它們，因爲對於優化程序來說，多數時間是要看運行圖形的變化情況，而不是這些統計值或平均數，它們只是告訴你係統的運行情況是好是壞，卻不能告訴你係統的瓶頸出在了哪裏。下面就來簡單介紹一下報告中幾個非常重要的圖表，首先就是併發用戶圖：
該圖顯示的是併發用戶數量在整個測試周期中的生成情況，可以看到在3分鐘後，併發用戶數到達了頂峯，並在6分鐘後高峯退去。所以在這段時間內是個‘敏感期’，我們要特別重視在這個時間段內系統的反映情況。
接着就是每秒點擊率圖：
這個圖看到在3--6分鐘出現了三個高峯（值基本上到達了1300），而這個期間與上面的併發用戶高峯時段正好‘穩合’，原因很好解釋，必定用戶多了，操作多了，自然向服務器提交的http請求就多了。
接下來，再看一下‘吞吐量’：
這一張圖基本上已上前的點擊率圖的走勢差不多，原因很好解釋，因爲操作請求多了，服務器端忙了，在服務端能正常處理請求的情況下，自然接收到的數據量相應也會增加了。
下面再介紹一下事務執行情況，這張圖可以幫助我們看到那些action執行時出了問題（紅色部分爲出錯），那些工作良好（綠色爲良好）。
最後一個圖就是我經常看的圖了，“平均時間響應時間”，它告訴我們那個action的執行時間過長，那些基本穩定，那些先是穩定但大併發來時出了問題。
當然，除了這五個圖表之後，lr還提供了更多其它方面的圖表，比如頁面大小，文件(js,css,aspx等)元素加載時間等，比如下圖就是我經常添加的圖表：
其中：
Web Page Breakdown：會告訴你所做的action中，每個頁面（aspx,js,css,img）的加載時間（最大，最小，平均值）
Page Downloaded Time Breakdown: 頁面下載時間，包括dns解析時間，首次緩衝時間，發起鏈接時間等。
Downloaded Component：每個頁面體積尺寸，以便於分析那些頁面體積過大，從而影響網絡傳輸或處理速度。
最後聲明一下，上面這些圖只是說明各個圖表的性質和作用，並不是優化前的最終測試結果。
在下一篇中，我們通過最終的測試數據來找出系統有那些瓶頸，以及如果優化數據庫訪問查詢，更新等。
好了，今天的內容就先到這裏了。
