WAS性能測試工具的使用

　　幾種方式的比較：1、記錄浏覽器活動的方式以精确的方式捕捉所有使用者的互動活動，任何從浏覽器發往伺服器的url指向,應用程式參數http頭部資訊都會被自動地記錄在新的測試腳本裡。

　　2、導入伺服器日志檔案的方法在站點已經進入投入使用階段，有了真實的使用者流量的情況下使用最好，但是，一個新的站點未必有這麼多真實使用者使用資料，進一步說，可能還需要合并大量的日志檔案來達到較好的展現使用者活動的目的，這将需要建立大量的測試腳本，蔣需要用戶端更多的系統資源。

　　3、選取web内容檔案夾的方法最好用在測試多數是靜态html檔案的站點，這種方法允許在已有伺服器的web頁面的基礎上快速建立測試腳本，然而這種方法并不捕捉任何由大多數應用程式檔案産生的參數)

　　二、錄制測試腳本

　　安裝并啟動was，程式運作時會打開“cteate new script”對話框，即建立一個新的腳本視窗（如圖1），如果運作was沒有打開該視窗可以單擊was主程式視窗工具欄上第一個按鈕“new script”即可。

　　因為是初次使用，是以在建立腳本視窗上單擊“record”按鈕打開建立向導對話框“browser recorder-step 1 of 2”，其中三個選項的作用是選擇要記錄的内容，分别為request（請求）、cookies（網上資訊塊）以及host headers（主機标題），可根據需要選擇（圖2），然後單擊“next”即會打開“browser recorder-step 2 of 2”視窗，單擊“finish”按鈕。這樣was會自動啟用，并且會打開一個浏覽器視窗，此時我們就可以在浏覽器的位址欄中輸入要測試的網站網址。随着要測試的網站内容的不斷顯示，在was主界面的“recording”頁籤中的資訊會實時更新（如圖3）。

　　當浏覽器的狀态欄顯示為“完成”時，我們就可以傳回was視窗，單擊“stop recording”按鈕傳回腳本視窗。

　　三、測試設定

　　為了使測試更加準确，更加接按真實效果，需要對錄制的測試腳本進行一些設定。

　　去除靜态幹擾

　　由于網頁是由圖檔、文字以及其它動态源碼組成的，而一般的靜态内容消耗的帶寬并不是很大，是以我們可以将其排除在外。在腳本中選中指向圖像、文字以及其它靜态檔案項目前的灰色按鈕，然後單擊工具欄上的“delete”按鈕将其删除（圖4）。

　　設定并發數

　　然後在單擊“new recorded script”下的“settings”标簽，其中“concurrent connections”是設定并發連接配接數的，其下面的“stress level (threads)”和 “stress multiplier(sockets perthread)” 分别設定對目标伺服器的壓力及負載程度的，其中level是用戶端所産生的線程數目，一個線程可以産生多個socket并發請求，是以将兩者的數值相乘，所獲得的數字就是用戶端同時連接配接的并發數（圖5）。

　　時間設定

　　時間設定包括“test run time”（測試運作時間）和“request delay”（停止響應）以及“suspend”（挂起時間）三項。其中測試運作時間是以日、小時、分鐘和秒來設定的，建議該項時間不宜太短，如果設定的并發數較多，那麼時間應該按比較增長，以便産生足夠多的請求；而停止時間是指連接配接時超出這個時間即作逾時處理；在挂起時間處部分為warmup和cooldown兩項，一般可以設定為兩三分鐘為宜，這樣做的目的是避免測試開始和結束時資料的變形，影響測試的準确性。

　　指定帶寬瓶頸

　　“bandwith”是指定帶寬瓶頸的，即選擇通路該網站大多數使用者所使用的帶寬。例如通路該網站的絕大部分使用者是撥号，那麼可以選擇56k。

四、開始測試

　　做好基本的設定工作後，就可以在左側選中建立的腳本“new recorded script”項，然後單擊工具欄上的“run script”按鈕，或者打開“scripts”菜單下的“run”指令，這樣就開始測試了。測試過程中會以進度條的方式實時顯示，待進度條結束我們即可進行測試結果分析了。

　　五、資料分析

　　現在我們就可以打開測試報告來檢視測試結果了。單擊“view”菜單，選擇“reports”，在打開的視窗左側會按時間顯示所有測試報告。根據時間選擇本次測試報告，在視窗右側即可檢視具體内容。

　　在測試報告中最重要的部分就是“socket errors”部分和“result codes”部分。其中socket errors部分共分為connect、send 、recv和timeouts。其中connect表示用戶端不能與伺服器取得連接配接的次數；send表示用戶端不能正确發送資料到伺服器的次數；recv表示用戶端不能正确從伺服器接次的次數；timeouts表示逾時的線程數目。由此我們可以如果這四個數值都比較小，甚至為0則說明我們的伺服器是經得起考驗的；如果數值居高不下，甚至接近設定的并發數，那麼則要好好的檢查你的伺服器了（圖6）。

　　另外在“result codes”部分，如果code清單下的數值都為200，那麼表示所有請求都經伺服器成功傳回，如果數值出現400或大于400，例如404，那麼則需要在左側找到“page data”節點，檢視具體的錯誤項目，然後作出改正了。

　　其實要完整的反映出一個網站在伺服器上的運作情況，需要不斷增減其并發數，并且進行多次測試，才能了解伺服器所能承受的限度，然後才可以在iis中設定允許連接配接的最大數目，進而保證網站正常運作。

　　was 的負載使用說明（二）

　　測試腳本的準備

　　1、在測試用戶端機器上啟動web application stress tool，在彈出的“建立新腳本”對話框中選擇“record”按鈕；

　　2、在“record”參數設定第一步中，所有的checkbox都不用選擇，next

　　到第二步時直接點選“finish”，點選後彈出一個ie視窗以便記錄浏覽器活動，同時was會被置于記錄模式，在新出現的ie視窗的位址欄輸入你的目的站點的位址，在was的視窗你将看到http資訊在跟随你的浏覽活動而實時改變着，當完成了你的站點浏覽後，傳回web application stress tool，停止record（點選stop recording按鈕），終止記錄并産生一個新的測試腳本（在右邊的視窗将看到一個列出所有腳本的清單）。

　　3、将一些沒用的記錄删去（比如：/apply/test/index.htm）,隻留下如下圖所示的五條記錄：

　　指定目标web伺服器：server預設地目标伺服器為localhost，修改為ip位址或目标伺服器的域名

　　端口号不用輸入。左邊的視窗中改一下腳本名字，比如改為joinwork test;

　　4、5個測試用例在實際使用環境中被通路的機率是不一樣的。我們可以在page groups中定義幾個page group來模拟這種通路分布：

　　在上圖中我們定義了5個group，分别對應：查詢可啟動流程清單、啟動流程、查詢個人待辦工作任務、顯示任務執行表單和執行任務，它們被點選的次數比率為：1 : 1 : 5 : 5 : 4。

　　回到腳本首頁面，分别将5條記錄的group改為剛才建立的page group。這樣在運作腳本的時候就會按group定義的比率來産生點選了；

　　5、設定測試并發使用者數和測試運作時間

　　到 如下圖的settings頁面，通過stress level (threads)和stress mulitiplters來設定并發使用者數，test run time來設定測試時長。因為我們要做性能壓力測試，不要設定延時時間（request delay）。可以在實際測試時間之前，設定一段warm up運作時間，這段時間的資料是不會記錄到最後的報告裡的；其他設定可以保持預設值不變；

　　測試運作

　　一切準備完成後，回到腳本首頁面，然後點選工具條上的“run script”按鈕就開始測試了；

　　測試報告檢視

　　測試運作結束後，我們就可以通過點選工具條上的"reports"按鈕檢視測試報告了；

　　測試報告裡比較重要的資料是：每秒處理的請求數（requests per second）和每個頁面的平均響應時間。

　　上面兩張圖的資料是筆者直接使用joinwork開發版的預設配置（jboss 3.2.2和jboss自帶的資料庫hsql），一台主頻1.5m hz（奔騰移動）、記憶體725m的筆記本作伺服器，一台主頻2.0m hz的桌上型電腦作用戶端，測試的資料。

　　資料顯示在100并發使用者數下，每秒可處理89.26個請求，其中響應時間最長的頁面是任務執行，平均響應時間是1.66秒。

　　web application stress tool也可以采集伺服器的cpu使用率等伺服器端資料，有興趣的話可以檢視幫助檔案。

　　web application stress 是microsoft免費提供的一款軟體專門對web服務進行壓力測試用的工具軟體。我經常會需要測試一些伺服器的運作狀态和響應時間什麼的，比如在網絡中新加了一台防火牆做好設定以後，它的改動對于網絡中應用層的服務影響怎麼樣，客戶會不會明顯感覺到ie 打開站點的速度明顯減慢等等，尤其是在防火牆工作在透明代理模式下加上了一些對于應用服務的内容限制以後，設定前後速度上的改變都是非常重要參考資料的，我需要知道到底速度的影響有多大是否可以忽略不計。

部分資料解析

　　下面我們用其進行一次簡單的壓力測試。

　　打開主程式，點選"record"按鈕，選擇"record delay between request"，然後"next"，再"finish"。接下來會彈出一個浏覽器，輸入所要測試的web伺服器位址，随便浏覽一些頁面，然後将其關閉，傳回到web application stress中，點選"stop recording"按鈕。點選"settings"，就可以進入設定界面，填入一些參數。在此例中，threads我填入了50，run time我填入了2分鐘，其它預設。然後選擇"scripts"菜單項中的"run"，對伺服器進行壓力測試，等待2分鐘。

　　結束後，選擇"window"下的"reports"，可以看到類似于下面的壓力測試結果（我已經将其簡化了）。

============================================================

number of test clients: 1

number of hits: 6121

requests per second: 51.01

socket statistics

------------------------------------------------------------

socket connects: 6163

total bytes sent (in kb): 1750.10

bytes sent rate (in kb/s): 14.58

total bytes recv (in kb): 29227.62

bytes recv rate (in kb/s): 243.55

socket errors

connect: 0

send: 0

recv: 0

timeouts: 0

rds results

successful queries: 0

　　下面對其進行簡單解釋。測試時間内，虛拟的使用者點選頁面6121次，平均每秒51個請求，socket連接配接數6163，其中沒有連接配接、發送、接收、逾時錯誤。從這個壓力測試報告來看，伺服器對于50個使用者同時操作，應該沒有任何問題。需要特别說明的是，這個隻是簡化的部分結果。

　　這隻是一個簡單的示例，web application stress的功能遠不止于此，還需要在實踐中總結才是。

最新内容請見作者的github頁：http://qaseven.github.io/