天天看點

LoadRunner壓力測試執行個體步驟

LoadRunner 是一種預測系統行為和性能的工業标準級負載測試工具。通過以模拟上

千萬使用者實施并發負載及實時性能監測的方式來确認和查找問題,LoadRunner 能夠對整個

企業架構進行測試。通過使用LoadRunner , 企業能最大限度地縮短測試時間, 優化性能和加速應用系統的釋出周期。目前企業的網絡應用環境都必須支援大量使用者,網絡體系架構中含各類應用環境且由不同供應商提供軟體和硬體産品。難以預知的使用者負載和愈來愈複雜的應用環境使公司時時擔心會發生使用者響應速度過慢, 系統崩潰等問題。這些都不可避免地導緻公司收益的損失。Mercury Interactive 的 LoadRunner 能讓企業保護自己的收入來源, 無需購置額外硬體而最大限度地利用現有的IT 資源, 并確定終端使用者在應用系統的各個環節中對其測試應用的品質, 可靠性和可擴充性都有良好的評價。LoadRunner 是一種适用于各種體系架構的自動負載測試工具, 它能預測系統行為并優化系統性能。LoadRunner 的測試對象是整個企業的系統, 它通過模拟實際使用者的操作行為和實行實時性能監測, 來幫助您更快的查找和發現問題。此外,LoadRunner 能支援廣範的協定和技術, 為您的特殊環境提供特殊的解決方案。

1.1 基本步驟

使用LoadRunner 完成測試一般分為四個步驟:

1)Vvitrual User Generator 建立腳本

² 建立腳本,選擇協定

² 錄制腳本

² 編輯腳本

² 檢查修改腳本是否有誤

2)中央控制器(Controller)來排程虛拟使用者

² 建立Scenario,選擇腳本

² 設定機器虛拟使用者數

² 設定Schedule

² 如果模拟多機測試,設定Ip Spoofer

3)運作腳本

²  分析scenario

4)分析測試結果

2 安裝LoadRunner 中文版

LoadRunner 分為Windows 版本和Unix 版本。如果我們的所有測試環境基于Windows 

平台, 那麼我們隻要安裝Windows 版本即可。本章講解的安裝過程就是LoadRunner7.8中文的Windows 版本的安裝。

2.1 系統要求

目前部門的測試機和工作機器足可以滿足LoadRunner7.8 的最低要求。不過要比較好

的運作LoadRunner, 記憶體最好在512M 以上, 安裝LoadRunner 的磁盤空間至少剩餘500M。作業系統最好為Windows 2000。

2.2 安裝過程

中文版安裝基本分兩個步驟:首先安裝LoadRunner7.8英文原版,然後安裝中文語言插件包

LoadRunner7.8英文原版存放位置:\\10.138.149.139\ test tools\LR7.8nt.rar将壓縮檔案拷貝解壓到本機的安裝,過程比較簡單要開始安裝LoadRunner,以Administrator 的身份登陸Windows2000 後,運作LoadRunner 安裝目錄下Setup.exe 即可進入安裝程式。

1. 在“Registration Information” 界面中, 輸入序列号( 不用改動, 就是n 個8)

2. 在安裝類型界面中, 選擇一種安裝類型

LoadRunner壓力測試執行個體步驟

下面簡單的對這三種安裝類型進行介紹

●Standalone Installation 将要安裝LoadRunner 在一台計算機上

●Network Installation 把LoadRunner 安裝在一個網絡驅動器上, 這樣任何能連接配接到這個

網絡驅動器的計算機都可以使用LoadRunner 的部分或者全部元件。

●Network Installation and shortcuts 和Network Installation 類似,不同的隻是這種類型将把

自己的計算機配置成Workstation 來運作LoadRunner。如果選擇了第二項, 我們還需要

進行2.3 的安裝來配置Workstation.。考慮到我們是自己學習研究學習, 選擇第一種安裝方法。

3. 在安裝方式界面中, 需要選擇一種安裝方式。建議選擇“ 自定義安裝”, 這樣所有的元件都會一次安裝。

下面簡單的對各個安裝方式進行介紹

●Typical Installation 安裝比較通用的元件, 包括Controller、Vuser、線上幫助和腳

該選項适合于控制Vusers 的機器。

●Load Generator    隻安裝運作Vusers 産生負載的元件。該選項适合于隻産生負載, 

而不控制Vusers 的機器。

●MI Listener 安裝MI Listener 元件, 用來透過防火牆來運作Vusers 并且監視性能。

●Custom Installation 自定義安裝, 我們将使用該選項, 安裝全部的元件。

4. 在“License Information” 中輸入License Key 後,Next, 繼續

個使用者(無時間限制):AEAMAUIK-YAFEKEKJJKEEA-BCJGI

個使用者(有時間限制):AEABEXFR-YTIEKEKJJMFKEKEKWBRAUNQJU-KBYGB

5. 如果是網絡安裝,最好把網絡驅動器映射成本機的一個盤符, 安裝LoadRunner 的各級目錄不要包含中文字元。

6. Next 後進入拷貝檔案的界面

7. 拷貝檔案完成後, 進入“User Login Settings” 界面。

●Allow virtual users to run on this machine without user login 需要在下面輸入域、用

戶名和密碼, 這樣運作Load Generator 的機器會自動登陸到網絡, 

Manual log in to the Load Generator machine 運作Vusers 時, 自動登陸到網絡, 

無需登陸使用者名和密碼, 這樣Vusers 就會不用任何幹預自動的啟動運作。推薦

選擇該項。這裡選擇第一項和第二項都可以。

8. 重新啟動, 安裝完成

LoadRunner7.8英文原版存放位置:\\10.138.149.139\test tools\ LoadRunner7.8中文版.rar

将壓縮檔案拷貝解壓到本機的安裝.。過程比較簡單要開始安裝以Administrator 的身份登陸Windows2000 後,(注意要退出已經運作的英文原版)運作安裝目錄下Setup.exe 即可進入安裝程式,安裝過程中一切人機交流視窗多選擇預設“下一步”即可

注意:解壓檔案存放的檔案夾不可起中文名字,安裝目錄最好使用預設,如果更改則安裝目錄不要使用中文名!

3.項目背景介紹

3.1 背景概述

“LMS網校考試平台”是一個典型的三層B/S架構的MIS系統(用戶端/應用伺服器/資料庫管),中間層是業務邏輯層,應用伺服器處理所有的業務邏輯,但應用伺服器本身不提供負載均衡的能力,而是利用開發工具提供的ORB(對象請求代理)軟體保證多個應用伺服器間的負載均衡。本次測試的目的是:進行應用伺服器的壓力測試,找出應用伺服器能夠支援的最大用戶端數。方法是:按照正常業務壓力估算值的1~10倍進行測試,考察應用伺服器的運作情況。

3.2壓力測試用例

 場景描述一:

1. 使用者登入的lmm子產品,總共登陸24個使用者,所有使用者都同時并發操作。 

2. 使用者點選“登記的教程”

3. 使用者點選“啟動”,進行課程學習,進入DS子產品

4. 在DS子產品中進行學習,過程包括:首先,點選一次課程結構樹;然後,進行課程内容的學習。

5. 點選“傳回LMS”按鈕,傳回到lmm子產品,點選“退出”按鈕,退出系統

場景描述二:

1. 使用者登陸lmm子產品,總共登入48個使用者,每1秒登入1個使用者

2. 使用者點選“已登記教程”

3. 使用者點選“啟動”,進行課程學習,進入DS子產品

4. 在DS子產品中進行學習,過程包括:首先,點選一次課程結構樹;然後,進行課程内容的學習;

5. 點選“傳回LMS”按鈕,傳回到lmm子產品,點選“退出”按鈕,退出系統

場景描述三:

1. 使用者登入的lmm子產品,總共登陸48個使用者,所有使用者都同時并發操作。 

2. 使用者點選“登記的教程”

3. 使用者點選“啟動”,進行課程學習,進入DS子產品

4. 在DS子產品中進行學習,過程包括:首先,點選一次課程結構樹;然後,進行課程内容的學習。

5. 點選“傳回LMS”按鈕,傳回到lmm子產品

點選“退出”按鈕,退出系統

場景描述四:

1. 使用者登入的lmm子產品,總共登陸48個使用者,每秒同時登入10個使用者。 

2. 使用者點選“登記的教程”

3. 使用者點選“啟動”,進行課程學習,進入DS子產品

4. 在DS子產品中進行學習,過程包括:首先,點選一次課程結構樹;然後,進行課程内容的學習。

5. 點選“傳回LMS”按鈕,傳回到lmm子產品,點選“退出”按鈕,退出系統

場景描述五: 

1. 使用者登入的lmm子產品,總共登陸100個使用者,所有使用者同時并發操作。 

2. 使用者點選“登記的教程”

3. 使用者點選“啟動”,進行課程學習,進入DS子產品

4. 在DS子產品中進行學習,過程包括:首先,點選一次課程結構樹;然後,進行課程内容的學習。

5. 點選“傳回LMS”按鈕,傳回到lmm子產品

場景描述六: 

1. 使用者登入的lmm子產品,總共登陸200個使用者,所有使用者同時并發操作

2. 使用者點選“登記的教程”

3. 使用者點選“啟動”,進行課程學習,進入DS子產品

4. 在DS子產品中進行學習,過程包括:首先,點選一次課程結構樹;然後,進行課程内容的學習。

5. 點選“傳回LMS”按鈕,傳回到lmm子產品,點選“退出”按鈕,退出系統

場景描述七: 

1. 戶登入的lmm子產品,總共登陸24個使用者。所有使用者都同時并發操作 

2. 所有使用者都同時并發操作,戶點選“登記的教程”中“test”課件

使用自發測試工具,目的測試24個使用者同時打開課件時伺服器性能

場景描述八: 

1. 登入的lmm子產品,總共登陸60個使用者。所有使用者都同時并發操作 

2. 有使用者都同時并發操作,戶點選“登記的教程”中“test”課件

使用自發測試工具,目的測試60個使用者同時打開課件時伺服器性能

4.使用LoadRunner進行負載/壓力測試

4.1錄制基本的使用者腳本

建立使用者腳本需要用到VuGen。提示: 運作VuGen 最好在1024*768 的分辨率下, 否則有些工具欄會看不到。

啟動Visual User Generator 後, 通過菜單建立一個使用者腳本, 選擇系統通訊的協定。

這裡我們需要測試的是Web 應用,同時考慮到背景SQL資料庫是以我們需要選擇Web(HTTP/HTML)協定+SQL SERVER協定,确定後, 進入主窗體。通過菜單來啟動錄制腳本的指令。

LoadRunner壓力測試執行個體步驟

●在URL 中添入要測試的Web 站點位址..。

●測試http://lms.ah.sp.com.cn/lms-lmm/loginForm.do選擇要把錄制的腳本放到哪一個部分, 預設情況下是“Action”。

這裡簡單說明一下:VuGen 中的腳本分為三部分:vuser_init、vuser_end 和Action。其

中vuser_init 和vuser_end 都隻能存在一個, 不能再分割, 而Action 還可以分成無數多個部分( 通過點選New 按鈕, 建立ActionXXX)。在錄制需要登陸的系統時, 我們把登陸部分放到vuser_init 中, 把登陸後的操作部分放到Action 中, 把登出關閉登陸部分放到vuser_end 中。( 如果需要在登陸操作設集合點, 那麼登陸操作也要放到Action 中, 因為vuser_init 中不能添加集合點) 在其他情況下, 我們隻要把操作部分放到Action 中即可。注意: 在重複執行測試腳本時,vuser_init 和vuser_end 中的内容隻會執行一次, 重複執行的隻是Action 中的部分。

LoadRunner壓力測試執行個體步驟

●點“ 選項 ”按鈕, 進入錄制的設定窗體, 這裡一般情況下不需要改動。

●然後點“OK” 後,VuGen 開始錄制腳本。在錄制過程中, 不要使用浏覽器的“ 後退” 功能,LoadRunner 支援不太好! 錄制過程中, 在螢幕上會有一個工具條出現。錄制的過程和WinRunner 有些類似, 不再多介紹。錄制完成後, 按下“ 結束錄制” 按鈕,VuGen 自動生成使用者腳本, 退出錄制過程。

4.2 完善測試腳本

當錄制完一個基本的使用者腳本後, 在正式使用前我們還需要完善測試腳本, 增強腳本的

靈活性。一般情況下, 我們通過以下幾種方法來完善測試腳本。插入事務、插入結合點、插入注解、參數化輸入。這裡隻舉例介紹參數化如何設定,其它隻作簡單介紹。

4.2.1 插入事務

事務(Transaction): 為了衡量伺服器的性能, 我們需要定義事務。比如: 我們在腳本

中有一個資料查詢操作, 為了衡量伺服器執行查詢操作的性能, 我們把這個操作定義為一個事務, 這樣在運作測試腳本時,LoadRunner 運作到該事務的開始點時,LoadRunner 就會開始計時, 直到運作到該事務的結束點, 計時結束。這個事務的運作時間在結果中會有反映。

插入事務操作可以在錄制過程中進行, 也可以在錄制結束後進行。LoadRunner 運作在

腳本中插入不限數量的事務。

具體的操作方法如下: 在需要定義事務的操作前面, 通過菜單或者工具欄插入。輸入該事務的名稱。注意: 事務的名稱最好要有意義, 能夠清楚的說明該事務完成的動作。插入事務的開始點後, 下面需要在需要定義事務的操作後面插入事務的“ 結束點”。同樣可以通過菜單或者工具欄插入。預設情況下, 事務的名稱列出最近的一個事務名稱。一般情況下, 事務名稱不用修改。事務的狀态預設情況下是LR_AUTO。一般情況下, 我們也不需要修改, 除非在手工編寫代碼時, 有可能需要手動設定事務的狀态。

4.2.2 插入集合點

插入集合點是為了衡量在加重負載的情況下伺服器的性能情況。在測試計劃中, 可能會

要求系統能夠承受1000 人同時送出資料,在LoadRunner 中可以通過在送出資料操作前面加入集合點, 這樣當虛拟使用者運作到送出資料的集合點時,LoadRunner 就會檢查同時有多少使用者運作到集合點,如果不到1000 人,LoadRunner 就會指令已經到集合點的使用者在此等待, 當在集合點等待的使用者達到1000 人時,LoadRunner 指令1000 人同時去送出資料, 進而達到測試計劃中的需求。

注意: 集合點經常和事務結合起來使用。集合點隻能插入到Action 部分,vuser_init 和vuser_end 中不能插入集合點。具體的操作方法如下: 在需要插入集合點的前面, 通過菜單或者工具欄操作輸入該集合點的名稱。注意: 集合點的名稱最好要有意義, 能夠清楚的說明該集合點完

成的動作。

4.2.3 插入注釋

注釋的作用就不多說了, 不過插入注釋最好是在錄制過程中。具體的操作方法如下: 在需要插入注釋的前面, 通過菜單或者工具欄操作

4.2.4 參數化輸入

如果使用者在錄制腳本過程中, 填寫送出了一些資料, 比如要增加資料庫記錄。這些操作

都被記錄到了腳本中。當多個虛拟使用者運作腳本時, 都會送出相同的記錄, 這樣不符合實際的運作情況, 而且有可能引起沖突。為了更加真實的模拟實際環境, 需要各種各樣的輸入。參數化輸入是一種不錯的方法。

用參數表示使用者的腳本有兩個優點: 

① 可以使腳本的長度變短。

② 可以使用不同的數值來測試你的腳本。例如, 如果你企圖搜尋不同名稱的圖書, 你

僅僅需要寫送出函數一次。在回放的過程中, 你可以使用不同的參數值, 而不隻搜尋一

個特定名稱的值。

參數化包含以下兩項任務: 

① 在腳本中用參數取代常量值。

② 設定參數的屬性以及資料源。

參數化僅可以用于一個函數中的參量。你不能用參數表示非函數參數的字元串。

另外, 不是所有的函數都可以參數化的。

參數化輸入的講解, 我們采用一個例子的方式來進行。

在本例中我們參數化使用者的登陸名:

先看如下腳本,通過腳本錄制找到使用者登陸部分,如圖

LoadRunner壓力測試執行個體步驟

框選住登陸名,點滑鼠右鍵,彈出對話框,選擇“替換為新參數”彈出對話框

LoadRunner壓力測試執行個體步驟

參數名随意取,建議取通俗易懂的名字,下面我們重點介紹一下參數的類型。

●DateTime: 很簡單, 在需要輸入日期/時間的地方, 可以用DateTime 類型來替代。

其屬性設定也很簡單, 選擇一種格式即可。當然也可以定制格式。

.●Group Name:暫時不知道何處能用到,但設定比較簡單。在實際運作中,LoadRunner 

使用該虛拟使用者所在的Vuser Group 來代替。但是在VuGen 中運作時,Group Name 

将會是None 

.●Load Generator Name: 在實際運作中,LoadRunner 使用該虛拟使用者所在Load Generator 的機器名來代替。

.●Iteration Number: 在實際運作中,LoadRunner 使用該測試腳本目前循環的次數來

代替。

.●Random Number: 随機數。很簡單。在屬性設定中可以設定産生随機數的範圍

.●Unique Number:唯一的數。在屬性設定中可以設定第一個數以及遞增的數的大小。

注意: 使用該參數類型必須注意可以接受的最大數。例如: 某個文本框能接受的

最大數為99。當使用該參數類型時, 設定第一個數為1, 遞增的數為1, 但100 個

虛拟使用者同時運作時,第100 個虛拟使用者輸入的将是100,這樣腳本運作将會出錯。

注意: 這裡說的遞增意思是各個使用者取第一個值的遞增數, 每個使用者相鄰的兩次循

環之間的內插補點為1。舉例說明: 假如起始數為1, 遞增為5, 那麼第一個使用者第一

次循環取值1, 第二次循環取值2; 第二個使用者第一次循環取值為6, 第二次為7; 

依次類推。

●Vuser ID: 設定比較簡單。在實際運作中,LoadRunner 使用該虛拟使用者的ID 來代

替,該ID 是由Controller 來控制的。但是在VuGen 中運作時,Vuser ID 将會是–1。

File: 需要在屬性設定中編輯檔案,添加内容,也可以從現成的資料庫中取資料( 下

面我們将會介紹) 

●User Defined Function: 從使用者開發的dll 檔案提取資料。就目前我認為, 這種方式

沒有必要。VuGen 支援C 語言的文法,在VuGen 中重新編寫類似的函數應該不難。

上面的例子中, 我們取随機數即可。點“Properties… ..” 按鈕, 進行屬性設定視窗

添入随機數的取值範圍為(1-50), 選擇一種資料格式。在“屬性” 中有以下幾

個選項: 

◆Each Occurrence:在運作時, 每遇到一次該參數, 便會取一個新的值

◆Each iteration:運作時, 在每一次循環中都取相同的值

◆Once:運作時, 在每次循環中, 該參數隻取一次值

這裡我們用的是随機數, 選擇Each Occurrence 非常合适。

下面我們再介紹用資料庫中的使用者名來參數化登陸使用者名。

框選住登陸名,點滑鼠右鍵,彈出對話框,選擇“替換為新參數”彈出對話框,此時參數名輸入:name,參數類型選擇File,如圖

LoadRunner壓力測試執行個體步驟

點“屬性”按鈕, 出現以下視窗

LoadRunner壓力測試執行個體步驟

注意: 參數的檔案名不要使用con.dat、pm.dat 或者lpt*.dat 等系統裝置名下面我們将會連接配接資料庫, 從資料表中選擇使用者名。點“資料向導” 按鈕,顯示如圖

LoadRunner壓力測試執行個體步驟

使用第2 項, 選擇“使用手動指定SQL語句”點下一步,出現如圖視窗

LoadRunner壓力測試執行個體步驟

添入連接配接字元串, 點“建立” 按鈕,選擇事先配置好的ODBC連接配接。在SQL語句裡輸入select查詢語句,出現如圖視窗

LoadRunner壓力測試執行個體步驟

提醒: 在參數資料顯示區, 最多隻能看到100 行, 如果資料超過100 行, 隻能點“編輯” 按鈕, 進入記事本看。

“選擇下一行 ” 有以下幾種選擇: 

●Sequential: 按照順序一行行的讀取。每一個虛拟使用者都會按照相同的順序讀取

●Random: 在每次循環裡随機的讀取一個, 但是在循環中一直保持不變

Unique : 唯一的數。注意: 使用該類型必須注意資料表有足夠多的數。比如Controller 中設定20 個虛拟使用者進行5 次循環, 那麼編号為1 的虛拟使用者取前5 個數, 編号為2 的虛拟使用者取6-10 的數, 依次類推, 這樣資料表中至少要有100 個資料, 否則Controller 運作過程中會傳回一個錯誤。

“按編号”指選擇清單中的那一列資料,從左到右分别是1、2、3依次

通常用在有關聯性的資料上面。我們這裡取值Sequential 即可。完成設定關閉即可

4.3 單機運作測試腳本

經過以上的各個步驟後, 腳本就可以運作了。運作腳本可以通過菜單或者工具欄來操作。

執行“ 運作” 指令後,VuGen 先編譯腳本, 檢查是否有文法等錯誤。如果有錯誤,VuGen 

将會提示錯誤。輕按兩下錯誤提示,VuGen 能夠定位到出現錯誤的那一行。為了驗證腳本的正

确性, 我們還可以調試腳本, 比如在腳本中加斷點等, 操作和在VC 中完全一樣, 相信大家誰都不會感到陌生。如果編譯通過, 就會開始運作。然後會出現運作結果。

5實施測試

5.1 選擇腳本,建立虛拟使用者

controller”彈出如圖視窗

LoadRunner壓力測試執行個體步驟

選擇剛才錄制并儲存好的腳本,添加到方案中,點“确定”出現如圖

LoadRunner壓力測試執行個體步驟

根據需要修改虛拟使用者數量,這裡我們取“100”根據實作場景設計,取不同數字

LoadRunner壓力測試執行個體步驟

點“編輯計劃”細化方案,計劃名裡選擇計劃種類:加壓,緩慢加壓、預設計劃或建立立計劃。

² 預設計劃:同時加載所有vuser,直到完成

² 加壓:每15秒啟動2個vuser 持續時間5分種

² 緩慢加壓::每2分種啟動2個vuser 持續時間10分種

這裡我們選擇“加壓” 出現如圖

LoadRunner壓力測試執行個體步驟

ok”傳回上一級視窗,點“開始方案”啟動運作,出現如圖視窗

LoadRunner壓力測試執行個體步驟

5.2 添加windows資源監視視窗

loadruner預設性能監視視窗四個,分别是“運作vuser“、”事務響應時間“、

“每秒點選次數”最後一個可以根據使用者自己選擇現實什麼視窗。打開可用圖中目錄樹,

選擇系統資源,找到windows資源輕按兩下,則windows資源監視視窗便自動替換原視窗如上圖。當然loadrunner也可以同時顯示1-16個視窗,方法是點右鍵,在彈出菜單中選擇“檢視圖”選擇顯示的圖數,也可以自定義數字。

5.3 添加windows性能計數器

滑鼠選擇windows資源監視視窗,點選右鍵彈出菜單中選擇“ADD Measurements..”彈出如圖視窗

LoadRunner壓力測試執行個體步驟

點“添加”把監視的伺服器ip位址輸入,點确定,如圖

LoadRunner壓力測試執行個體步驟

如果可以正常聯機到伺服器,則在資源度量中會顯示全部計數器,此時如果點“确定”則系統預設全部選中,在監視視窗中會顯示所有性能曲線,無法單獨過濾顯示某條曲線,如果選中某個計數器後點“添加”則彈出該項目下的其它性能名額,選擇需要的計數器後點“添加”如圖

LoadRunner壓力測試執行個體步驟

此時要注意,你登陸用戶端(也就是你裝有loadrunner機器)的使用者應該是管理者身份,同時還要保證該使用者在被監視的伺服器上也是管理者身份。這樣選擇雖然監視視窗中仍會顯示所有性能曲線,但是可以通過滑鼠右鍵彈出菜單,選中你指定的某條曲線單獨顯示。方法是輕按兩下監視視窗放大顯示,然後右鍵選擇“僅顯示指定圖”監視視窗還可以互相疊加等操作,功能強大,通過右鍵菜單選擇可以進行複雜顯示操作。常用的還有web程式伺服器圖、資料庫伺服器資源圖等,添加方法雷同。計數器有那些,有什麼含義,理想值是多少,可以參見第六章節。

5.4 執行腳本

此時設定完畢後,那就簡單了,點選“開始方案”注意觀察吧。

LoadRunner壓力測試執行個體步驟

5.4.1 分析結果

loadrunner會自動分析結果,生成分析結果圖或表,方法是點導航欄“結果”選現,在彈出視窗中選擇“分析結果”

LoadRunner壓力測試執行個體步驟
LoadRunner壓力測試執行個體步驟

6 分析以及監視場景

在運作過程中, 可以監視各個伺服器的運作情況(DataBase Server、Web Server 等)。

監視場景通過添加性能計數器來實作。這一章非常的重要, 确定系統瓶頸全靠它了。

下面重點講講需要添加那些計數器, 以及那些計數器代表什麼意思。由于Win2000 Professional、Server 以及Advanced Server 提供的計數器不完全相同, 這裡我們讨論将以Server 為基準。監視場景需要在Run 視圖中設定然後, 出現添加計數器的對話框其他的操作就和控制台“ 性能” 中添加性能計數器的操作一樣, 這裡不再詳細說明。本章主要說明一下各個系統計數器的含義( 資料庫的計數器不做重點, 隻是拿SQL Server2000 作為例子進行說明。因為資料庫各個版本之間差異比較大, 請參考您使用的資料庫系統的幫助)。

6.1 Memory相關

記憶體是第一個監視對象, 确定系統瓶頸的第一個步驟就是排除記憶體問題。記憶體短缺的問題可能會引起各種各樣的問題。

Object( 對象) Counters Description( 描述) 參考值
Memory Available MBytes 實體記憶體的可用數( 機關 Mbytes)。預設情況下IIS5.0 使用50%的可用實體記憶體, 作為IIS 的檔案緩存(file cache)。IIS 基本占用 2.5 MB,每個附加連接配接将在此基礎上占用 10 KB 左右 至少要有10% 的實體
Memory

Page/sec 

Page Faults/sec 

Pages Input/sec

Pages Input/sec 

Page Reads/sec 

Transition 

Faults/sec 

實體記憶體的可用數( 機關 Mbytes)。預設情況下IIS5.0 使用50%的可用實體記憶體, 作為IIS 的檔案緩存(file cache)。IIS 基本占用 2.5 MB,每個附加連接配接将在此基礎上占用 10 KB 左右。至少要有10% 的實體記憶體值當處理器向記憶體指定的位置請求一頁( 可能是資料或代碼) 出現錯誤時, 這就構成一個Page Fault。如果該頁在記憶體的其他位置, 該錯誤被稱為軟錯誤( 用Transition Fault/sec 數器衡量); 如果該頁必須從硬碟上重新讀取時, 被稱為硬錯誤。許多處理器可以在有大軟錯誤的情況下繼續操作。但是, 硬錯誤可以導緻明顯的拖延。Page Faults/sec 是處理器每秒鐘處理的錯誤頁( 包括軟錯誤和硬錯誤)。Pages Input/sec 是為了解決硬錯誤頁, 從硬碟上讀取的頁數, 而Page Reads/sec 是為了解決硬錯誤, 從硬碟讀取的次數。如果 Page Reads/Sec 比率持續保持為 5, 表示可能記憶體不足。Pages/sec 是指為解析硬頁錯誤從磁盤

讀取或寫入磁盤的頁數。

Page/sec 推薦00-20( 如果伺服器沒有足夠的記憶體處理其工作負荷, 此數值将一直很高。如果大于80,表示有問題)。這些計數器的值比較低, 說明Web伺服器響應請求比較快, 否則可能是伺服器系統記憶體短缺引起( 也可能是緩存太大, 導緻系統記憶體太少)。Page Input/sec 的值可以衡量出硬錯誤頁發生的速率, 通常它的值會于或者等于Page Reads/sec。Memory Cache Bytes
Memory Cache Bytes 檔案系統緩存(File System Cache) 默預設情況下認情況下為50%的可用實體記憶體。如為50%的可IIS5.0 運作記憶體不夠時, 它會自動整理用實體記憶體緩存。需要關注該計數器的趨勢變化
Internet File Cache Hits %

File Cache Hits %是檔案緩存命中全部( 對于一個Information File Cache 緩存需求的比例, 反映了IIS 的檔案緩大部分是靜Services Flushes 存設定的工作情況。而File Cache Hits 态網頁組成

Global File Cache Hits 是檔案緩存命中的具體值,File Cache 的網站)File Flushes 是自伺服器啟動之後檔案緩存Cache Hits% 重新整理次數, 如果重新整理太慢, 會浪費記憶體; 如果重新整理太快, 緩存中的對象會太頻繁屬于非常好! 的丢棄生成, 起不到緩存的作用。通過File Cache Hits 和File Cache Flushes 可以得到一個适當的重新整理值( 參考IIS 的設定ObjectTTL 、MemCacheSize 、MaxCacheFileSize)

Memory PoolPaged BytesPool Nonpaged Bytes Pool Paged Bytes Pool Nonpaged Bytes 這兩個計數器監視伺服器上各個程序的分頁池位元組數和非分頁池位元組數。 在通路數比較固定的情況下, Pool Nonpaged Bytes 是比較定的, 如果通路數逐漸增加, 該值會緩慢的增加
Process

Virtual Bytes

Working Set 計數器

Virtual Bytes( 實Virtual Bytes 數器監視IIS5.0 保留的例inetinfo 、虛位址空間的數量, 執行個體化為inetinfo dllhost) Working Set( 執行個體程序(IIS 運作的核心)和Dllhost 程序( 隔離/ 連接配接池的應用程式必需的)。inetinfo 、dllhost) Working Set 計數器反映了每個程序使Dllhost#n 程序都用的記憶體頁的數量。系統的記憶體頁(pool 要添加計數器Page) 隻能由作業系統的核心子產品直接通路, 使用者程序不能通路。運作IIS5.0 的伺服器上, 負責web 連接配接的線程以及它需要的一些對象都儲存在未分頁的池中(nonpaged pool), 比如檔案句柄和socket 連接配接
Process Private Bytes 指這個處理不能與其他處理共享的、已配置設定的目前位元組數
Memory

Committed 

Bytes

是指以位元組表示的确認虛拟記憶體。(确認記憶體是指為磁盤分

頁檔案在磁盤上保留的空間以便在需推薦不超過實體記憶體的75% 

要将其寫回磁盤時使用)

推薦部超過實體記憶體的75%

記憶體問題主要檢查應用程式是否存在記憶體洩漏。如果發生了記憶體洩漏,Process\Private Bytes 計數器和Process\Working Set 計數器的值往往會升高, 同時Available Bytes 的值會降低。記憶體洩漏應該通過一個長時間的, 用來研究分析當所有記憶體都耗盡時, 應用程式反應情況的測試來檢驗。

6.2 Processor相關

Object( 對象) Counters Description( 描述) 參考值
Sytem

Processor Queue 

Length 

Processor Queue Length 是指處理列隊中的線程數。即使在有多個處理器的計算機上處理器時間也會有一個單列隊。不象磁盤計數器, 這個計數器僅計數就緒的線程, 而不計數運作中的線程。如果處理器列隊中總是有兩個以上的線程通常表示處理器堵塞 小于2。顯示在由 Web 伺服器所有處理器共享的隊列中等待執行的線程數。處理器瓶頸會導緻該值持續大于2
Processor %Processor Time

CPU 使用率。這是檢視處理器飽和狀況的最佳計數器。顯示所有 CPU 的線程處理時間。如果一個或多個處理器的該數值持續超過 90%,則表示此測試的負

載對于目前的硬體過于沉重。為多處理器伺服器添加該計數器的 0 到 x 個執行個體

小于75%。排除記憶體因素, 如果該計數器的值比較大, 而同時網卡和硬碟的值比較低, 那麼可以定CPU瓶頸
System Context Switches/sec Context Switches/sec 指計算機上的所有處理器全都從一個線程轉換到另一個線程的綜合速率。當正在運作的線程自動放棄處理器時出現上下文轉換, 由一個有更高優先就緒的線程占先或在使用者模式和特權(核心)模式之間轉換以使用執行或分系統服務。它是在計算機上的所有處理器上運作的所有線程的Thread: Context Switches/sec 的總數并且用轉換數量衡量。在系統和線程對象上有上下文轉換計數器

如果切換次數到5000*CPU個數和10000*CPU 個數中, 說明它忙于切換線程而不是

處理ASP 腳本

Processo %Privileged Time % Privileged Time 是在特權模式下處理線程執行代碼所花時間的百分比。當調用 Windows 系統服務時, 此服務經常在特權模式運作, 以便擷取對系統專有資料的通路。在使用者模式執行的線程無法通路這些資料。對系統的調用可以是直接的(explicit)或間接的(implicit), 例如頁面錯誤或中斷。不像某些早期的作業系統,Windows 除了使用使用者和特權模式的傳統保護模式之外, 還使用處理邊界作為分系統保護。某些由Windows 為您的應用程式所做的操作除了出現在處理的特權時間内, 還可能在其他子系統處理出現
Time Switches/sec ( 執行個體化inetinfo 和dllhost 如果你決定要增加線程位元組池的大小,你應該監視這三個計數器( 包括上面的一個)。增加線數可能會增加上下文切換次數, 這樣性能不會上升反而會下降。如果十個執行個體的上下文切換值非常高, 就應該減小線程位元組池的大小
Processor Interrupts/sec %DPC Time Time 這兩個計數器能夠反映處理器用在進行中斷以及推遲處理調用的時間。如果處理器使用率超過Interrupts/sec 指處理器每秒鐘接收并維90% 且 硬體中斷的平均值。正常的線程操作在中斷時懸停。大多數的系統時鐘每Interrupt Time 大于隔 10 毫秒中斷處理器一次, 形成了間15%, 則處理隔活動的背景 如果處理器使用率超過90%,且Interrupts/sec time大于15%則處理器可能負載過重,并發生中斷

Processor Interrupts/sec %DPC Time 這兩個計數器能夠反映處理器用在進行中斷以及推遲處理調用的時間。如果處理器使用率超過Interrupts/sec 指處理器每秒鐘接收并維90% 且 硬體中斷的平均值。正常的線程操作在中斷時懸停。大多數的系統時鐘每Interrupt Time 大于隔 10 毫秒中斷處理器一次, 形成了間15%, 則處理隔活動的背景。器可能負荷過重, 并發生中斷。判斷應用程式是否存在處理器瓶頸的方法: 如果Processor Queue Length 顯示的隊列長度保持不變(>=2) 個并且處理器的使用率%Processor Time 超過90%, 那麼很有可能存在處理器瓶頸。

如果發現Processor Queue Length 顯示的隊列長度超過2, 而處理器的使用率卻一直很

低, 那麼或許更應該去解決處理器阻塞問題, 這裡處理器一般不是瓶頸。如果系統由于應用程式代碼效率低下或者系統結構設計有缺陷而導緻大量的上下文切換(Context Switches/sec 顯示的上下文切換次數比較大), 那麼就會占用大量的系統資源。如果系統的吞吐量降低并且CPU 的使用率很高,并且此現象發生時切換水準在15000 以上, 那麼意味着上下文切換次數過高同時還可以比較Context Switches/sec 和%Privileged Time 來判斷上下文切換是否過量。如果後者的值超過40%, 且上下文切換的速率也很高, 那麼應該檢查為什麼會産生這樣高的上下文切換。

6.3 網絡吞吐量以及帶寬

Object Counter Description 參考值
Network Interface Bytes Total/se Bytes Total/sec 為發送和接收位元組的速率, 包括幀字元在内。判斷網絡連接配接速該計數器的值和目前網度是否是瓶頸, 可以用該計數器的值和絡的帶寬相目前網絡的帶寬比較 改計數器的值和目前網絡帶寬相除,結果應該小于50%
Web Servic Maximum Maximum Connections Maximum Maximum Connections :“ 最大連接配接數” Attempts Total Connection Attempts :“ 連接配接嘗試總數” 是從服務啟動時利用Web 服務嘗試連接配接的總數。該計數器應用于全部所列的執行個體。

6.4 磁盤相關

Object( 對象) Counters( 計數器名稱) Description( 描述) 參考值

Object Counters Description 參考值
Network Bytes Total/sec Bytes Total/sec 為發送和接收位元組的速Interface 率, 包括幀字元在内。判斷網絡連接配接速度是否是瓶頸, 可以用該計數器的值和目前網絡的帶寬比較
Processo

%Processor Time

% Privileged Time

CPU 使用率該計數器對應于處理器執行Windows. 2000 核心指令( 如處理SQL Server I/O 請求) 所用時間的百分比。如果 Physical Disk 計數器的值很高時該計數器的值也一直很高, 則考慮使用速度更快或效率更高的磁盤子系統。
PhysicalDisk %Disk Time

% Disk Time 指所選磁盤驅動器忙于為讀或寫入請求提供服務所用的時間的百分比。如果三個計數器都比較大, 那

麼硬碟不是瓶頸。如果隻有%Disk Time 比較大, 另外兩個都比較适中, 硬碟可能會是瓶頸。在記錄該計數器之前, 請

在 Windows 2000 的指令行視窗中運作 diskperf -yD 。若數值持續超過 80%, 則可能記憶體洩漏。

PhysicalDisk

AverageDisk 

Queue Length

指讀取和寫入請求(為所選磁盤在執行個體間隔中列隊的)的平均數。
PhysicalDisk PhysicalDisk 指在此盤上讀取操作的速率
PhysicalDisk Disk Writes/sec 指在此盤上寫入操作的速率

判斷磁盤瓶頸的方法是通過以下公式來計算: 

每磁盤的I/O 數 = [讀次數 + (4 * 寫次數)] / 磁盤個數

如果計算出的每磁盤的I/O 數大于磁盤的處理能力, 那麼磁盤存在瓶頸。

6.5 Web應用程式

這裡以ASP.NET 開發的Web 應用程式為例進行說明。

Object Counters Description 參考值
ASP.NET Applications Request/Sec Request Executing 每秒執行的請求數。

如果Request/Sec ApplicationsRequest Executing 目前執行的請求數。的值比較小, 你

的Web 程式可能

是瓶頸

ASP.NET

ASP.NETRequestWait 

Time 

Request Executing Time 

最近的請求在隊列中等待的毫秒數。執行最近的請求所用的毫秒數。Queued 在理想狀況下應該接近0,Request Queued 等候處理的請求數。該計數器應保持接近 0。超過 IIS 隊列長度會出如果這兩個值太大, 那麼需要重制“伺服器太忙”錯誤

6.6 SQL Server

這裡針對SQL Server2000, 而且隻是列出比較關鍵的幾個。更加詳細的資訊可以參考SQL Server 的聯機文檔。

Object( Counters Description 參考值
Processor %Processor time CPU 使用率
SQL Server: Logins/sec 這是每秒登入到 SQL Server 的計數
SQLServer:CacheManage

Cache Hit Ratio

(all instances)

顯示在高速緩存中找到資料的命中率。如果數值持續小于 85%, 則表

示記憶體有問題。

SQL Server

General Statistics

User Connections

顯示目前 SQL 使用者數。與Active Server Pages:Requests/Sec 計數器

進行比較, 可幫助了解腳本對 SQL Server 的影響程度。如果差别過大, 則表示測試腳本不能有效地對SQL Server 進行應力測試。

SQLServer:Locks Lock Waits/sec 顯示在目前程序完成之前強制其他程序等待的每秒鎖定請求的數量。如果該值始終大于 0, 則表示事務有問題。
SQLServer: BuffeManage Buffer Manager Hit Ratio 計數器值依應用程式而定, 但比率最好為 90% 或更高。增加記憶體直到這一數值持續高于 90%, 表示90% 以上的資料請求可以從資料緩沖區中獲得所需資料。

SQLServer

SQL Statistics

Batch Requests/sec

每秒收的Transact-SQL 指令批數。這一統計資訊受所有限制( 如I/O、使用者數、高速緩存大小、請求I/O、使用者數、高速緩存大小、請求的複雜程度等) 影響。批請求數值

高意味着吞吐量很好。

SQL Server:

Buffer Manager 

Lazy Writes/sec

每秒被緩沖區管理器的惰性寫入器寫入的緩沖區數。惰性寫入器是一

個系統程序, 其主要任務是重新整理成批的老化的髒緩沖區( 指包含更改

的緩沖區, 這些更改必須寫回磁盤, 才能使該緩沖區由其它頁重新使

用), 并使之可由使用者程序使用。惰性寫入器消除了為建立可用緩沖區而頻繁執行檢查點的需要。

SQL Server: 

Buffer Manager 

Page Reads/sec

每秒發出的實體資料庫頁讀取數。這一統計資訊顯示的是在所有資料

庫間的實體頁讀取總數。由于實體I/O 的開銷大, 可以通過使用更大

的資料高速緩存、智能索引、更高效的查詢或者改變資料庫設計等方法, 使開銷減到最小。

SQL 

Server:Databases 

Transactions/sec 每秒為資料庫啟動的事務數

這裡針對SQL Server2000, 而且隻是列出比較關鍵的幾個。更加詳細的資訊可以參考SQL 

Server 的聯機文檔。

6.7 Network Delay

如果要監視的兩台計算機在同一個區域網路絡内, 建議不要使用Network Delay Monitor。

因為在同一區域網路内,Network Delay 會非常的小, 網絡螢幕會有足夠的時間在每秒鐘内發送成百上千的請求, 這樣會導緻源計算機(source machine) 的CPU 和記憶體超負荷工作。

預設情況下“Enable display of network nodes by DNS names” 選擇是沒有選中的, 因為

選中它會明顯的降低該螢幕的速度。

7 分析實時監視圖表

這一章僅僅介紹幾個最重要的圖表。

Q1 事務響應時間是否在可接受的時間内? 哪個事務用的時間最長? 

看Transaction Response Time 圖, 可以判斷每個事務完成用的時間, 進而可以判斷出那個事務用的時間最長, 那些事務用的時間超出預定的可接受時間。

Q2 網絡帶寬是否足夠? 

“Throughput”圖顯示在場景運作期間的每一秒鐘, 從Web Server 上接受到的資料量的值。

拿這個值和網絡帶寬比較, 可以确定目前的網絡帶寬是否是瓶頸。

如果該圖的曲線随着使用者數的增加, 沒有随着增加, 而是呈比較平的直線, 說明目前的

網絡速度不能夠滿足目前的系統流量。

Q3 硬體和作業系統能否處理高負載? 

“Windows Resources” 圖實時地顯示了Web Server 系統資源的使用情況。利用該圖提供的資料, 可以把瓶頸定位到特定機器的某個部件。

8 經常遇到的問題

8.1 VuGen的問題

在使用VuGen 中經常會遇到的問題。

8.2 Controller的問題

在使用Controller 中經常會遇到的問題。

1. 在添加完Load Generators 機器時, 連接配接老是失敗; 添加的機器明明已經安裝了

loadrunner, 并且網絡通訊正常。

解決方法: 在安裝loadrunner 的第七步驟, 應該選擇第2 項, 如果選擇了第一項, 

就會有這種問題。重新安裝一下即可。

2. 在VuGen 中運作良好的腳本, 到Controller 中運作卻出問題。

這種問題可能會遇到。為了确定問題出在Controller 中的場景,而不是腳本的問題, 

你應該在所有的Load Generators 機器上使用VuGen 運作測試腳本, 確定都能夠運

行正确。因為VuGen 和Controller 運作的機制不一樣。在VuGen 中運作時使用的

是完整的浏覽器, 而在Controller 中運作時使用的隻是浏覽器的基本的部分。

8.3 計數器的問題

在使用性能計數器中經常會遇到的問題。

1. 添加了Windows Resources 計數器後, 卻看不到實時的資料。

解決方法: 要得到監視的資料, 必須要在被監視的伺服器(Web Server) 上獲得管

理員權限。最簡單的方法是在“ 網絡鄰居”中以administrator 身份登陸Web Server。

當然使用下面的控制台指令也可以:net use \\< 機器名> 然後登陸使用者名和密碼即

可。(登陸的使用者名必須具有管理者權限) 

2. 添加了一些預設的性能計數器後, 出現了錯誤。

解決方法: 可能是一些LoadRunner 預設的計數器在WebServer 上已經不存在的原

因, 尤其是資料庫的計數器方面。簡單的解決方法, 就是删除有問題的計數器, 添

加比較接近的計數器( 可能需要參考Windows 幫助或者資料庫的幫助) 

9.結果分析

根據不同的場景設計,配置腳本後進行測試得到如下結果

測試環境

LMM:

CPU:4x2.7G RAM:4G

Websphere 5.0 + IBM Http Server  

線程池:100

JDBC連接配接池:100

會話逾時:30分鐘

DS:

CPU:4x2.2RAM:4G

Websphere 5.0 + IBM Http Server 

線程池:100

JDBC連接配接池:100

會話逾時:30分鐘

DB&LDAP:

CPU:2x2.2GRAM:4G

Oralce 8.1.7 + LDAP

測試工具:Load Runner 7.8

使用者資料:使用者名test1 – test100; 密碼與使用者名相同。

測試用例1

測試場景描述

使用者登入的lmm子產品,總共登陸24個使用者,所有使用者都同時并發操作。 

使用者點選“登記的教程”

使用者點選“啟動”,進行課程學習,進入DS子產品

在DS子產品中進行學習,過程包括:首先,點選一次課程結構樹;然後,進行課程内容的學習。

點選“傳回LMS”按鈕,傳回到lmm子產品

點選“退出”按鈕,退出系統

測試結果

LMM與DS子產品CPU平均使用率在10%以下。LMM伺服器CPU使用率峰值為20%,其階段為LMM處理多個使用者同時的登入請求與點選“已登記教程”的學習課程查詢。DS伺服器CPU使用率峰值為100%(持續時間為7秒),其階段為DS處理多個使用者單一登入驗證和同時對課程結構樹查詢。使用者平均操作響應時間不超過5秒,所有交易成功。

測試用例2

測試場景描述

使用者登陸lmm子產品,總共登入48個使用者,每1秒登入1個使用者

使用者點選“已登記教程”

使用者點選“啟動”,進行課程學習,進入DS子產品

在DS子產品中進行學習,過程包括:首先,點選一次課程結構樹;然後,進行課程内容的學習;

點選“傳回LMS”按鈕,傳回到lmm子產品

點選“退出”按鈕,退出系統

測試結果

LMM與DS子產品CPU平均使用率在5%以下。LMM伺服器CPU使用率峰值為10%,其階段為LMM處理多個使用者同時的登入請求與點選“已登記教程”的學習課程查詢。DS伺服器CPU使用率峰值為8%,其階段為DS處理多個使用者單一登入驗證和同時對課程結構樹查詢。使用者操作響應時間不超過3秒,所有交易成功。

測試用例3

測試場景描述

使用者登入的lmm子產品,總共登陸48個使用者,所有使用者都同時并發操作。 

使用者點選“登記的教程”

使用者點選“啟動”,進行課程學習,進入DS子產品

在DS子產品中進行學習,過程包括:首先,點選一次課程結構樹;然後,進行課程内容的學習。

點選“傳回LMS”按鈕,傳回到lmm子產品

點選“退出”按鈕,退出系統

測試結果

LMM與DS子產品CPU平均使用率在20%以下。LMM伺服器CPU使用率峰值為40%,其階段為LMM處理多個使用者同時的登入請求與點選“已登記教程”的學習課程查詢。DS伺服器CPU使用率峰值為100%(持續時間為10秒),其階段為DS處理多個使用者單一登入驗證和同時對課程結構樹查詢。使用者平均操作響應時間不超過10秒,所有交易成功。

測試用例4

測試場景描述

使用者登入的lmm子產品,總共登陸48個使用者,每秒同時登入10個使用者。 

使用者點選“登記的教程”

使用者點選“啟動”,進行課程學習,進入DS子產品

在DS子產品中進行學習,過程包括:首先,點選一次課程結構樹;然後,進行課程内容的學習。

點選“傳回LMS”按鈕,傳回到lmm子產品

點選“退出”按鈕,退出系統

測試結果

LMM與DS子產品CPU平均使用率在10%以下。LMM伺服器CPU使用率峰值為10%,其階段為LMM處理多個使用者同時的登入請求與點選“已登記教程”的學習課程查詢。DS伺服器CPU使用率峰值為100%(持續時間為2秒),其階段為DS處理多個使用者單一登入驗證和同時對課程結構樹查詢。使用者平均操作響應時間不超過5秒,所有交易成功。

測試用例5

測試場景描述

使用者登入的lmm子產品,總共登入100個使用者,每1秒登入一個使用者。 

使用者點選“登記的教程”

使用者點選“啟動”,進行課程學習,進入DS子產品

在DS子產品中進行學習,過程包括:首先,點選一次課程結構樹;然後,進行課程内容的學習。

點選“傳回LMS”按鈕,傳回到lmm子產品

點選“退出”按鈕,退出系統

測試結果

LMM與DS子產品CPU平均使用率在20%以下。LMM伺服器CPU使用率峰值為10%,其階段為LMM處理多個使用者同時的登入請求與點選“已登記教程”的學習課程查詢。DS伺服器CPU使用率峰值為100%(持續時間為2’20分鐘),其階段為DS處理多個使用者單一登入驗證和同時對課程結構樹查詢。使用者最大操作響應時間30秒,所有交易成功。

測試用例6

測試場景描述

使用者登入的lmm子產品,總共登陸100個使用者,所有使用者同時并發操作。 

使用者點選“登記的教程”

使用者點選“啟動”,進行課程學習,進入DS子產品

在DS子產品中進行學習,過程包括:首先,點選一次課程結構樹;然後,進行課程内容的學習。

點選“傳回LMS”按鈕,傳回到lmm子產品

點選“退出”按鈕,退出系統

測試結果

LMM與DS子產品CPU平均使用率在20%以下。LMM伺服器CPU使用率峰值為40%,其階段為LMM處理多個使用者同時的登入請求與點選“已登記教程”的學習課程查詢。DS伺服器CPU使用率峰值為100%(持續時間為3分鐘),其階段為DS處理多個使用者單一登入驗證和同時對課程結構樹查詢。使用者逾時1個。

測試用例7

測試場景描述

使用者登入的lmm子產品,總共登陸200個使用者,所有使用者同時并發操作。 

使用者點選“登記的教程”

使用者點選“啟動”,進行課程學習,進入DS子產品

在DS子產品中進行學習,過程包括:首先,點選一次課程結構樹;然後,進行課程内容的學習。

點選“傳回LMS”按鈕,傳回到lmm子產品

點選“退出”按鈕,退出系統

測試結果

LMM CPU平均使用率在20%以下。LMM伺服器CPU使用率峰值為40%,其階段為LMM處理多個使用者同時的登入請求與點選“已登記教程”的學習課程查詢。DS伺服器CPU使用率峰值為100%(持續時間為5分鐘),其階段為DS處理多個使用者單一登入驗證和同時對課程結構樹查詢。使用者逾時108個。

10參考文獻