第一篇：LoadRunner學(xué)習(xí)總結(jié)[本站推薦]

LoadRunner學(xué)習(xí)小結(jié)

今年十月份我到北京跟張坤學(xué)習(xí)性能測試知識，共花了三個星期學(xué)習(xí)LoadRunner。以下是我的學(xué)習(xí)小結(jié)。

一． 什么是LoadRunner LoadRunner是一種預(yù)測系統(tǒng)行為和性能的工業(yè)標(biāo)準(zhǔn)級負(fù)載測試工具。通過以模擬多個用戶實施并發(fā)負(fù)載測試及實時性能檢測的方式來確認(rèn)和查找問題，能對整個企業(yè)架構(gòu)進行測試。

二． LoadRunner的優(yōu)點

1.輕松創(chuàng)建虛擬用戶：通過記錄下業(yè)務(wù)流程轉(zhuǎn)為測試腳本，在機器上產(chǎn)生多個用戶訪問，減少負(fù)載測試需要的硬件和人力資源。

2.創(chuàng)建真實的負(fù)載：可以通過Controller設(shè)定負(fù)載方案，如定義用戶在什么時候訪問系統(tǒng)以產(chǎn)生負(fù)載，所有用戶同時執(zhí)行一個動作來模擬峰值負(fù)載情況等。3.實時監(jiān)測器：可以實時顯示交易性能數(shù)據(jù)（如響應(yīng)時間）和其他系統(tǒng)組件如數(shù)據(jù)庫，網(wǎng)絡(luò)等的實時性能。

4.分析結(jié)果以精確定位問題所在：LoadRunner能收集匯總所有測試數(shù)據(jù)，提供高級的分析和報告工具。

三． LoadRunner的安裝與使用

1.安裝過程詳見上傳的LoadRunner使用手冊，在此不再詳細(xì)介紹。2.具體使用：

點擊File新建錄制文件，也可以點擊下面的NEW快捷鍵進行新建。使用File新建，會彈出協(xié)議選擇窗口，選擇新的單協(xié)議腳本（New Single Protocol Script）的Web(HTTP/HTML)項，確定即可（選擇Web項是因為我們測試的是Web應(yīng)用）。接著會彈出開始錄制的設(shè)置項，需要寫入錄入系統(tǒng)的地址，點擊確定后就會根據(jù)錄入地址展現(xiàn)系統(tǒng)頁面，開始錄制腳本，出現(xiàn)小工具條：

第一個按鈕為錄制鍵 第二個為回放腳本鍵 第三個為停止錄制鍵 第四個為暫停錄制鍵 第五個為編譯腳本鍵

第六個為創(chuàng)建新的Action鍵。LR的錄制腳本分為三個部分，vuser_init、vuser_end和 Action。腳本循環(huán)執(zhí)行時，只執(zhí)行一次vuser_init和vuser_end，而多次循環(huán)Action部分。比如錄制投保業(yè)務(wù)時，登陸系統(tǒng)部分放入vuser_init，退出登陸放到vuser_end，中間的投保操作放到Action中，則循環(huán)執(zhí)行時就會登陸一次投保系統(tǒng)開始反復(fù)執(zhí)行投保操作直到結(jié)束退出系統(tǒng)。

第七個為用來改變錄制的options設(shè)置按鈕

第八個和第九個為插入事務(wù)的起始點和結(jié)束點鍵，結(jié)合起來構(gòu)成一個完整事物，用來衡量服務(wù)器的性能。比如錄制腳本過程中，投保系統(tǒng)的查詢投保單號操作，可以在輸入完查詢信息后點擊查詢按鈕前插入事務(wù)的起始點，查詢出數(shù)據(jù)后插入事務(wù)的結(jié)束點，這樣在運行測試腳本時，Loadrunner在運行到該事務(wù)時，便會計算出這個查詢操作所花時間，便于衡量服務(wù)器執(zhí)行查詢操作的性能。

第十個為插入集合點鍵，可用于衡量在加重負(fù)載的情況下服務(wù)器的性能。比如要驗證系統(tǒng)是否能承受100人同時進行報案操作，便可在腳本錄入過程中，點擊報案確認(rèn)鍵操作前插入集合點，這樣當(dāng)腳本運行到集合點時，Loadrunner會讓100個虛擬用戶同時點擊報案確認(rèn)按鈕（如果有的用戶還沒運行到集合點，先到用戶要等未到用戶一起操作）進行報案，從而達(dá)到測試目的。

最后一個為設(shè)置驗證點鍵，在創(chuàng)建事物后，設(shè)置一個驗證點可以用來確認(rèn)事物執(zhí)行是否成功。比如進行查詢事務(wù)操作時，LR只要檢測到網(wǎng)頁的響應(yīng)，就認(rèn)為事務(wù)pass,而不管顯示頁面內(nèi)容是否正確。因此為了檢查Web服務(wù)器返回的網(wǎng)頁是否正確，可以插入Text/Image檢查點，驗證網(wǎng)頁上是否存在指定的Text或Image。

設(shè)置驗證點時，如果我們驗證的文本內(nèi)容是中文，有時會返回?zé)o法找到驗證內(nèi)容的報錯信息，而頁面顯示又是正確的，出現(xiàn)問題的原因可能是因為LR對中文的支持部好，盡量選擇驗證信息為數(shù)字或字母；也可能是設(shè)置問題，可以嘗試將Tools->Recording Options->HTTP Properties下的Advanced選項里設(shè)置支持UTF-8，再檢查開發(fā)人員有沒有設(shè)置支持中文。

錄制結(jié)束后，先點擊保存腳本，同時為腳本命名。然后編譯腳本，看是否存在語法錯誤，編譯成功后，即可回放，看錄制腳本是否成功。

LoadRunner錄制得到的腳本基本沒有錯誤，不像robot會有錄入數(shù)據(jù)的缺失，只是會錄入一些非錄入系統(tǒng)的網(wǎng)頁信息，根據(jù)地址可以識別并刪除掉。

四． LoadRunner腳本錄制學(xué)習(xí)小結(jié)

1.LoadRunner錄制腳本，主要是為了進行壓力測試，所以跑流程時，跑了主要流程即可，也就是系統(tǒng)必須的信息錄入就可以了。2.LoadRunner的腳本運行過程中，只能用于一次業(yè)務(wù)辦理的數(shù)據(jù)需要做參數(shù)化，如車輛車架號，車牌，報案號等，以免出現(xiàn)重復(fù)投保或報案無法立案現(xiàn)象，不能繼續(xù)進行下去。參數(shù)化步驟：

1）將需要做參數(shù)化的數(shù)據(jù)右鍵點擊，選擇Replace with a parameter,進行設(shè)置。2）在彈出編輯框里，設(shè)置易懂的參數(shù)名稱，再點擊Properties進行屬性設(shè)置。3）點擊Create Table 按鈕，生成參數(shù)表格，再點擊Edit with Notepad按鈕，即可在記事本里添加新的參數(shù)，添加完后再次回車（不回車可能最后條數(shù)據(jù)讀取不到）關(guān)閉，參數(shù)化操作完成。

4）使用Ctrl +H鍵可以找到替換同樣的需要參數(shù)化的數(shù)據(jù)。

3.腳本跑流程過程中，因為業(yè)務(wù)運轉(zhuǎn)，前面生成的投保單要接著進行提交核保業(yè)務(wù)，而每次生成的投保單號不一樣，用于進行提交核保的單號也要與之前的保持一致，因此需要做關(guān)聯(lián)處理，讀取到生成的新投保單號給提交核保流程。關(guān)聯(lián)步驟：

1).查找關(guān)聯(lián)數(shù)據(jù)第一次出現(xiàn)的位置，判斷該數(shù)據(jù)是由什么函數(shù)返回的。

2).在樹形結(jié)構(gòu)里點擊返回該數(shù)據(jù)值的函數(shù)，看它的Server Response信息，用復(fù)制的關(guān)聯(lián)數(shù)據(jù)進行查找它的返回語句，找到區(qū)分度明顯的語句（不一定要是第一個返回語句），然后使用web_reg_save_param函數(shù)進行關(guān)聯(lián)。

注：關(guān)聯(lián)函數(shù)一定要寫在第一個返回該數(shù)據(jù)值的函數(shù)前。

3).web_reg_save_param(const char *ParamName, , LAST);

函數(shù)的第一個參數(shù)是用來對關(guān)聯(lián)數(shù)據(jù)進行定義的，取名最好可讀性強；第二個參數(shù)是用來標(biāo)識關(guān)聯(lián)數(shù)據(jù)在返回語句里的具體位置的，寫出該數(shù)據(jù)的左右邊界，程序才能識別；LAST表示屬性列的結(jié)束。比如辦理理賠業(yè)務(wù)的流程號，在服務(wù)器的返回語句里是：

做關(guān)聯(lián)為：

web_reg_save_param(“LogFlowID”，“LB=name=flowID type=”hidden“ value=”，“RB=>”，LAST);定義的參數(shù)名就叫LogFlowID,表示流程號，易于明白；左邊界從name取就可以標(biāo)識了，也可取長點或短點，只要能區(qū)分；右邊界只有>，寫上就好；最后寫上LAST。

在定義的左右邊界中，如果有雙引號，在腳本中是需要轉(zhuǎn)義的，因為雙引號在C中是有意義的，這里只要表示語句信息，加上右斜杠。尖括號直寫。

左右邊界也需要用雙引號括起來。定義好的參數(shù)寫在程序中，需要在加上單尖括號：swfLogFlowID={LogFlowID} 五． 腳本執(zhí)行過程中的報錯處理

1.vuser_init.c(3051): Error-26377: No match found for the requested parameter “proposalNo”.Check whether the requested boundaries exist in the response data.Also, if the data you want to save exceeds 256 bytes, use web_set_max_html_param_len to increase the parameter size [MsgId: MERR-26377] 2.vuser_init.c(3051): web_submit_data(“UIPrPoEnInputNext.jsp”)highest severity level was “ERROR”, 4312 body bytes, 258 header bytes [MsgId: MMSG-26388]

兩個錯誤一起出現(xiàn)，出錯語句都是在關(guān)聯(lián)函數(shù)下的提交數(shù)據(jù)函數(shù)位置，但是具體出錯有可能是：

1).關(guān)聯(lián)函數(shù)左右邊界沒寫對，所有信息都要用字符輸入，不能是中文或其他。

2).在關(guān)聯(lián)函數(shù)確認(rèn)寫對的情況下，看提交數(shù)據(jù)函數(shù)中的業(yè)務(wù)設(shè)置，比如有可能是因為保單查詢語句，設(shè)置的查詢時間是過去的時間，新生成的投保單當(dāng)然查不到，這樣程序也會報這樣的錯。

3.loadrunner 執(zhí)行理賠的立案處理，錄制好腳本后，回放，報錯：

腳本日志信息提示：

1.Action.c(400): Error-26366: “Text=立案信息提交成功” not found for web_reg_find [MsgId: MERR-26366] 2.Action.c(400): web_submit_data(“claimSave.do”)highest severity level was “ERROR”, 4424 body bytes, 258 header bytes [MsgId: MMSG-26388] 腳本執(zhí)行過程停止在立案信息提交頁面，錯誤原因：數(shù)據(jù)問題，可能是有的應(yīng)該變化的信息沒有變。

在該流程中，一個報案號只能做一次立案，而初始腳本沒有設(shè)置參數(shù)、關(guān)聯(lián)，使用保單號進行查詢，錯誤被掩蓋。在立案系統(tǒng)中，一個保單號可以重復(fù)報案，但是一個報案號只能一次立案，要跑通流程，需要先將這一保單再重復(fù)報案，得到新的報案號。

六． 性能測試的場景設(shè)置

腳本錄制完畢后，接著準(zhǔn)備測試場景。1.首先準(zhǔn)備測試數(shù)據(jù)。比如車險投保，需要投保人和車架號信息來唯一標(biāo)識一輛被保車，因此就需要將投保人和車架號做參數(shù)化處理，編輯文本框錄入大量數(shù)據(jù)讓腳本唯一讀?。?/p>

1）.錄入投保人參數(shù)，車架號參數(shù)，過程同腳本錄制的參數(shù)化處理

2）.因為投保人和車架號一起生成一條投保數(shù)據(jù)，可設(shè)置車架號隨投保人參數(shù)一起讀取，設(shè)置步驟為：

投保人文件存放路徑--File path

投保人參數(shù)數(shù)據(jù)讀取方式

腳本按列名讀取參數(shù)，每行數(shù)據(jù)讀取一次，每次循環(huán)取一次新值。接著設(shè)置車架號參數(shù)信息：

車架號參數(shù)讀取文件路徑設(shè)為和投保人文件路徑一樣

腳本按列名讀取參數(shù)，行號選擇和讀取的投保人數(shù)據(jù)同一行

這樣得到所需的投保單生成參數(shù)數(shù)據(jù)

2.設(shè)置測試場景

點擊Tools->Create Controller Scenarios,彈出場景類型選擇框：

錄入需要的虛擬用戶數(shù)，選擇生成結(jié)果存放路徑和組名。確定后進入具體設(shè)置頁面：

Quantity表示虛擬用戶個數(shù)，group name為組名。

1).設(shè)置運行時間選項Run – time Settings

選擇循環(huán)次數(shù)Run Logic->Iteration Count,設(shè)置循環(huán)10次，虛擬用戶數(shù)為之前設(shè)置的5人，則預(yù)計一共可生成50張投保單。

設(shè)置思考時間，思考時間通常是錄制腳本過程中，填寫頁面信息花費的時間，選擇忽略項，節(jié)省跑腳本的時間。

設(shè)置網(wǎng)絡(luò)連接時間，點擊網(wǎng)絡(luò)協(xié)議項Internet Protocol 的Options鍵，將彈出頁面里的HTTP-request connect timeout和 HTTP-request receive timeout的數(shù)值改為1000。使得能在網(wǎng)絡(luò)狀況不太好的情況下向服務(wù)器發(fā)送接收數(shù)據(jù)。

2).設(shè)置Edit Schedule

選擇虛擬用戶加載方式：

可以一次加載所有用戶，也可以按需要設(shè)置，一秒加載一個用戶或其他。

選擇結(jié)束方式：

當(dāng)選擇一秒加載一個用戶時，結(jié)束設(shè)置為直到跑完所有腳本停止執(zhí)行。如果選擇選擇一次加載所有用戶可以選擇運行多少時間后停止和不停止選項。

這些設(shè)置完成后，一次測試場景布置完成。可以進行基線檢查或單點并發(fā)測試。

七． 性能測試步驟

一）.除測試工具外性能測試必備的系統(tǒng)及業(yè)務(wù)知識

1、熟悉保險行業(yè)業(yè)務(wù)特點，有助于與開發(fā)和客戶討論需求，制定測試用例；

2、熟悉系統(tǒng)的實現(xiàn)特點，開發(fā)實現(xiàn)方式，有助于選擇程序處理復(fù)雜、消耗系統(tǒng)資源的用例點；

3、熟悉數(shù)據(jù)結(jié)構(gòu)，了解數(shù)據(jù)存儲規(guī)則，對腳本調(diào)試、數(shù)據(jù)準(zhǔn)備、測試執(zhí)行和監(jiān)視都有幫助；

4、熟悉系統(tǒng)所使用的數(shù)據(jù)庫、操作系統(tǒng)、中間件的監(jiān)視和性能問題查看，有助于測試監(jiān)視和發(fā)現(xiàn)問題；

5、熟悉系統(tǒng)架構(gòu)及系統(tǒng)集成方式，有助于分析及明確定位性能問題。

二)性能測試執(zhí)行過程 1.基線檢查

1).目的：驗證環(huán)境是否可用；

驗證腳本是否能在場景正常執(zhí)行。

2).方法：1個人單獨循環(huán)5次--沒有其他人干擾，干凈的環(huán)境

3).結(jié)果：一般一個事物的響應(yīng)時間超過3秒就可能存在問題，要提報開發(fā)人

2.單點并發(fā)

1).目的：為了快速的發(fā)現(xiàn)問題，如多進程的鎖機制，看是否相互間有影響。2).方法：一般是10人或20人執(zhí)行10到15分鐘，執(zhí)行過程忽略思考時間。

忽略思考時間可以減少客戶端時間，加快向服務(wù)器傳送數(shù)據(jù)速度，很大程度上增大了服務(wù)器的壓力，20個人單點并發(fā)的壓力就相當(dāng)于200人正常執(zhí)行帶給服務(wù)器的壓力。

3).單點測試的數(shù)據(jù)可以用來進行混發(fā)測試，但是有可能單點測試的數(shù)據(jù)不足以進行混發(fā)，需要自己再準(zhǔn)備足夠的數(shù)據(jù)。

3.方案測試--混發(fā)測試

1).目的：模擬生產(chǎn)環(huán)境

2).方法：執(zhí)行1小時左右，加上思考時間

八．資源監(jiān)控及調(diào)優(yōu)

性能測試執(zhí)行過程中，需要監(jiān)控系統(tǒng)各項資源，看是否能滿足用戶實際需要，如內(nèi)存使用，SQL SERVER等，結(jié)合LR生成的分析報告，分析系統(tǒng)哪里可能存在問題，需要改進，進行調(diào)優(yōu)，這也是我之后要接著進行學(xué)習(xí)的地方。

1.學(xué)習(xí)使用weblogic，了解weblogic常配參數(shù)的意義。通過weblogic自身的監(jiān)控臺，可以了解到目前的JVM的大小、數(shù)據(jù)庫連接池的使用情況以及目前連接的客戶端數(shù)量以及請求狀況等等。

2.學(xué)習(xí)oracle使用，熟悉它的體系結(jié)構(gòu)，尤其是oracle10里 的awr，awr能采集與統(tǒng)計數(shù)據(jù)，并從那些統(tǒng)計數(shù)據(jù)中導(dǎo)出性能量度，以跟蹤潛在的問題。

3.需要繼續(xù)學(xué)習(xí)LR的理論知識和實際操作，參考書籍《Web性能測試實戰(zhàn)》、《軟件性能測試過程詳解與案例剖析》

第二篇：LoadRunner測試總結(jié)

性能測試（并發(fā)負(fù)載壓力）測試分析－簡要篇

在論壇混了多日，發(fā)現(xiàn)越來越多的性能測試工程師基本上都能夠掌握利用測試工具來作負(fù)載壓力測試，但多數(shù)人對怎樣去分析工具收集到的測試結(jié)果感到無從下手，下面我就把個人工作中的體會和收集到的有關(guān)資料整理出來，希望能對大家分析測試結(jié)果有所幫助。

分析原則：

? 具體問題具體分析（這是由于不同的應(yīng)用系統(tǒng)，不同的測試目的，不同的性能關(guān)注點）? 查找瓶頸時按以下順序，由易到難。

服務(wù)器硬件瓶頸-〉網(wǎng)絡(luò)瓶頸（對局域網(wǎng)，可以不考慮）-〉服務(wù)器操作系統(tǒng)瓶頸（參數(shù)配置）-〉中間件瓶頸（參數(shù)配置，數(shù)據(jù)庫，web服務(wù)器等）-〉應(yīng)用瓶頸（SQL語句、數(shù)據(jù)庫設(shè)計、業(yè)務(wù)邏輯、算法等）注：以上過程并不是每個分析中都需要的，要根據(jù)測試目的和要求來確定分析的深度。對一些要求低的，我們分析到應(yīng)用系統(tǒng)在將來大的負(fù)載壓力（并發(fā)用戶數(shù)、數(shù)據(jù)量）下，系統(tǒng)的硬件瓶頸在哪兒就夠了。? 分段排除法 很有效

分析的信息來源：

?1 根據(jù)場景運行過程中的錯誤提示信息

?2 根據(jù)測試結(jié)果收集到的監(jiān)控指標(biāo)數(shù)據(jù)

一．錯誤提示分析

分析實例：?Error: Failed to connect to server “10.10.10.30:8080”: [10060] Connection

?Error: timed out Error: Server “10.10.10.30” has shut down the connection prematurely

分析：

?A、應(yīng)用服務(wù)死掉。

（小用戶時：程序上的問題。程序上處理數(shù)據(jù)庫的問題）

?B、應(yīng)用服務(wù)沒有死

（應(yīng)用服務(wù)參數(shù)設(shè)置問題）

例：在許多客戶端連接Weblogic應(yīng)用服務(wù)器被拒絕，而在服務(wù)器端沒有錯誤顯示，則有可能是Weblogic中的server元素的AcceptBacklog屬性值設(shè)得過低。如果連接時收到connection refused消息，說明應(yīng)提高該值，每次增加25％

?C、數(shù)據(jù)庫的連接

（1、在應(yīng)用服務(wù)的性能參數(shù)可能太小了

2、數(shù)據(jù)庫啟動的最大連接數(shù)（跟硬件的內(nèi)存有關(guān)）)

2Error: Page download timeout(120 seconds)has expired

分析：可能是以下原因造成?A、應(yīng)用服務(wù)參數(shù)設(shè)置太大導(dǎo)致服務(wù)器的瓶頸

?B、頁面中圖片太多

?C、在程序處理表的時候檢查字段太大多

二．監(jiān)控指標(biāo)數(shù)據(jù)分析

1．最大并發(fā)用戶數(shù)：

應(yīng)用系統(tǒng)在當(dāng)前環(huán)境（硬件環(huán)境、網(wǎng)絡(luò)環(huán)境、軟件環(huán)境（參數(shù)配置））下能承受的最大并發(fā)用戶數(shù)。在方案運行中，如果出現(xiàn)了大于3個用戶的業(yè)務(wù)操作失敗，或出現(xiàn)了服務(wù)器shutdown的情況，則說明在當(dāng)前環(huán)境下，系統(tǒng)承受不了當(dāng)前并發(fā)用戶的負(fù)載壓力，那么最大并發(fā)用戶數(shù)就是前一個沒有出現(xiàn)這種現(xiàn)象的并發(fā)用戶數(shù)。

如果測得的最大并發(fā)用戶數(shù)到達(dá)了性能要求，且各服務(wù)器資源情況良好，業(yè)務(wù)操作響應(yīng)時間也達(dá)到了用戶要求，那么OK。否則，再根據(jù)各服務(wù)器的資源情況和業(yè)務(wù)操作響應(yīng)時間進一步分析原因所在。

2．業(yè)務(wù)操作響應(yīng)時間：

? 分析方案運行情況應(yīng)從平均事務(wù)響應(yīng)時間圖和事務(wù)性能摘要圖開始。使用“事務(wù)性能摘要”圖，可以確定在方案執(zhí)行期間響應(yīng)時間過長的事務(wù)。

? 細(xì)分事務(wù)并分析每個頁面組件的性能。查看過長的事務(wù)響應(yīng)時間是由哪些頁面組件引起的？問題是否與網(wǎng)絡(luò)或服務(wù)器有關(guān)？

? 如果服務(wù)器耗時過長，請使用相應(yīng)的服務(wù)器圖確定有問題的服務(wù)器度量并查明服務(wù)器性能下降的原因。如果網(wǎng)絡(luò)耗時過長，請使用“網(wǎng)絡(luò)監(jiān)視器”圖確定導(dǎo)致性能瓶頸的網(wǎng)絡(luò)問題

3．服務(wù)器資源監(jiān)控指標(biāo)：

內(nèi)存：UNIX資源監(jiān)控中指標(biāo)內(nèi)存頁交換速率（Paging rate），如果該值偶爾走高，表明當(dāng)時有線程競爭內(nèi)存。如果持續(xù)很高，則內(nèi)存可能是瓶頸。也可能是內(nèi)存訪問命中率低。Windows資源監(jiān)控中，如果ProcessPrivate Bytes計數(shù)器和ProcessWorking Set計數(shù)器的值在長時間內(nèi)持續(xù)升高，同時MemoryAvailable bytes計數(shù)器的值持續(xù)降低，則很可能存在內(nèi)存泄漏。

內(nèi)存資源成為系統(tǒng)性能的瓶頸的征兆:

很高的換頁率(high pageout rate);

進程進入不活動狀態(tài);

交換區(qū)所有磁盤的活動次數(shù)可高;

可高的全局系統(tǒng)CPU利用率;

內(nèi)存不夠出錯(out of memory errors)

處理器：UNIX資源監(jiān)控（Windows操作系統(tǒng)同理）中指標(biāo)CPU占用率（CPU utilization），如果該值持續(xù)超過95%，表明瓶頸是CPU?？梢钥紤]增加一個處理器或換一個更快的處理器。如果服務(wù)器專用于SQL Server,可接受的最大上限是80-85%

合理使用的范圍在60%至70%。Windows資源監(jiān)控中，如果SystemProcessor Queue Length大于2，而處理器利用率（Processor Time）一直很低，則存在著處理器阻塞。

CPU資源成為系統(tǒng)性能的瓶頸的征兆:

很慢的響應(yīng)時間(slow response time)

CPU空閑時間為零(zero percent idle CPU)

過高的用戶占用CPU時間(high percent user CPU)

過高的系統(tǒng)占用CPU時間(high percent system CPU)

長時間的有很長的運行進程隊列(large run queue size sustained over time)

磁盤I/O：UNIX資源監(jiān)控（Windows操作系統(tǒng)同理）中指標(biāo)磁盤交換率（Disk rate），如果該參數(shù)值一直很高，表明I/O有問題?？煽紤]更換更快的硬盤系統(tǒng)。Windows資源監(jiān)控中，如果 Disk Time和Avg.Disk Queue Length的值很高，而Page Reads/sec頁面讀取操作速率很低，則可能存在磁盤瓶徑。

I/O資源成為系統(tǒng)性能的瓶頸的征兆 :

過高的磁盤利用率(high disk utilization)

太長的磁盤等待隊列(large disk queue length)

等待磁盤I/O的時間所占的百分率太高(large percentage of time waiting for disk I/O)太高的物理I/O速率:large physical I/O rate(not sufficient in itself)

過低的緩存命中率(low buffer cache hit ratio(not sufficient in itself))

太長的運行進程隊列，但CPU卻空閑(large run queue with idle CPU)

4．?dāng)?shù)據(jù)庫服務(wù)器：

SQL Server數(shù)據(jù)庫：SQLServer資源監(jiān)控中指標(biāo)緩存點擊率（Cache Hit Ratio），該值越高越好。如果持續(xù)低于80%，應(yīng)考慮增加內(nèi)存。如果Full Scans/sec（全表掃描/秒）計數(shù)器顯示的值比1或2高，則應(yīng)分析你的查詢以確定是否確實需要全表掃描，以及SQL查詢是否可以被優(yōu)化。Number of Deadlocks/sec(死鎖的數(shù)量/秒)：死鎖對應(yīng)用程序的可伸縮性非常有害，并且會導(dǎo)致惡劣的用戶體驗。該計數(shù)器的值必須為0。Lock Requests/sec(鎖請求/秒)，通過優(yōu)化查詢來減少讀取次數(shù)，可以減少該計數(shù)器的值。

Oracle數(shù)據(jù)庫：如果自由內(nèi)存接近于0而且?guī)炜齑婊驍?shù)據(jù)字典快存的命中率小于0.90，那么需要增加

SHARED_POOL_SIZE的大小。

快存（共享SQL區(qū)）和數(shù)據(jù)字典快存的命中率：

select(sum(pins-reloads))/sum(pins)from v$librarycache;

select(sum(gets-getmisses))/sum(gets)from v$rowcache;

自由內(nèi)存：select * from v$sgastat where name=’free memory’;如果數(shù)據(jù)的緩存命中率小于0.90，那么需要加大DB_BLOCK_BUFFERS參數(shù)的值（單位：塊）。緩沖區(qū)高速緩存命中率：

select name,value from v$sysstat where name in('db block gets’,'consistent gets','physical reads');

Hit Ratio = 1-(physical reads /(db block gets + consistent gets))如果日志緩沖區(qū)申請的值較大，則應(yīng)加大LOG_BUFFER參數(shù)的值。

日志緩沖區(qū)的申請情況 ：

select name,value from v$sysstat where name = 'redo log space requests';如果內(nèi)存排序命中率小于0.95，則應(yīng)加大SORT_AREA_SIZE以避免磁盤排序。

內(nèi)存排序命中率 ：

select round((100*b.value)/decode((a.value+b.value), 0, 1,(a.value+b.value)), 2)from v$sysstat a, v$sysstat b where a.name='sorts(disk)' and b.name='sorts(memory)'

注：上述SQL Server和Oracle數(shù)據(jù)庫分析，只是一些簡單、基本的分析，特別是Oracle數(shù)據(jù)庫的分析和優(yōu)化，是一門專門的技術(shù)，進一步的分析可查相關(guān)資料。

說明：

以上只是個人的體會和部分資料的整理，并不代表專家之言。算拋磚引玉，有不同看法和更深入的分析的，希望大家勇要發(fā)言，以推動我們國內(nèi)的性能測試工作。

第三篇：loadrunner計數(shù)器分析總結(jié)

Loadrunner性能計數(shù)器分析總結(jié)

2009-12-02 14:48

Memory: 內(nèi)存使用情況可能是系統(tǒng)性能中最重要的因素。如果系統(tǒng)“頁交換”頻繁，說明內(nèi)存不足?！绊摻粨Q”是使用稱為“頁面”的單位，將固定大小的代碼和數(shù)據(jù)塊從 RAM 移動到磁盤的過程，其目的是為了釋放內(nèi)存空間。盡管某些頁交換使 Windows 2000 能夠使用比實際更多的內(nèi)存，也是可以接受的，但頻繁的頁交換將降低系統(tǒng)性能。減少頁交換將顯著提高系統(tǒng)響應(yīng)速度。要監(jiān)視內(nèi)存不足的狀況，請從以下的對象計數(shù)器開始：

Available Mbytes:可用物理內(nèi)存數(shù).如果Available Mbytes的值很?。? MB 或更?。?，則說明計算機上總的內(nèi)存可能不足，或某程序沒有釋放內(nèi)存。

page/sec: 表明由于硬件頁面錯誤而從磁盤取出的頁面數(shù)，或由于頁面錯誤而寫入磁盤以釋放工作集空間的頁面數(shù)。一般如果pages/sec持續(xù)高于幾百，那么您應(yīng)該進一步研究頁交換活動。有可能需要增加內(nèi)存，以減少換頁的需求（你可以把這個數(shù)字乘以4k就得到由此引起的硬盤數(shù)據(jù)流量）。Pages/sec 的值很大不一定表明內(nèi)存有問題，而可能是運行使用內(nèi)存映射文件的程序所致。

page read/sec:頁的硬故障，page/sec的子集，為了解析對內(nèi)存的引用，必須讀取頁文件的次數(shù)。閾值為>5.越低越好。大數(shù)值表示磁盤讀而不是緩存讀。由于過多的頁交換要使用大量的硬盤空間，因此有可能將導(dǎo)致將頁交換內(nèi)存不足與導(dǎo)致頁交換的磁盤瓶徑混淆。因此，在研究內(nèi)存不足不太明顯的頁交換的原因時，您必須跟蹤如下的磁盤使用情況計數(shù)器和內(nèi)存計數(shù)器：

Physical Disk % Disk Time

Physical Disk Avg.Disk Queue Length

例如，包括 Page Reads/sec 和 % Disk Time 及 Avg.Disk Queue Length。如果頁面讀取操作速率很低，同時 % Disk Time 和 Avg.Disk Queue Length的值很高，則可能有磁盤瓶徑。但是，如果隊列長度增加的同時頁面讀取速率并未降低，則內(nèi)存不足。

要確定過多的頁交換對磁盤活動的影響，請將 Physical Disk Avg.Disk

sec/Transfer 和 Memory Pages/sec 計數(shù)器的值增大數(shù)倍。如果這些計數(shù)器的計數(shù)結(jié)果超過了 0.1，那么頁交換將花費百分之十以上的磁盤訪問時間。如果長時間發(fā)生這種情況，那么您可能需要更多的內(nèi)存。

Page Faults/sec:每秒軟性頁面失效的數(shù)目（包括有些可以直接在內(nèi)存中滿足而有些需要從硬盤讀取）較page/sec只表明數(shù)據(jù)不能在內(nèi)存的指定工作集中立即使用。

Cache Bytes：文件系統(tǒng)緩存（File System Cache），默認(rèn)情況下為50%的可用物理內(nèi)存。如IIS5.0 運行內(nèi)存不夠時，它會自動整理緩存。需要關(guān)注該計數(shù)器的趨勢變化

如果您懷疑有內(nèi)存泄露，請監(jiān)視 Memory Available Bytes 和 Memory

Committed Bytes，以觀察內(nèi)存行為，并監(jiān)視您認(rèn)為可能在泄露內(nèi)存的進程的 ProcessPrivate Bytes、ProcessWorking Set 和ProcessHandle Count。如果您懷疑是內(nèi)核模式進程導(dǎo)致了泄露，則還應(yīng)該監(jiān)視 MemoryPool Nonpaged Bytes、Memory Pool Nonpaged Allocs 和 Process(process_name)Pool Nonpaged Bytes。

Pages per second :每秒鐘檢索的頁數(shù)。該數(shù)字應(yīng)少于每秒一頁。

Process：

%Processor Time: 被處理器消耗的處理器時間數(shù)量。如果服務(wù)器專用于sql server,可接受的最大上限是80-85%

Page Faults/sec:將進程產(chǎn)生的頁故障與系統(tǒng)產(chǎn)生的相比較，以判斷這個進程對系統(tǒng)頁故障產(chǎn)生的影響。

Work set: 處理線程最近使用的內(nèi)存頁，反映了每一個進程使用的內(nèi)存頁的數(shù)量。如果服務(wù)器有足夠的空閑內(nèi)存，頁就會被留在工作集中，當(dāng)自由內(nèi)存少于一個特定的閾值時，頁就會被清除出工作集。

Inetinfo:Private Bytes:此進程所分配的無法與其它進程共享的當(dāng)前字節(jié)數(shù)

量。如果系統(tǒng)性能隨著時間而降低，則此計數(shù)器可以是內(nèi)存泄漏的最佳指示器。Processor：監(jiān)視“處理器”和“系統(tǒng)”對象計數(shù)器可以提供關(guān)于處理器使用的有價值的信息，幫助您決定是否存在瓶頸。

%Processor Time:如果該值持續(xù)超過95%，表明瓶頸是CPU?？梢钥紤]增加一個處理器或換一個更快的處理器。

%User Time:表示耗費CPU的數(shù)據(jù)庫操作，如排序，執(zhí)行aggregate functions等。如果該值很高，可考慮增加索引，盡量使用簡單的表聯(lián)接，水平分割大表格等方法來降低該值。

%Privileged Time：（CPU內(nèi)核時間）是在特權(quán)模式下處理線程執(zhí)行代碼所花時間的百分比。如果該參數(shù)值和“Physical Disk”參數(shù)值一直很高，表明I/O有問題。可考慮更換更快的硬盤系統(tǒng)。另外設(shè)置Tempdb in RAM，減低“max async IO”，“max lazy writer IO”等措施都會降低該值。

此外，跟蹤計算機的服務(wù)器工作隊列當(dāng)前長度的 Server Work Queues Queue Length 計數(shù)器會顯示出處理器瓶頸。隊列長度持續(xù)大于 4 則表示可能出現(xiàn)處理器擁塞。此計數(shù)器是特定時間的值，而不是一段時間的平均值。

% DPC Time:越低越好。在多處理器系統(tǒng)中，如果這個值大于50%并且Processor:% Processor Time非常高，加入一個網(wǎng)卡可能會提高性能，提供的網(wǎng)絡(luò)已經(jīng)不飽和。

Thread

ContextSwitches/sec:(實例化inetinfo 和dllhost 進程)如果你決定要增加線程字節(jié)池的大小，你應(yīng)該監(jiān)視這三個計數(shù)器（包括上面的一個）。增加線程數(shù)可能會增加上下文切換次數(shù)，這樣性能不會上升反而會下降。如果十個實例的上下文切換值非常高，就應(yīng)該減小線程字節(jié)池的大小。

Physical Disk:

%Disk Time %:指所選磁盤驅(qū)動器忙于為讀或?qū)懭胝埱筇峁┓?wù)所用的時間的百分比。如果三個計數(shù)器都比較大，那么硬盤不是瓶頸。如果只有%Disk Time比較大，另外兩個都比較適中，硬盤可能會是瓶頸。在記錄該計數(shù)器之前，請在Windows 2000 的命令行窗口中運行diskperf-yD。若數(shù)值持續(xù)超過80%，則可能是內(nèi)存泄漏。

Avg.Disk Queue Length:指讀取和寫入請求(為所選磁盤在實例間隔中列隊的)的平均數(shù)。該值應(yīng)不超過磁盤數(shù)的1.5~2 倍。要提高性能，可增加磁盤。注意：一個Raid Disk實際有多個磁盤。

Average Disk Read/Write Queue Length:指讀取(寫入)請求(列隊)的平均數(shù)。Disk Reads(Writes)/s: 物理磁盤上每秒鐘磁盤讀、寫的次數(shù)。兩者相加，應(yīng)小于磁盤設(shè)備最大容量。

Average Disksec/Read: 指以秒計算的在此盤上讀取數(shù)據(jù)的所需平均時間。Average Disk sec/Transfer:指以秒計算的在此盤上寫入數(shù)據(jù)的所需平均時間。Network Interface：

Bytes Total/sec :為發(fā)送和接收字節(jié)的速率，包括幀字符在內(nèi)。判斷網(wǎng)絡(luò)連接速度是否是瓶頸，可以用該計數(shù)器的值和目前網(wǎng)絡(luò)的帶寬比較

SQLServer性能計數(shù)器：

Access Methods(訪問方法)用于監(jiān)視訪問數(shù)據(jù)庫中的邏輯頁的方法。

.Full Scans/sec(全表掃描/秒)每秒不受限的完全掃描數(shù)?？梢允腔颈頀呙杌蛉饕龗呙?。如果這個計數(shù)器顯示的值比1或2高，應(yīng)該分析你的查詢以確定是否確實需要全表掃描，以及S Q L查詢是否可以被優(yōu)化。

.Page splits/sec(頁分割/秒)由于數(shù)據(jù)更新操作引起的每秒頁分割的數(shù)量。Buffer Manager(緩沖器管理器)：監(jiān)視 Microsoft? SQL Server? 如何使用： 內(nèi)存存儲數(shù)據(jù)頁、內(nèi)部數(shù)據(jù)結(jié)構(gòu)和過程高速緩存；計數(shù)器在 SQL Server 從磁盤讀取數(shù)據(jù)庫頁和將數(shù)據(jù)庫頁寫入磁盤時監(jiān)視物理 I/O。監(jiān)視 SQL Server 所使用的內(nèi)存和計數(shù)器有助于確定： 是否由于缺少可用物理內(nèi)存存儲高速緩存中經(jīng)常訪問的數(shù)據(jù)而導(dǎo)致瓶頸存在。如果是這樣，SQL Server 必須從磁盤檢索數(shù)據(jù)。是否可通過添加更多內(nèi)存或使更多內(nèi)存可用于數(shù)據(jù)高速緩存或 SQL Server 內(nèi)部結(jié)構(gòu)來提高查詢性能。

SQL Server 需要從磁盤讀取數(shù)據(jù)的頻率。與其它操作相比，例如內(nèi)存訪問，物理 I/O 會耗費大量時間。盡可能減少物理 I/O 可以提高查詢性能。

.Page Reads/sec：每秒發(fā)出的物理數(shù)據(jù)庫頁讀取數(shù)。這一統(tǒng)計信息顯示的是在所有數(shù)據(jù)庫間的物理頁讀取總數(shù)。由于物理 I/O 的開銷大，可以通過使用更大的數(shù)據(jù)高速緩存、智能索引、更高效的查詢或者改變數(shù)據(jù)庫設(shè)計等方法，使開銷減到最小。

.Page Writes/sec(.寫的頁/秒)每秒執(zhí)行的物理數(shù)據(jù)庫寫的頁數(shù)。

.Buffer Cache Hit Ratio.在“緩沖池”（Buffer Cache/Buffer Pool）中沒有被讀過的頁占整個緩沖池中所有頁的比率?？稍诟咚倬彺嬷姓业蕉恍枰獜拇疟P中讀取的頁的百分比。這一比率是高速緩存命中總數(shù)除以自 SQL Server 實例啟動后對高速緩存的查找總數(shù)。經(jīng)過很長時間后，這一比率的變化很小。由于從高速緩存中讀數(shù)據(jù)比從磁盤中讀數(shù)據(jù)的開銷要小得多，一般希望這一數(shù)值高一些。通常，可以通過增加 SQL Server 可用的內(nèi)存數(shù)量來提高高速緩存命中率。計數(shù)器值依應(yīng)用程序而定，但比率最好為90% 或更高。增加內(nèi)存直到這一數(shù)值持續(xù)高于90%，表示90% 以上的數(shù)據(jù)請求可以從數(shù)據(jù)緩沖區(qū)中獲得所需數(shù)據(jù)。.Lazy Writes/sec(惰性寫/秒)惰性寫進程每秒寫的緩沖區(qū)的數(shù)量。值最好為0。Cache Manager(高速緩存管理器)對象提供計數(shù)器，用于監(jiān)視 Microsoft? SQL Server? 如何使用內(nèi)存存儲對象，如存儲過程、特殊和準(zhǔn)備好的 Transact-SQL 語句以及觸發(fā)器。

.Cache Hit Ratio(高速緩存命中率，所有Cache”的命中率。在SQL Server中，Cache可以包括Log Cache，Buffer Cache以及Procedure Cache，是一個總體的比率。)高速緩存命中次數(shù)和查找次數(shù)的比率。對于查看SQL Server高

速緩存對于你的系統(tǒng)如何有效，這是一個非常好的計數(shù)器。如果這個值很低，持續(xù)低于80%，就需要增加更多的內(nèi)存。

Latches(閂)用于監(jiān)視稱為閂鎖的內(nèi)部 SQL Server 資源鎖。監(jiān)視閂鎖以明確用戶活動和資源使用情況，有助于查明性能瓶頸。

.Average Latch Wait Ti m e(m s)(平均閂等待時間(毫秒))一個SQL Server線程必須等待一個閂的平均時間，以毫秒為單位。如果這個值很高，你可能正經(jīng)歷嚴(yán)重的競爭問題。

.Latch Waits/sec(閂等待/秒)在閂上每秒的等待數(shù)量。如果這個值很高，表明你正經(jīng)歷對資源的大量競爭。

Locks(鎖)提供有關(guān)個別資源類型上的 SQL Server 鎖的信息。鎖加在 SQL Server 資源上（如在一個事務(wù)中進行的行讀取或修改），以防止多個事務(wù)并發(fā)使用資源。例如，如果一個排它(X)鎖被一個事務(wù)加在某一表的某一行上，在這個鎖被釋放前，其它事務(wù)都不可以修改這一行。盡可能少使用鎖可提高并發(fā)性，從而改善性能?？梢酝瑫r監(jiān)視 Locks 對象的多個實例，每個實例代表一個資源類型上的一個鎖。

.Number of Deadlocks/sec(死鎖的數(shù)量/秒)導(dǎo)致死鎖的鎖請求的數(shù)量

.Average Wait Time(ms)(平均等待時間(毫秒))線程等待某種類型的鎖的平均等待時間

.Lock Requests/sec(鎖請求/秒)每秒鐘某種類型的鎖請求的數(shù)量。

Memory manager:用于監(jiān)視總體的服務(wù)器內(nèi)存使用情況，以估計用戶活動和資源使用，有助于查明性能瓶頸。監(jiān)視 SQL Server 實例所使用的內(nèi)存有助于確定：是否由于缺少可用物理內(nèi)存存儲高速緩存中經(jīng)常訪問的數(shù)據(jù)而導(dǎo)致瓶頸存在。如果是這樣，SQL Server 必須從磁盤檢索數(shù)據(jù)。

是否可以通過添加更多內(nèi)存或使更多內(nèi)存可用于數(shù)據(jù)高速緩存或 SQL Server 內(nèi)部結(jié)構(gòu)來提高查詢性能。

Lock blocks:服務(wù)器上鎖定塊的數(shù)量，鎖是在頁、行或者表這樣的資源上。不希望看到一個增長的值。

Total server memory：sql server服務(wù)器當(dāng)前正在使用的動態(tài)內(nèi)存總量.監(jiān)視IIS需要的一些計數(shù)器

Internet Information Services Global:

File Cache Hits %、File CacheFlushes、File Cache Hits

File Cache Hits %是全部緩存請求中緩存命中次數(shù)所占的比例，反映了IIS 的文件緩存設(shè)置的工作情況。對于一個大部分是靜態(tài)網(wǎng)頁組成的網(wǎng)站，該值應(yīng)該保持在80%左右。而File Cache Hits是文件緩存命中的具體值，F(xiàn)ile CacheFlushes 是自服務(wù)器啟動之后文件緩存刷新次數(shù)，如果刷新太慢，會浪費內(nèi)存；如果刷新太快，緩存中的對象會太頻繁的丟棄生成，起不到緩存的作用。通過比較File Cache Hits 和File Cache Flushes 可得出緩存命中率對緩存清空率的比率。通過觀察它兩個的值，可以得到一個適當(dāng)?shù)乃⑿轮担▍⒖糏IS 的設(shè)置

ObjectTTL、MemCacheSize、MaxCacheFileSize）

Web Service:

Bytes Total/sec:顯示W(wǎng)eb服務(wù)器發(fā)送和接受的總字節(jié)數(shù)。低數(shù)值表明該IIS正在以較低的速度進行數(shù)據(jù)傳輸。

Connection Refused：數(shù)值越低越好。高數(shù)值表明網(wǎng)絡(luò)適配器或處理器存在瓶頸。

Not Found Errors：顯示由于被請求文件無法找到而無法由服務(wù)器滿足的請求數(shù)（HTTP狀態(tài)代碼404）

監(jiān)視內(nèi)存計數(shù)器（補充）

要監(jiān)視內(nèi)存不足的狀況，請從以下的對象計數(shù)器開始：

內(nèi)存信息：

Memory Available Bytes

Memory Pages/sec

Memory Available Bytes

如果您懷疑有內(nèi)存泄露，請監(jiān)視 MemoryAvailable Bytes 和 Memory

Committed Bytes，以觀察內(nèi)存行為，并監(jiān)視您認(rèn)為可能在泄露內(nèi)存的進程的 Process Private Bytes、Process Working Set 和Process Handle Count。如果您懷疑是內(nèi)核模式進程導(dǎo)致了泄露，則還應(yīng)該監(jiān)視 Memory Pool Nonpaged Bytes、Memory Pool Nonpaged Allocs 和 Process(process_name)Pool Nonpaged Bytes。

CPU信息：

Processor % Processor Time 獲得處理器使用情況。

也可以選擇監(jiān)視 Processor % User Time 和 % Privileged Time 以獲得詳細(xì)信息。

Server Work Queues Queue Length 計數(shù)器會顯示出處理器瓶頸。隊列長度持續(xù)大于 4 則表示可能出現(xiàn)處理器擁塞。

System Processor Queue Length 用于瓶頸檢測

通過使用 Process % Processor Time 和 Process Working Set

Process % Processor Time過程的所有線程在每個處理器上的處理器時間總和。

硬盤信息：

Physical Disk % Disk Time

Physical Disk Avg.Disk Queue Length

例如，包括 Page Reads/sec 和 % Disk Time 及 Avg.Disk Queue Length。如果頁面讀取操作速率很低，同時 % Disk Time 和 Avg.Disk Queue Length的值很高，則可能有磁盤瓶徑。但是，如果隊列長度增加的同時頁面讀取速率并未降低，則內(nèi)存不足。

Physical Disk % Disk Time

Physical Disk Avg.Disk Queue Length

例如，包括 Page Reads/sec 和 % Disk Time 及 Avg.Disk Queue Length。如果頁面讀取操作速率很低，同時 % Disk Time 和 Avg.Disk Queue Length的值很高，則可能有磁盤瓶徑。但是，如果隊列長度增加的同時頁面讀取速率并未降低，則內(nèi)存不足。

請觀察 Processor Interrupts/sec 計數(shù)器的值，該計數(shù)器測量來自輸入/輸出

(I/O)設(shè)備的服務(wù)請求的速度。如果此計數(shù)器的值明顯增加，而系統(tǒng)活動沒有相應(yīng)增加，則表明存在硬件問題。

Physical Disk Disk Reads/sec and Disk Writes/sec

Physical Disk Current Disk Queue Length

Physical Disk % Disk Time

LogicalDisk % Free Space

測試磁盤性能時，將性能數(shù)據(jù)記錄到另一個磁盤或計算機，以便這些數(shù)據(jù)不會干擾您正在測試的磁盤。

可能需要觀察的附加計數(shù)器包括 Physical Disk Avg.Disk sec/Transfer、Avg.Disk Bytes/Transfer，和 Disk Bytes/sec。

Avg.Disk sec/Transfer 計數(shù)器反映磁盤完成請求所用的時間。較高的值表明磁盤控制器由于失敗而不斷重試該磁盤。這些故障會增加平均磁盤傳送時間。對于大多數(shù)磁盤，較高的磁盤平均傳送時間是大于 0.3 秒。

也可以查看 Avg.Disk Bytes/Transfer 的值。值大于 20 KB 表示該磁盤驅(qū)動器通常運行良好；如果應(yīng)用程序正在訪問磁盤，則會產(chǎn)生較低的值。例如，隨機訪問磁盤的應(yīng)用程序會增加平均 Disk sec/Transfer 時間，因為隨機傳送需要增加搜索時間。

Disk Bytes/sec 提供磁盤系統(tǒng)的吞吐率。

決定工作負(fù)載的平衡

要平衡網(wǎng)絡(luò)服務(wù)器上的負(fù)載，需要了解服務(wù)器磁盤驅(qū)動器的繁忙程度。使用 Physical Disk % Disk Time 計數(shù)器，該計數(shù)器顯示驅(qū)動器活動時間的百分比。如果 % Disk Time 較高（超過 90%），請檢查 Physical Disk Current Disk Queue Length 計數(shù)器以查看正在等待磁盤訪問的系統(tǒng)請求數(shù)量。等待 I/O 請求的數(shù)量應(yīng)當(dāng)保持在不大于組成物理磁盤的主軸數(shù)的 1.5 到 2 倍。

盡管廉價磁盤冗余陣列(RAID)設(shè)備通常有多個主軸，大多數(shù)磁盤有一個主軸。硬件 RAID 設(shè)備在“系統(tǒng)監(jiān)視器”中顯示為一個物理磁盤；通過軟件創(chuàng)建的 RAID 設(shè)備顯示為多個驅(qū)動器（實例）?？梢员O(jiān)視每個物理驅(qū)動器（而不是 RAID）的 Physical Disk 計數(shù)器，也可以使用 _Total 實例來監(jiān)視所有計算機驅(qū)動器的數(shù)據(jù)。

使用 Current Disk Queue Length 和 % Disk Time 計數(shù)器來檢測磁盤子系統(tǒng)的瓶頸。如果 Current Disk Queue Length 和 % Disk Time 的值始終較高，可以考慮升級磁盤驅(qū)動器或?qū)⒛承┪募苿拥狡渌疟P或服務(wù)器。

第四篇：loadrunner使用cookie模擬

loadrunner使用cookie模擬

自己的工作總結(jié)，大家討論討論

1為什么要使用cookie模擬

從日常項目測試過程中的問題說起。

比如要進行論壇中的文件下載功能的測試。我們都知道只有登錄用戶才能進行下載操作，這樣我們的測試過程可能就變成了先登錄系統(tǒng)，然后再進行下載操作。在使用loadrunner設(shè)計腳本時就要先在初始化部分寫登錄腳本，然后再action中寫下載操作，當(dāng)單個用戶運行時我們可能看不到什么問題。當(dāng)用戶并發(fā)量較多時，問題馬上暴露出來了。大部分用戶可能很長時間也沒有下載成功，大量的初始化登錄操作已經(jīng)給系統(tǒng)造成了很大的壓力，而在日常訪問中，這種大量短時間登錄的壓力是不容易出現(xiàn)的。這樣的測試結(jié)果可能無法達(dá)到我們的測試目標(biāo)。的確，不能處理較大的登錄吞吐可能已經(jīng)是系統(tǒng)的瓶頸了，我們可以通過這種全流程的測試方式發(fā)現(xiàn)登錄的問題。但是后續(xù)的測試我們可能就無法進行下去了。當(dāng)項目組解決了登錄的吞吐問題時，可能項目工期已經(jīng)十分緊張了，再進行重要的下載功能測試可能已經(jīng)太晚了。

這種情況在測試過程中經(jīng)常會出現(xiàn)，我們要如何繞過登錄盡早的進行后續(xù)的下載操作呢？如果網(wǎng)站使用了cookie的機制，則我們可以嘗試使用下面的方法。

2怎么使用loadrunner模擬

Loadrunner的web函數(shù)中提供了幾個關(guān)于cookie的函數(shù)。

web_remove_cookie()

web_add_cookie()

web_cleanup_cookies();

web_reg_add_cookie();

這里我們?yōu)榱四Mcookie繞過登錄使用web_add_cookie();

首先獲取網(wǎng)站留在客戶端上的cookie都存儲了什么。通常主要內(nèi)容包括名字，值，過期時間，作用域和路徑，分為會話cookie和文件cookie。會話cookie存儲在內(nèi)存里，關(guān)閉瀏覽器后就沒有了，這種很難模擬。文件cookie是將cookie信息寫到硬盤上，關(guān)閉瀏覽器再次打開后仍可以使用。我們要模擬的就是這種存儲在硬盤文件里的cookie。我們觀察cookie文件的內(nèi)容，如果使用ie的話，在“C:Documents and Settings用戶名Local SettingsTemporary Internet Files”中的用戶名@域名的文件里，cookie存儲都是加密的，所以我們直接看并看不出什么特別的東西，也搞不清楚具體是什么。這時我們借助IE webdeveloper 工具獲取cookie值如下所示：

cdb_cookietime=2592000;cdb_smile=1D1;cdb_sid=71WKOd;cdb_auth=TzsVl16XRFahjqkfuWyoF5OzI%2BrekHgiy0YXJd8m1y9vq6aV4bg3GGMsa9s;cdb_visitedfid=20;cdb_onlineusernum=28

獲得了cookie信息后，我們進行編輯loadrunner腳本。將cookie每個分號分行，使用UltraEdit進行列模式操作，在每句后面加上域名。（域名在webdeveloper的Attributes下也可以找到domain對應(yīng)值），修改完成后如下。

web_add_cookie(“cdb_cookietime=2592000;domain=172.16.1.3”);

web_add_cookie(“cdb_smile=1D1;domain=172.16.1.3”);

web_add_cookie(“cdb_sid=71WKOd;domain=172.16.1.3”);

web_add_cookie(“cdb_auth=TzsVl16XRFahjqkfuWyoF5OzI%2BrekHgiy0YXJd8m1y9vq6aV4b

g3GGMsa9s;domain=172.16.1.3”);

web_add_cookie(“cdb_visitedfid=20;domain=172.16.1.3”);

web_add_cookie(“cdb_onlineusernum=28;domain=172.16.1.3”);

把這些值放在要訪問的url的web函數(shù)之前，你就可以繞過登錄進行后續(xù)操作了。如:

Action()

{

web_add_cookie(“cdb_cookietime=2592000;DOMAIN=172.16.1.3”);

web_add_cookie(“cdb_smile=1D1;DOMAIN=172.16.1.3”);

web_add_cookie(“cdb_oldtopics=D280D39523D39418D;DOMAIN=172.16.1.3”);

web_add_cookie(“cdb_sid=eSuWgw;DOMAIN=172.16.1.3”);

web_add_cookie(“cdb_auth=TzsVl16XRFahjqkfuWyoF5OzI%2BrekHgiy0YXJd8m1y9vq6aV4bg3GGMsa9s;DOMAIN=172.16.1.3”);

web_add_cookie(“cdb_visitedfid=20;DOMAIN=172.16.1.3”);

web_url(“cookies”,“URL=http://172.16.1.3:8080/bbs/index.php”,“referer=http://172.16.1.3/newiweb/index/dealIndex.do?action=Index”,“Mode=HTML”,“RecContentType=text/html”,LAST);

return 0;

}

最后注明一下：loadrunner的web錄制功能是自動的增加cookie的，只要在cookie不過期的情況下，我們不需要手工的增加cookie，當(dāng)出現(xiàn)錄制不上或錄制的值發(fā)生變化時可以手工進行添加。

在loadrunner場景設(shè)計使用其他負(fù)載機器時，同樣可以使用你本機的這個cookie值進行，不會因為客戶端機器發(fā)生變化而產(chǎn)生影響。

第五篇：LoadRunner檢查點使用小結(jié)

LoadRunner檢查點使用小結(jié)

LR中檢查點有兩種：圖片和文字。這兩種檢查點可用以下三個函數(shù)實現(xiàn)：web_find()、web_reg_find()和web_image_check()下面分別介紹三種函數(shù)的用法

1、web_find()函數(shù)

函數(shù)作用：在頁面中查找相應(yīng)的內(nèi)容

參數(shù)舉例：web_find(“web_find”,“RighOf=a”,“LeftOf=b”,“What=name”,LAST);參數(shù)解釋：“web_find”定義該查找函數(shù)的名稱；“LeftOf”和“RighOf=”用來定義查找字符的左右邊界；“What=”定義查找內(nèi)容。

例如上述參數(shù)舉例中的意思就是在頁面中查找左邊界為b，右邊界為a，內(nèi)容為name的信息 函數(shù)用法：該函數(shù)是在查找頁面中的內(nèi)容，所以要放在要查找的內(nèi)容的后面。注意事項：使用該函數(shù)時，要在Vuser->Run-Tme Settings中更改下設(shè)置

勾選Enable Image and text check

系統(tǒng)默認(rèn)是不勾選該選項的。

2、web_reg_find()函數(shù)

函數(shù)作用：在緩存中查找相應(yīng)的內(nèi)容

參數(shù)舉例：web_reg_find(“Search=Body”,“SaveCount=ddd”,“Test=aaa”,LAST);參數(shù)解釋： Search用來定義查找范圍，SaveCount定義查找計數(shù)變量名稱，該參數(shù)可以記錄在緩存中查找內(nèi)容出現(xiàn)的次數(shù)，可以使用該值，來判斷要查找的內(nèi)容是否被找到

例如上述參數(shù)舉例中的意思就是Body中查找內(nèi)容為aaa的信息，并將出現(xiàn)次數(shù)記錄在變量ddd中。函數(shù)用法：該函數(shù)是在緩存中查找相應(yīng)的內(nèi)容，所以要放在查找內(nèi)容之前。

注：在錄制過程中添加的檢查點，用到的函數(shù)是web_reg_find()，且參數(shù)只有“Text=”

3、web_image_check()函數(shù)

函數(shù)作用：在頁面中查找一個具體的圖片。

參數(shù)說明：web_image_check(“web_image_check”,“Alt=”,“Src=”,LAST);;參數(shù)解釋：“Alt”和“Src”的值直接取該圖片在網(wǎng)頁源代碼中相應(yīng)參數(shù)的值。函數(shù)用法：該函數(shù)是在緩存中查找相應(yīng)的內(nèi)容，所以要放在查找內(nèi)容之前。

注意事項：使用該函數(shù)時，要在Vuser->Run-Tme Settings中勾選Enable Image and text check，具體操作請看web_find()中的注意事項。

經(jīng)過測試，該函數(shù)用到查找內(nèi)容前面或后面，都不影響查找結(jié)果。舉例說明（腳本）

該腳本記錄的是登陸系統(tǒng)后退出的操作，在腳本中用到atoi()函數(shù)和lr_eval_string(”{SaveCount定義的變量}”)兩個函數(shù)結(jié)合使用，判斷查找內(nèi)容出現(xiàn)的次數(shù)是否大于0，若大于0，則輸入登錄成功的信息。

vuser_init()

{

web_url(“xjcost”，“URL=http://gczj-server8:9205/xjcost/”，“Resource=0”，“RecContentType=text/html”，“Referer=”, “Snapshot=t1.inf”, “Mode=HTML”, EXTRARES，“Url=jsp/images/index/index.swf”, ENDITEM, “Url=jsp/images/index/xxfb2.gif”, ENDITEM, “Url=jsp/images/index/ywpt2.gif”, ENDITEM，LAST);

web_url(“userAction.struts”, “URL=http://gczj-server8:9205/xjcost/userAction.struts?actionType=reLogin”，“Resource=0”，“RecContentType=text/html”，“Referer=”, “Snapshot=t2.inf”, “Mode=HTML”，LAST);return 0;

} Action()

{

lr_start_transaction(“Log_on”);lr_rendezvous(“Log_on”);web_add_cookie(“userAccount=admin;DOMAIN=gczj-server8”);

web_reg_find(“Text=歡迎您”, “SaveCount=歡迎您_Count”，LAST);

web_image_check(“web_image_check”, “Src=/xjcost/jsp/images/index1/edit_01.gif”，LAST);

web_submit_data(“userLogin.struts”, “Action=http://gczj-server8:9205/xjcost/userLogin.struts?actionType=userLogin”，“Method=POST”, “RecContentType=text/html”, “Referer=http://gczj-server8:9205/xjcost/userAction.struts?actionType=reLogin”，“Snapshot=t3.inf”, “Mode=HTML”, ITEMDATA, “Name=userAccount”, “Value=admin”, ENDITEM，“Name=pwd”, “Value=1111”, ENDITEM，EXTRARES，“Url=jsp/images/index1/edit_01a.gif”, “Referer=http://gczj-server8:9205/xjcost/userLogin.struts?actionType=userLogin”, ENDITEM，LAST);

web_find(“web_find”, “What=歡迎您”，LAST);

lr_end_transaction(“Log_on”,LR_AUTO);

//檢查是否登錄成功

//如果“歡迎您”這個字符出現(xiàn)次數(shù)大于0，輸出“Log on successfully!”

if(atoi(lr_eval_string(“{歡迎您_Count}”))>0)lr_output_message(“Log on successfully!”);

else

lr_error_message(“Log on failed!”);

return 0;return 0;

} //atoi()函數(shù)的作用是將一個ASCII字符串轉(zhuǎn)換為整型

//lr_eval_string()函數(shù)作用是取得參數(shù)值，將字符串變量中的參數(shù)值替換為當(dāng)前的參數(shù)值并將這個字符串返

回 vuser_end()

{

lr_think_time(4);

web_url(“userAction.struts_2”, “URL=http://gczj-server8:9205/xjcost/userAction.struts?actionType=reLogin”，“Resource=0”，“RecContentType=text/html”，“Referer=”, “Snapshot=t4.inf”, “Mode=HTML”，LAST);return 0;

} Global.h： #ifndef _GLOBALS_H #define _GLOBALS_H //------

// Include Files #include “l(fā)run.h” #include “web_api.h” #include “l(fā)rw_custom_body.h” //------

// Global Variables #endif // _GLOBALS_H Replay Log常見信息說明

1、web_find()和web_image_check()函數(shù)的日志信息（這兩個日志信息是上一樣的，只是輸出的函數(shù)名和參數(shù)不同）

1）信息1Action.c(22): Verification checks not enabled.web_image_check is skipped.See the 'Run-time settings/Preferences/Checks' [MsgId: MMSG-27197] Action.c(22): web_image_check was successful [MsgId: MMSG-26392] 出現(xiàn)該信息，說明沒有勾選Enable Image and text check 2）信息2Action.c(22): “web_image_check” succeeded(1 occurrence(s)found.Alt=“", Src=”/xjcost/jsp/images/index1/edit_01.gif“)[MsgId: MMSG-27192] Action.c(22): web_image_check was successful [MsgId: MMSG-26392] 出現(xiàn)該信息，說明檢查點設(shè)置成功，且已經(jīng)查找到信息

3）信息3Action.c(22): Error-27191: ”web_image_check“ failed(0 occurrence(s)found.Alt=”“, Src=”/xjcost/jsp/images/index1/edit_1.gif“)[MsgId: MERR-27191] Action.c(22): web_image_check highest severity level was ”ERROR“ [MsgId: MMSG-26391] 出現(xiàn)該信息，說明要查找的內(nèi)容沒有找到。這時依次嘗試以下操作：（1）檢查參數(shù)的信息是否寫錯；

（2）如果是web_find(),檢查函數(shù)的位置是否在要查找內(nèi)容的后面；

（3）如果是web_image_check()，查看該圖片的源代碼，看其是否是這個頁面上的圖片，很可能是圖片選擇錯誤，即所選圖片不屬于該頁面。

2、web_reg_find()函數(shù)的日志信息

1）信息1Action.c(15): Registering web_reg_find was successful [MsgId: MMSG-26390] 出現(xiàn)該信息，說明內(nèi)容已查找到

2）信息2Action.c(27): Error-26366: ”Text=ABC“ not found for web_reg_find [MsgId: MERR-26366] Action.c(27): web_submit_data(”userLogin.struts“)highest severity level was ”ERROR", 18364 body bytes, 918 header bytes, 13 chunking overhead bytes [MsgId: MMSG-26387] 該信息在replay log頁面是紅色顯示的，說明沒有找到內(nèi)容，出現(xiàn)此情況嘗試以下兩個操作：（1）參數(shù)的信息是否正確；

（2）查看該函數(shù)是否在查找內(nèi)容的前面。