loadrunner自學以及問題解答2

視頻匯總地址：https://edu.51cto.com/lecturer/4626073.html

    46.LR啟動controller報錯“transaction monitor not available”

1.多是OS系統問題，修復試試或升級

2.或修復LR試試

    47.Loadrunnber 報錯誤：Error -- memory violation : Exception ACCESS_VIOLATION received.的一種情況

Posted on 2011-01-05 12:12蟈蟈俊 閱讀(433) 評論(0) 編輯收藏 

最近寫的一個Loadrunner腳本，最后一步是點擊“退出”按鈕退出登錄狀態，如下：

web_text_link("[退出]",

    "Snapshot=t18.inf",

    DESCRIPTION,

    "Text=[退出]",

    ACTION,

    "UserAction=Click",

    LAST);

return 0;

但是會報錯誤：

Action1.c(94): Error: C interpreter run time error: Action1.c (94): Error -- memory violation : Exception ACCESS_VIOLATION received.

Action1.c(94): Notify: CCI trace: Action1.c(94): web_text_link(0x02080870, 0x0208085f "Snapshot=t18.inf", 0x02080a42 "DESCRIPTION", 0x02080853, 0x02080a3b "ACTION", 0x020809de "UserAction=Click", 0x02080a6a "LAST")

Action1.c(94): Notify: CCI trace: Compiled_code(0): Action1()

經過試驗，發現是因為 退出后有個自動跳轉。

如果退出結束代碼修改為下面就沒有問題了。

    web_text_link("[退出]",

       "Snapshot=t18.inf",

       DESCRIPTION,

       "Text=[退出]",

       ACTION,

       "UserAction=Click",

       LAST);

    web_browser("Sync",

       "Snapshot=t18.inf",

       DESCRIPTION,

       ACTION,

        "Sync",

       LAST);

     return 0;

結論：

web_text_link如果有中間跳轉，不能放在代碼的最后，最后要有一個 Sync 。

    48.Step download timeout(sec)設置

     這個默認是120秒，但是經常我們要設置的更大一些，具體設置方法：Vugen--》Vuser---》Runtime-settings----》Preferences------》option，將Step download timeout(sec)默認值120s改為自己需要的值，其次要改變HTTP-reguest connnect timeout（sec）和HTTP-reguest receive timeout（sec）也為相應的值。

    49.修改本機tcp連接數

        因為個人pc機的默認的tcp連接數只有15個（xp），所以我們在模擬虛擬多個用戶時，就會遇到tcp的連接限制，從而報錯。修改的方法：windows下運行 Patch.exe

輸入C，再輸入你要的TCP/IP連接數字（一般為500～2000）回車確認

輸入Y 回車確認。

倒計時15秒后結束。

接著再運行下Patch.exe，看連接數是不是由原來的10變成自己改了的數值。

Patch.exe 下載地址：http://www.touchboy.cn/2007/05/% ... %E6%8E%A5%E6%95%B0/

    50.關于Error -27791: Error -27790:Error -27740:錯誤的解決方法：

        錯誤如下：

Action.c(198): Error -27791: Server "www.zcpx.cn" has shut down the connection prematurely

Action.c(198): Error -27790: Failed to read data from server "www.zcpx.cn": [10053] Software caused connection

abort

Action.c(198): Error -27740: Overlapped transmission of request to "www.zcpx.cn" for URL

"http://www.zcpx.cn/userEntry.do" failed: WSA_IO_PENDING

解決辦法：

在腳本的最前面加上web_set_sockets_option("OVERLAPPED","0");

    51. LR中錯誤代號為27796的一個解決方法

        錯誤如下：

52.

1A:注冊表不能訪問或寫導致的，可以恢復注冊表或卸載（清除注冊表，可以使用工具）重新安裝程序。

要啟支LR自帶的實例的服務時，出錯了，提示：端口已經被另一個服務占用，請問一下能不能自己修改這個程序原來設定的端口??？

2A:停止服務之后，在程序的安裝目錄\WebTours下找到xitami.cfg文件修改portbase值，注意 默認的端口號是portbase+80，portbase值是1000；要把端口號改成8088，就把portbase改為8008，保存之后就是了（8088=8008+80）。然后重啟服務 

二：LoadRunner面試（筆試）問題整理

1.      什么是負載測試？什么是性能測試？                                                                       

     負載測試是通過逐步增加系統負載，測試系統性能的變化，并最終確定在滿足性能指標的情況下，系統所能承受的最大負載量的測試，例如，訪問一個頁面的響應時間規定不超過1秒，負載測試就是測試在響應時間為1秒時，系統所能承受的最大并發訪問用戶的數量。

壓力測試通常是在高負載情況下來對系統的穩定性進行測試，更有效地發現系統穩定性的隱患和系統在負載峰值的條件下功能隱患等。

性能測試：指在一定的約束條件下（指定的軟件、硬件、網絡環境等），確定系統所能承受的最大負載壓力。

2.        性能測試包含了哪些測試（至少舉出3種）

　性能測試包含負載測試、壓力測試、大數據量測試、疲勞強度測試等。

3.   簡述性能測試的步驟

 第一，分析產品結構，明確性能測試的需求，包括并發、極限、配置和指標等方面的性能要求，必要時基于LOAD測試的相同測略需同時考慮穩定性測試的需求。

　　第二，分析應用場景和用戶數據，細分用戶行為和相關的數據流，確定測試點或測試接口，列示系統接口的可能瓶頸，一般是先主干接口再支線接口，并完成初步的測試用例設計。

　　第三，依據性能測試需求和確定的測試點進行測試組網設計，并明確不同組網方案的重要程度或優先級作為取舍評估的依據，必要時在前期產品設計中提出支持性能測試的可測試性設計方案和對測試工具的需求。

　　第四，完成性能測試用例設計、分類選擇和依據用戶行為分析設計測試規程，并準備好測試用例將用到的測試數據。

    第五，確定采用的測試工具。

      第六，進行初驗測試，以主干接口的可用性為主，根據測試結果分析性能瓶頸，通過迭代保證基本的指標等測試的環境。

      第七，迭代進行全面的性能測試，完成計劃中的性能測試用例的執行。

      第八，完成性能測試評估報告。

　　在進行性能測試的時候，我們需要知道一些有效的性能指標，下面我們來列出一些主要的性能指標：

　　一是，通用指標（指Web應用服務器、數據庫服務器必需測試項）：

      *ProcessorTime：指服務器CPU占用率，一般平均達到70%時，服務就接近飽和；

      *Memory Available Mbyte：可用內存數，如果測試時發現內存有變化情況也要注意，如果是內存泄露則比較嚴重；

      *Physicsdisk Time ：物理磁盤讀寫時間情況。

      二是，Web服務器指標：

      *Avg Rps：平均每秒鐘響應次數＝總請求時間/秒數；

      *Avg time to last byte per terstion（mstes）：平均每秒業務角本的迭代次數；*Successful Rounds：成功的請求；

      *Failed Rounds：失敗的請求；

      *Successful Hits：成功的點擊次數；

      *Failed Hits：失敗的點擊次數；

      *Hits Per Second：每秒點擊次數；

      *Successful Hits Per Second：每秒成功的點擊次數；

      *Failed Hits Per Second：每秒失敗的點擊次數；

      *Attempted Connections：嘗試鏈接數。

      三是，數據庫服務器指標：

      *User 0 Connections ：用戶連接數，也就是數據庫的連接數量；

      *Number of deadlocks：數據庫死鎖；

      *Butter Cache hit：數據庫Cache的命中情況。

4.         簡述使用Loadrunner的步驟

　　A4：制定性能測試計劃—>開發測試腳本—>設計測試場景—>執行測試場景—>監控測試場景—>分析測試結果

5.         什么時候可以開始執行性能測試？

　　功能測試通過；一般需要進行性能測試的系統，都是用戶量比較大、業務使用比較頻繁、比較重要的功能模塊。

6.         LoadRunner由哪些部件組成？

　　A6：主要有三部分組成：

7.         你使用LoadRunner的哪個部件來錄制腳本？

　　   使用Virtual User Generator錄制測試腳本

8.         LoadRunner的哪個部件可以模擬多用戶并發下回放腳本？

　　LoadRunner的Controller組件。

9.         什么是集合點？設置集合點有什么意義？Loadrunner中設置集合點的函數是哪個？

　   　在性能測試過程中，需要模擬大量用戶在同一時刻，訪問系統并同時操作某一任務，可以通過配置集合點來實現，多個用戶同時進行某操作；

　　  集合點可以在服務器上創建密集的用戶負載，使LoadRunner能夠測試服務器在負載狀態下的性能。

　    設置集合點函數：lr_rendezvous("Meeting")；  // Meeting是集合點名稱

10.     什么是場景？場景的重要性有哪些？如何設置場景？

 　　場景用于模擬用戶實際業務操作；

     LoadRunner中場景有手工場景和面向目標的場景。

設置場景：選擇場景類型、設置運行時設置、模擬用戶數、加減壓方式、持續時間，配置負載生成

1.選擇場景中需要的腳本

     2.選擇為目標場景，還是指定的手工場景

     3.設置用戶數、設置產生負載的設備

     4.設置執行策略

11.     請解釋一下如何錄制web腳本？

LR通過轉發請求，來捕獲數據包，來形成腳本

解釋：1.基于瀏覽器的應用程序推薦使用HTML-based Script, 腳本中采用

HTML頁面的形式來表示，這種方式的Script腳本容易維護，容易理解，使用該選項中的advance中的第一個選項，如果單純的HTML方式，是不允許使用關聯的。

2．不是基于瀏覽器的應用程序推薦使用URL-based Script，腳本中的表示采用基于URL 的方式，不是很好閱讀。

解釋：1.是否記錄錄制過程中的ThinkTime，如果記錄，還可以設置最大值，一般我不記錄這個值。

2．通知Vugen去重新設置每個action之間的Http context，缺省是需要的。

3．完整記錄錄制過程的log，

4．保存一個本地的snapshot，可以加速顯示

5．把html的title放到web_reg_find函數里面

6.支持的字符集標準

7．Http header的錄制，我們采用缺省即可，不需要用web_add_header去錄制非標準的header信息。

對錄制的content的內容進行filter，不作為resource處理的。

解釋：這個就是我前面提到的關聯，系統已經預先設置好了一些常見的關聯rules，我們錄制腳本之前，可以把系統的

12.    為什么要創建參數?如何創建參數?

  參數：在環境變化時必須時腳本具有環境變化的能力，就需要參數化（客戶端發送到服務器端）

  1.確定要參數話的數據

  2.設定規則形式來取值

13.    什么是關聯？請解釋一下自動關聯和手動關聯的不同。

關聯：很多構架用sessionid等方法標識不同任務和數據，應用在每次運行時方式發送數據不完全相同，需要利用的機制對錄制的腳本進行處理，這種機制叫做關聯（服務端發送到客戶端）

14.    場景設置有哪幾種方法？

目標場景，手工場景

15.    你如何找出哪里需要關聯？請給一些你所在項目的實例。

用戶登陸，

客戶端發送請求后，服務端驗證正確性后，發送給客戶端sessionid，是某種規則產生。

16.    你在哪里設置自動關聯選項？

兩地方可以設置

1.設置允許錄制時進行自動關聯，可以自定義規則

2.錄制完成后，vuser-scan action for correlations

17.    哪個函數是用來截取虛擬用戶腳本中的動態值？（手工關聯）

web_reg_save_param()函數主要根據需要做關聯的動態數據前面和后面的固定字符串來識別、提取動態數據，所以在做關聯時，需要找出動態數據的左、右邊界字符串。

18.    你在VUGen中何時選擇關閉日志？何時選擇標準和擴展日志？

Run-time，log，

當調試腳本時，可以只輸出錯誤日志，當在場景找你管加載腳本時，日志自動變為不可用。

Standard Log Option：選擇標準日志時，就會在腳本執行過程中，生成函數的標準日志并且輸出信息，供調試用。大型負載測試場景不用啟用這個選項。

擴展日志包括警告和其他信息。大型負載測試不要啟用該選項。用擴展日志選項，可以指定哪些附加信息需要加到擴展日志中

19.    你如何調試LoadRunner腳本？

VuGen有兩個選項幫助調試Vuser腳本。Run Step by Step命令和斷點（breakpoints）。Option對話框中的調試設置（Debug setting）項，可以確定在場景執行過程中執行軌跡范圍。調試信息寫在output窗口?？梢杂?nbsp;

lr_set_debug_messag函數在腳本中手工設置信息類型。如果我們只想接收到一小段腳本的調式信息。

20.    你在LR中如何編寫自定義函數？請給出一些你在以前進行的項目中編寫的函數。

在創建用戶自定義函數前我們需要和創建DLL（external libary）。把庫放在VuGen bin目錄下。一旦加了庫，把自定義函數分配做一個參數。該函數應該具有一下格式：__declspec (dllexport) char* (char*, char*)。

Milan

21.    什么是逐步遞增？你如何來設置？

Ramp up這個選項用于逐漸增加服務器的虛擬用戶數或負載量。設置一個初始值而且可以在兩個迭代之間設置一個值等待。設置Ramp up，請到‘Scenario Scheduling Options’。

22.    以線程方式運行的虛擬用戶有哪些優點？

VuGen提供了用多線程的便利。這使得在每個生成器上可以跑更多的虛擬用戶。如果是以進程的方式跑虛擬用戶，為每個用戶加載相同的驅動程序到內存中，因此占用了大量的內存。這就限制了在單個生成器上能跑的虛擬用戶數。如果按線程運行，給定的所有虛擬用戶數（比如100）只是加載一個驅動程序實例到內存里。每個線程共用父驅動程序的內存，因此在每個生成器上可以跑更多的虛擬用戶。

23.    當你需要在出錯時停止執行腳本，你怎么做？

lr_abort函數放棄虛擬用戶腳本的執行。說明虛擬用戶停止Action的執行，直接執行vuser_end然后結束執行。在出現錯誤情況下想手工放棄腳本的執行，這個函數是有用的。用這個函數停止腳本時，Vuser被指定為“Stopped”狀態。為了這個函數起作用，開始時候就不能選擇Run-Time Settings中的Continue on error選項。

24.    響應時間和吞吐量之間的關系是什么？

吞吐量圖顯示的是虛擬用戶每秒鐘從服務器接收到的字節數。當和響應時間比較時，可以發現隨著吞吐量的降低，響應時間也降低，同樣的，吞吐量的峰值和最大響應時間差不多在同時出現。

25.    說明一下如何在LR中配置系統計數器？

通過Web資源監視器，利用這些監控器可以分析web服務器的吞吐量、點擊率、每秒http響應數以及每秒下載的頁面數。

26.    什么是think time？think_time有什么用？

思考時間是真實用戶在action之間等待的時間。例如：當一個用戶從服務器接收到數據時，用戶可能需要在響應之前等待幾分鐘回顧數據，這種推遲被稱為思考時間。

27.    標準日志和擴展日志的區別是什么？

Standard Log Option：選擇標準日志時，就會在腳本執行過程中，生成函數的標準日志并且輸出信息，供調試用。大型負載測試場景不用啟用這個選項。

擴展日志包括警告和其他信息。大型負載測試不要啟用該選項。用擴展日志選項，可以指定哪些附加信息需要加到擴展日志中

28.    解釋以下函數及他們的不同之處。

Lr_debug_message

lr_debug_message 函數在指定的消息級別

// 處于活動狀態時發送一條調試消息。如果指定的

// 消息級別未處于活動狀態，則不發出消息。

Lr_output_message

要發送不是特定錯誤消息的特殊通知，

Lr_error_message

函數將錯誤消息發送到

// 輸出窗口和 Vuser日志文件

Lrd_stmt lrd_exec 函數執行 lrd_stmt設置的 SQL 語句。

Lrd_fetch  函數從結果集中提取后續若干行

result set. 

函數準備用于

// 通過光標輸出字符串（通常為 SQL語句）

// 的下一結果集。對于 CtLib，它發出 ct_result

// 命令，并且在 ODBC中它運行用于當前數據庫

29.    什么是吞吐量？

單位時間內系統處理客戶端的請求數。

30.    action和init、end除了迭代的區別還有其他嗎？

在init、end中不能使用集合點、事務等, init、end只執行一次。

31.    在什么地方設置HTTP頁面filter?

       在runtime_settings中download filter里面進行設置。

32.    pot mapping的原理是什么？

       就是代理服務器

33.    HTTP的超時有哪三種？

HTTP-request connect timeout、HTTP-request receive timeout、step download timeout

34.    什么是contentcheck?如何來用？

ContentCheck的設置是為了讓VuGen檢測何種頁面為錯誤頁面。如果被測的Web 應用沒有使用自定義的錯誤頁面，那么這里不用作更改；如果被測的Web應用使用了自定義的錯誤頁面，那么這里需要定義，以便讓VuGen 在運行過程中檢測，服務器返回的頁面是否包含預定義的字符串，進而判斷該頁面是否為錯誤頁

面。如果是，VuGen就停止運行，指示運行失敗。

使用方法：點擊在runtime settings中點擊“contentcheck”，然后新建立一個符合要求的應用程序和規則，設定需要查找的文本和前綴后綴即可使用。

35.    network中的speed simulation是模擬的什么帶寬？

模擬用戶訪問速度的帶寬。

36.    生成WEB性能圖有什么意義？大概描述即可。

可以很直觀的看到，在負載下系統的運行情況以及各種資源的使用情況，可以對系統的性能瓶頸定位、性能調優等起到想要的輔助作用。

37.    如果刷新controller里的腳本？

在controller中，點擊detailis－Refresh-script即可。

38.    進程和線程有什么區別？

線程有自己的全局數據。線程存在于進程中,因此一個進程的全局變量由所有的線程共享。由于線程共享同樣的系統區域,操作系統分配給一個進程的資源對該進程的所有線程都是可用的,正如全局數據可供所有線程使用一樣。在Controller中將使用驅動程序（如mdrv.exe、r3vuser.exe）運行vuser。如果按進程運行每個vuser，則對于每個vuser實例，都將反復啟動同一驅動程序并將其加載到內存中。將同一驅動程序加載到內存中會占用大量的RAM（隨機存儲器）及其他系統資源。這就限制了可以在任一負載生成器上運行的vuser數量。如果按線程運行每個vuser，Controller為每50個vuser（默認情況下）僅啟動驅動程序（如mdrv.exe）的一個實例。該驅動程序將啟動幾個vuser，每個vuser都按線程運行。這些線程vuser將共享父驅動進程的內存段。這就消除了多次重新加載驅動程序/進程的需要，節省了大量內存空間，從而可以在一個負載生成器上運行更多的Vuser.

39.    如何把腳本和結果放到load generator的機器上？

    在controller中，點擊Results-Results settings,在里面進行相應的設置即可。

40.    如何設置才能讓集合點只對一半的用戶生效？

   對集合點策略進行相應的設置即可。即在controller中，點擊Scenario－Rendezvous-policy進行相應的設置即可，由于題目中“一半的用戶”沒有說明白具體指什么樣的用戶，現在不好確定具體對里面的哪個選項進行設置。

41.    LRd的API分為幾類

Ａ：通用的ＡＰＩ：，就是跟具體的協議無關，在任何協議的腳本里都能用的；

Ｂ：針對協議的：像lrs前綴是winsock的；lrd的是針對database;

Ｃ：自定義的：這個范圍就比較廣了；比如至少有Java Vuser API、lrapi、XML API。還可以添加WindowsAPI和自定義函數庫。

42.    LR幾種日志函數的區別？

【lr_message】 int lr_message (const char *format, exp1, exp2,…expn.);中文解釋：lr_message函數將信息發送到日志文件和輸入窗口。在VuGen中運行時，輸入文件為output.txt。

【lr_log_message】 int lr_log_message (const char *format, exp1, exp2,…expn.);中文解釋：lr_log_message函數將消息發送到Vuser或代理日志文件（取決于應用程序），而不是發送到輸出窗口。通過向日志文件發送錯誤消息或其他信息性消息，可以將該函數用于調試。                   【lr_error_message】 int lr_error_message (const char *format, exp1, exp2,…expn. );中文解釋：lr_error_message函數將錯誤消息發送到輸出窗口和Vuser日志文件。要發送不是特定錯誤消息的特殊通知，請使用lr_output_message。

【lr_output_message】 int lr_output_message (const char *format, exp1, exp2,…expn.);中文解釋：lr_output_message函數將帶有腳本部分的行號的消息發送到輸出窗口和日志文件。

【lr_debug_message函數組】 int lr_debug_message (unsigned int message_level, const char *format, … );中文解釋：lr_debug_message函數在指定的消息級別處于活動狀態時發送一條調試信息。如果指定的消息級別未出于活動狀態，則不發送消息。您可以從用戶界面或者使用lr_set_debug_message，將處于活動狀態的消息級別設置為MSG_CLASS_BRIEF_LOG或MSG_CLASSS_EXTENDED_LOG。要確定當前級別，

請使用lr_get_debug_message。 unsigned int lr_get_debug_message ( );中文解釋：lr_get_debug_message函數返回當前的日志運行時設置。該設置確定發送到輸出端的信息。日志設置是使用運行時設置對話框或通過使用lr_set_debug_message函數指定的。 int lr_set_debug_message (unsigned int message_level, unsigned int on_off); 中文解釋：lr_set_debug_message函數設置腳本執行的調試消息級別message_lvl。通過設置消息級別，可以確定發送哪些信息。啟動設置的方法是將LR_SWITCH_ON作為on_off傳遞，禁用設置的方法是傳遞LR_SWITCH_OFF。

【lrd_stmt】：將SQL語句與光標關聯

【lrd_fetch】:提取結果集中得下一條記錄

43.    性能瓶頸分析方法？

 同一場景

1.小用戶量的情況下測試

2.大用戶量情況下的測試

分析的方法：

整個系統架構分析，系統響應時間消耗，利用圖表分析

查看事務響應時間，通過事務摘要圖分析事務響應時間，那個消耗最大（通過小用戶量和大用戶量的響應時間分析，查看那個事務響應時間最高），確定哪部分功能是性能的瓶頸，分析window resource圖表，查看cpu

使用下列計數器標識cpu瓶頸

Processor\ Interrupts/sec

Processor\ % Processor Time

Process(process)\ % Processor Time

System\ Processor Queue Length

通過它來確定是否硬件本身出現瓶頸，或者進一步確定應該怎么去判斷性能產生瓶頸的地方！

下一步去判斷進程，那個進程消耗cpu最高

下邊就有很多種情況需要你自己去判斷，有可能是進程調用了的函數消耗了系統資源形成上邊的問題，也有可能是后臺數據庫出現的問題（這個就要看你的系統配置是什么樣的，比如你的db服務器和應用服務器都配置在一臺機器上）

性能產生瓶頸有很多地方，所以需要進一判斷，是否是后臺數據庫的問題還有待分析，是那條語句導致的問題需要進一步分析判斷。

分析原則：

 具體問題具體分析（這是由于不同的應用系統，不同的測試目的，不同的性能關注點）

 查找瓶頸時按以下順序，由易到難。

服務器硬件瓶頸-〉網絡瓶頸（對局域網，可以不考慮）-〉服務器操作系統瓶頸（參數配置）-〉中間件瓶頸（參數配置，數據庫，web服務器等）-〉應用瓶頸（SQL語句、數據庫設計、業務邏輯、算法等）

注：以上過程并不是每個分析中都需要的，要根據測試目的和要求來確定分析的深度。對一些要求低的，我們分析到應用系統在將來大的負載壓力（并發用戶數、數據量）下，系統的硬件瓶頸在哪兒就夠了。

 分段排除法很有效

分析的信息來源：

1 根據場景運行過程中的錯誤提示信息

2 根據測試結果收集到的監控指標數據

一．錯誤提示分析

分析實例：

1 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、應用服務死掉。

（小用戶時：程序上的問題。程序上處理數據庫的問題）

B、應用服務沒有死

（應用服務參數設置問題）

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

C、數據庫的連接

(1、在應用服務的性能參數可能太小了 2、數據庫啟動的最大連接數（跟硬件的內存有關）)

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

分析：可能是以下原因造成

A、應用服務參數設置太大導致服務器的瓶頸

B、頁面中圖片太多

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

二．監控指標數據分析

1．最大并發用戶數：

應用系統在當前環境（硬件環境、網絡環境、軟件環境（參數配置））下能承受的最大并發用戶數。

在方案運行中，如果出現了大于3個用戶的業務操作失敗，或出現了服務器shutdown的情況，則說明在當前環境下，系統承受不了當前并發用戶的負載壓力，那么最大并發用戶數就是前一個沒有出現這種現象的并發用戶數。

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

2．業務操作響應時間：

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

 細分事務并分析每個頁面組件的性能。查看過長的事務響應時間是由哪些頁面組件引起的？問題是否與網絡或服務器有關？

 如果服務器耗時過長，請使用相應的服務器圖確定有問題的服務器度量并查明服務器性能下降的原因。如果網絡耗時過長，請使用“網絡監視器”圖確定導致性能瓶頸的網絡問題

3．服務器資源監控指標：

內存：

1 UNIX資源監控中指標內存頁交換速率（Paging rate），如果該值偶爾走高，表明當時有線程競爭內存。如果持續很高，則內存可能是瓶頸。也可能是內存訪問命中率低。

2 Windows資源監控中，如果Process\Private Bytes計數器和Process\Working Set計數器的值在長時間內持續升高，同時Memory\Available bytes計數器的值持續降低，則很可能存在內存泄漏。

內存資源成為系統性能的瓶頸的征兆:

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

進程進入不活動狀態;

交換區所有磁盤的活動次數可高;

可高的全局系統CPU利用率;

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

處理器：

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

合理使用的范圍在60%至70%。

2 Windows資源監控中，如果System\Processor Queue Length大于2，而處理器利用率（Processor Time）一直很低，則存在著處理器阻塞。

CPU資源成為系統性能的瓶頸的征兆:

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

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

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

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

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

磁盤I/O：

1 UNIX資源監控（Windows操作系統同理）中指標磁盤交換率（Disk rate），如果該參數值一直很高，表明I/O有問題?？煽紤]更換更快的硬盤系統。

2 Windows資源監控中，如果 Disk Time和Avg.Disk Queue Length的值很高，而Page Reads/sec頁面讀取操作速率很低，則可能存在磁盤瓶徑。

I/O資源成為系統性能的瓶頸的征兆 :

過高的磁盤利用率(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．數據庫服務器：

SQL Server數據庫：

1 SQLServer資源監控中指標緩存點擊率（Cache Hit Ratio），該值越高越好。如果持續低于80%，應考慮增加內存。

2 如果Full Scans/sec（全表掃描/秒）計數器顯示的值比1或2高，則應分析你的查詢以確定是否確實需要全表掃描，以及SQL查詢是否可以被優化。

3 Number of Deadlocks/sec(死鎖的數量/秒)：死鎖對應用程序的可伸縮性非常有害，并且會導致惡劣的用戶體驗。該計數器的值必須為0。

4 Lock Requests/sec(鎖請求/秒)，通過優化查詢來減少讀取次數，可以減少該計數器的值。

Oracle數據庫：

1 如果自由內存接近于0而且庫快存或數據字典快存的命中率小于0.90，那么需要增加SHARED_POOL_SIZE的大小。

快存（共享SQL區）和數據字典快存的命中率：

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

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

自由內存 select * from v$sgastat where name=’free memory’;

2 如果數據的緩存命中率小于0.90，那么需要加大DB_BLOCK_BUFFERS參數的值（單位：塊）。

緩沖區高速緩存命中率：

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))

3 如果日志緩沖區申請的值較大，則應加大LOG_BUFFER參數的值。

日志緩沖區的申請情況：

select name,value from v$sysstat where name = ‘redo log space requests’ ;

4 如果內存排序命中率小于0.95，則應加大SORT_AREA_SIZE以避免磁盤排序。