LR性能測試應用

時間 2019-12-01

原文原文鏈接

上半個月，因爲工做和上課兩邊跑，幾乎沒有屬於本身的時間去作本身想作的事，在沒有加班的一天晚上，我忽然衝動地跑到圖書館借了一本書《LR性能測試應用》——姜豔。html

我總喜歡看那些陳舊的書，由於在咱們忙碌的生活中，它又讓我不經意間拾起了那一段記憶。一本好書，能夠改變一我的的一輩子，是由於從中使用我獲得知識的渴望和追求，不斷地總結，不斷地成長。。。。。。web

《LR性能測試應用》我花了半個月看這確是一本好書，書中內容分爲三部分，「基礎篇」、「提升篇」、「實戰篇」。看完了這本書我最大的收穫是，有了一個明確的LR性能測試思想和思路。在「基礎篇」中，認識到一些曾經一直模糊的性能測試概念，以及LR的工做原理；算法

在「提升篇」中，從LR建立腳本，對腳本的優化（包括設置事務、參數化、關聯、IP欺騙）以及對腳本中出錯的處理、調優等，再從建立場景中，設置場景的策略方法，集合點的策略設置，還有對不一樣服務器的監控分配和負載均勻等，最後對Analysis分析圖表說明、結果總結。sql

1、提升篇：數據庫

性能測試的核心原來，其實就是，經過將生產時的工做量應用於部署系統來衡量系統性能和最終用戶體驗。瀏覽器

對性能測試的一些模糊概念，一直沒有認真研究弄懂區分過，關於壓力測試和負載測試有什麼區別尚未弄懂的，以下是個人博客：http://www.cnblogs.com/luihengk/archive/2012/09/20/2695366.html緩存

在這裏我只強調幾個概念：服務器

併發用戶數：關於併發用戶數，有兩種常見的錯誤理解：一種是把併發用戶數量理解爲使用系統的所有用戶的數量，理由是這些用戶可能同時使用該系統；另外一種相對接近的觀點是把用戶在線數量理解爲併發用戶數量。實際上，在線用戶不必定會和其餘用戶發生併發，例如正在瀏覽網頁信息的用戶，對服務器沒有任何影響的。正確的理解是在同一時刻與服務器進行交互的在線用戶數量。對服務器而言，是否併發的關鍵是看用戶的操做是否對服務器產生了影響。這種交互能夠是單向的數據傳送，也能夠是雙向的數據傳送。網絡

在實戰經驗中，通常的併發用戶數量=在線用戶數*（5%～20%）；併發

響應時間：是指從客戶端發送一個請求開始計時，到客戶端接收到從服務器端返回的響應結果結束計時所經歷的時間，通常狀況下，響應時間是由網絡傳輸時間。服務器處理時間和瀏覽器顯示時間三部分組成。

（TTLB，即爲請求響應時間，意思是從發送一個請求開始，到客戶端收到最後一個字節的響應爲止所耗費的時間。）

吞吐量：就是吞吐量/傳輸時間，用來指單位時間內網絡上傳輸的數據量，也能夠指單位時間內處理的客戶端請求數量。

TPS：每秒鐘系統可以處理的交易或事務的數量。

點擊率：指每秒鐘用戶向Web服務器提交的HTTP請求數。

（注意：這裏的點擊不是指用鼠標的一次單擊操做，困爲在一次單擊操做中，客戶端可能向服務器發出多個HTTP請求）

整體上，LR的性能測試的工做流程大概以下：

一、建立腳本(Virtual User Generator)

在建立腳本的時候須要注意的是，要選擇與應用程序相對應的正確的協議，否則在瀏覽器錄製會沒有內容，若是不知道應用程序是基於哪一種腳本語言協議的，能夠經過一些工具進行捕獲數據包，進而分析，如網絡捉包軟件OmniPeek4.1。

在進行性能測試時，大部分對web性能測試，選擇「Web(HTTP/HTML)」協議便可，但錄製完腳本後，回放腳本中有時會發生中斷或者中止的狀況，查看錯誤時，若是沒法找到SOAP文檔字樣時，就須要考慮更換腳本錄製協議了。一般首先考慮更換Web Services協議，再錄製腳本。

在開始錄製的時候，須要對運行環境進行設置

如圖：

設置好環境後，必需要對錄製的腳本進行優化

例如：

腳本：

//首頁登陸退出錄製

Action()

{

web_url("WebTours",

"URL=http://127.0.0.1:1080/WebTours/",

"Resource=0",

"RecContentType=text/html",

"Referer=",

"Snapshot=t1.inf",

"Mode=HTML",

LAST);

lr_think_time(13);//思考時間，在錄製過程當中能夠忽略

web_reg_find("Text=Welcome",

LAST); //設置檢查點

lr_start_transaction("login"); //設置開始事務

web_reg_save_param("username", //設置關聯

"LB=Thank you, <b>",

"RB=</b>, for registering and welcome to the Web Tours family.",

"Ord=ALL",

"Search=NoResource",

LAST);

web_submit_form("login.pl",

"Snapshot=t2.inf",

ITEMDATA,

"Name=username", "Value={username}", ENDITEM, //設置參數化

"Name=password", "Value={password}", ENDITEM, //

"Name=login.x", "Value=59", ENDITEM,

"Name=login.y", "Value=10", ENDITEM,

LAST);

lr_end_transaction("login", LR_AUTO);//設置結束事務

lr_rendezvous("login"); //設置集合點

lr_think_time(4);

web_image("SignOff Button",

"Alt=SignOff Button",

"Snapshot=t3.inf",

LAST);

return 0;

}

在咱們錄製了腳本後，能夠完善腳本呢？

一、錄製完腳本後，第一件事情就是回放腳本，若是沒有報錯，能夠在腳本中插入事務，也能夠在錄製的時候插入事務，建議採用在腳本的錄製過程當中插入事務的方法，這樣就不至於遺漏程序中應插入事務的操做了。

二、插入集合點，須要明確的是，須要在併發哪一個業務任務操做前插入集合點，如：在一個登陸操做或者查詢操做插入，輸入集合點的名字要顧名思義。（注意：集合點只能在Action中插入，不能在vuser_init 或 vuser_end中插入）

三、插入註釋，「Insert——Comment」。

四、插入LR API經常使用函數。

如： web_custom_request();

Web_image();

Web_link();

五、腳本參數化，必須選定參數化的格式類型，如是日期型、仍是導入數據庫參數化。

參數化設置以下操做：

用參數替換腳本中的常量；
爲參數設置屬性和數據源；

須要注意事項：在參數化的過程當中，只有函數中的參數能被參數化，並且也不是全部的函數中的參數都能參數化，如Lrd_stmt只能參數化mpcText；參數化只能夠用於一個函數中的參量，但不能用參數表示非函數參數的字符串，關聯函數是不能參數化的。

六、腳本關聯(手動關聯)，操做步驟以下：

使用相同的業務流程與數據，錄製兩份腳本；
使用WinDiff工具協助找出須要關聯的數據；
使用web_reg_save_param函數手動創建關聯；
將腳本中有用到關聯的數據，以參數取代；

在這裏必須說明：在Recording Log（單協議）或是 Generation Log（多重協議）中找到不能肯定是否須要關聯的數據時，這時要確認數據是否爲從服務器端傳送過來的。首先能夠檢查數據的標頭，從標頭的Receiving response能夠知道數據是不是從服務器端傳送到客戶端的。假如此數據第一次出現是在Sending request中，則表示此數據是由客戶端產生，不須要作關聯，可是有可能須要作Parameterized（參數化）。

二、建立場景（Controller）

在建立場景的設置中，就須要對用戶的需求來設置場景了，能夠按方案計劃實施（Schedule by Scenario），也能夠案組計劃實施(Schedule by Group)，而後打開「Scenario Start」設置方案開始策略。

配置方案：在配置方案時，須要對運行時環境的設置「Tools——Options」

方案模式的選擇有兩種狀況：一種是百分比方案模式，一種是面向目標的方案模式。若是用戶需求比較明確，能夠選擇面向目標的方案模式，設置指望值。

注意：在設置方案計劃中，持續時間設置將覆蓋Vuser迭代設置。這意味着，若是將持續時間設置爲5分鐘，那麼Vuser將繼續在5分鐘時間內運行儘量多的迭代，即便運行時設置僅指定一次迭代。

三、結果分析(Analysis)

當場景運行結束後，能夠經過Analysis採集到數據信息（主要是圖表），咱們能夠根據以一幾種方式分析這些數據：

一、查看Vuser Log文件，這些文件包括了場景運行過程當中每一個用戶的跟蹤數據，Vuser Log 文件通常放在腳本目錄中；

二、在控制檯中輸出窗口查看場景的執行過程信息；

三、使用Aanalysis模塊分析執行結果圖表；

四、使用直接生成的圖表查看原始數據——Graph Data 或者 Raw Data ；

五、讓LR自動生成HTML或Word格式的測試報告，經過報告進行分析。

在這裏說下，Analysis摘要報告包含一個事務百分比列，默認爲90%的事務響應時間（90%是一個統計響應時間的參數，代表該事務全部的運行次數中，90%的次數落在這個響應時間內），此數值如沒有特殊要求不用改動。

2、提升篇

設置關聯：在腳本中設置手動關聯一貫是個難題，有些關聯的地方是有多處，前面的關聯若是沒有執行經過，執行將中止驗證腳本的正確性，後面須要作關聯的部分沒法被掃描出來。

在關聯中，如何打印出參數值？

Lr_output_message(「valueCaptured=%s」,lr_eval_string(「{ParameterName}」));

IP欺騙配置方法：IP Spoofer 應該在鏈接負載生成器以前啓用。同時，各個負載生成器機器必須使用固定的IP，不能使用動態IP（即DHCP）。

第一次運行IP Wizard須要選擇第一項「Create new settings」；若是之前運行過IP Wizard，能夠選擇第二項「Load previous setting from file」,選擇之前保存的文件；第三項用於使用「IP Spoofer」進行測試完成後，釋放IP的過程，由於該機器會點用大量的IP資源，可能會致使其餘機器沒有IP可用，使用該項，可使系統恢復到原來的情況。

當咱們成功配置了IP Spoofer後，須要從新啓動計算機，虛擬IP設置才成功，能夠在「開始->運行->」輸入cmd ，在窗口輸入「ipconfig/all」命令查看已生效的全部IP

爲了使用LR配置的虛擬IP，還須要在控制檯中對場景進行正確的設置，選擇「Scenario > Enable IP Spoofer」，設置容許使用IP欺騙。

對Oracle監控配置：安裝好Oracle後，須要在Oracle的客戶端中配置服務名，步驟以下圖：

一、啓動「Net Configuration Assistant」界面，選擇：

二、下一步，選擇「添加」

三、下一步，填寫數據庫名：

四、下一步，選擇協議：

六、下一步，填寫機器的IP：

七、最後一步進行配置測試：

若測試配置鏈接未成功，則須要」更改口令」，由於默認值爲系統管理員的用戶名和口令（都是「system」）,可使用事先已配置好的用戶登陸，而後用sqlplus鏈接一下，嘗試用戶登陸，看是否能夠鏈接成功。

最後，在LR的場景監控中，添加Oracle計數器，實行監控便可。

HTTP服務器狀態碼：

消息1XX：該類狀態代碼用於表示臨時響應，臨時響應狀態行以及可選標題組合。

消息2XX：該類狀態代碼表示客戶端請求被成功接收、理解或接受。

HTTP 200 OK 請求成功；

HTTP 201 Created 請求完成；

HTTP 204 No Content 無內容；

消息3XX：表示重定向，該類狀態碼用戶代理要想完成請求，還須要發出進一步的操做。這些操做只有當後跟的請求是GET或者HEAD時，纔可由用戶代理實現，而不用現用戶進行交互。用戶代理永遠也不要對請求進行5次以上的重定向操做，這樣可能致使無限循環。

消息4XX：表示客戶端錯誤，如時客戶端在收到此類狀態代碼時，請求尚未完成，它應當當即終止向服務器發送數據。

HTTP 400 Bad Request 非法請求；

HTTP 401 Unauthorized 未受權；

HTTP 403 Forbidden 禁止；

HTTP 404 Not Found 沒有找到；

消息5XX：表示服務器錯誤，不能繼續執行請求

HTTP 500 Internal Server Error 服務器內部錯誤

HTTP 501 Not Implementec 未實現

HTTP 502 Bad Gateway 非法網關

HTTP 503 Service Unavailable 服務不可用

LR默認計數器：

性能計數器一般用來衡量被測系統當前的情況和進行性能測試結果分析。如面對經常使用的計數器值進行分析：

1）、與進程Process相關

%process Time ：被處理器消耗的處理器時間數量。多數用於監測服務器（如：數據庫服務器或應用服務器），該值通常不要超過85%；

Page Faults/sec ：處理器處理錯誤頁的綜合速率，錯誤頁數/秒，表示當處理器請求一個不在其工做集（在物理內存中的空間）內的代碼或數據時出現的頁錯誤數=軟錯誤數（在物理內存中訪問出錯）+硬錯誤（在磁盤中訪問出錯）數；

（注意：處理器在有大量軟錯誤下仍然能夠繼續操做，而出現硬錯誤時，則能夠致使明顯的延遲）

Pages Input/sec ：指爲解決頁錯誤時而每秒從磁盤上讀取的頁數，越少越好；

Pages Reads/sec ：指爲解析硬錯誤而每秒讀取磁盤的次數，若是該值比率持續保持爲5，則表示可能內存不足；

Work set ：處理線程最近使用的內存頁，反映了每個進程使用的內存頁的數量，該值越低越好；

Private Bytes ：此進程所分配的沒法與其餘進程共享的當前字節數量。若是系統性能隨着時間而下降，它是檢測內存泄露的最佳觀察指示器；

2）、與處理器Processor相關

%Processor Time ：若是該值持續超過95%，代表是CPU瓶頸；

Processor Queue Length ：指處理隊列中的線程數，顯示在由Web服務器全部處理器共享的隊列中等待執行的線程數，若是該值持續大於2，則表示處理器瓶頸了；

%User Time ：非內核操做耗費的CPU時間。通常來講吧，若是系統中使用了大量的算法或者複雜的計算，該值是比較大的；

%Privileged Time ：CPU內核時間是在特權模式下處理線程執行代碼所花的時間%，該值越低越好；

%DPC Time CPU消耗在網絡處理上的時間，該值越低越好（與網絡有關）；

3）、與內存Memory相關

Available Mbytes ：可用物理內存數，通常要大於機器物理內存的1/2個字節；

Pages/sec ：代表因爲硬件頁面錯誤而從磁盤讀取出來的頁面數，或是因爲頁面錯誤而寫入磁盤以釋放工做集空間的頁面數；

Cache Bytes ：文件系統緩存，默認狀況下是50%的可用物理內存；

4）、與物理磁盤Physical Disk相關

%Disk Time ：所選磁盤驅動器忙於爲讀或寫請求提供服務所用的時間的%；

%Aerage Disk Queue Length ：指讀取和寫入請求的平均數，該值不該超過磁盤數的1.5～2倍；

Disk Queue Length 指標顯示磁盤中未完成的請求數量，若是隊列長度始終大於3，則表示磁盤或者內存問題，須要進一步分析；

Current Disk Queue Length指標的值應該平均小於2，若是%Disk Time 比較大，而該值又大於2，此時是磁盤瓶頸，須要提升系統磁盤處理性能；

5）、與網絡接口相關

Bytes Total/sec ：爲發送和接收字節的速率，能夠判斷網絡鏈接速度是不是瓶頸；

Current Bandwidth ：指以位/每秒估計的網絡接口的當前帶寬；

Output Queue Length ：爲輸出數據隊列（數據包）的長度。若是該值大於2，則會出現延緩現象；

6）、SQL Server 、Oracle 、IIS 、Tuxedo 、weblogic 等計數器的分析略；

LR計數器監控值我的分析思路：

判斷處理器CPU瓶頸：先看Processor Queue Length 是否大於2，再看%Processor Time 一個或多個處理器的相應數值是否持續超過90%，若是以上狀況都出現，則表示此測試的負載對於目前的硬件過於沉重了，處理器有多是瓶頸，此時還須要監控%Interrupt Time 計數器，若是該計數器持續大於15%，而處理器使用率也持續超過90%，就能夠判定處理器負荷太重，沒法知足業務增加的須要，處理器是系統瓶頸點。

判斷內存Memery瓶頸：先看 Available Mbytes的值是否持續很小來判斷是否有存在嚴重內存泄露的跡象，再看Page Read/sec的值，若是Pages/sec和Page Faults/sec的值持續很高，這時判斷多是內存有問題，此時再檢查Pages Read/sec的值是否超過5，若是是大於5，則能夠肯定是內存存在問題了。

判斷磁盤Disk瓶頸：先看Disk Time指標和Avg.Disk Queue Length 指標的值都很高，而Page Reads/sec頁面讀取操做速率很低，則能夠肯定是磁盤存在問題；再者，查看Disk Queue Length 值始終大於3，Current Disk Queue Length 也大於2，則表示磁盤存在問題了。

LR部分函數中文翻譯：http://www.cnblogs.com/luihengk/

3、實戰篇

一、如何分析性能需求指標呢？

1）、併發用戶指標：併發用戶數>=？？

2）、系統響應時間指標：頁面響應時間<=？？

3）、系統穩定性指標：系統有效工做時間要求>=？？%

Web服務持續穩定工做時間>=？？天或（小時）

4）、系統吞吐量指標：吞吐量？？如：完成業務狀況（數據庫容量）>=？？萬筆交易數

5）、業務處理能力性能指標：每筆業務的響應時間<=？？

登陸要求響應時間<=？？

業務處理能力（即每秒請求數）>=？？

TPS（每秒交易數）>=？？