上半個月，由於工作和上課兩邊跑，幾乎沒有屬於自己的時間去做自己想做的事，在沒有加班的一天晚上，我突然衝動地跑到圖書館借了一本書《LR性能測試應用》——姜豔。
我總喜歡看那些陳舊的書，因爲在我們忙碌的生活中，它又讓我不經意間拾起了那一段記憶。一本好書，可以改變一個人的一生，是因爲從中使用我得到知識的渴望和追求，不斷地總結，不斷地成長。。。。。。
《LR性能測試應用》我花了半個月看這確是一本好書，書中內容分爲三部分，“基礎篇”、“提高篇”、“實戰篇”。看完了這本書我最大的收穫是，有了一個明確的LR性能測試思想和思路。在“基礎篇”中，認識到一些曾經一直模糊的性能測試概念，以及LR的工作原理；
在“提高篇”中，從LR創建腳本，對腳本的優化（包括設置事務、參數化、關聯、IP欺騙）以及對腳本中出錯的處理、調優等，再從創建場景中，設置場景的策略方法，集合點的策略設置，還有對不同服務器的監控分配和負載均勻等，最後對Analysis分析圖表說明、結果總結。
一、提高篇：
性能測試的核心原來，其實就是，通過將生產時的工作量應用於部署系統來衡量系統性能和最終用戶體驗。
對性能測試的一些模糊概念，一直沒有認真研究弄懂區分過，關於壓力測試和負載測試有什麼區別還沒有弄懂的，如下是我的博客：http://www.cnblogs.com/luihengk/archive/2012/09/20/2695366.html
在這裏我只強調幾個概念：
併發用戶數：關於併發用戶數，有兩種常見的錯誤理解：一種是把併發用戶數量理解爲使用系統的全部用戶的數量，理由是這些用戶可能同時使用該系統；另一種相對接近的觀點是把用戶在線數量理解爲併發用戶數量。實際上，在線用戶不一定會和其他用戶發生併發，例如正在瀏覽網頁信息的用戶，對服務器沒有任何影響的。正確的理解是在同一時刻與服務器進行交互的在線用戶數量。對服務器而言，是否併發的關鍵是看用戶的操作是否對服務器產生了影響。這種交互可以是單向的數據傳送，也可以是雙向的數據傳送。
在實戰經驗中，一般的併發用戶數量=在線用戶數*（5%～20%）；
響應時間：是指從客戶端發送一個請求開始計時，到客戶端接收到從服務器端返回的響應結果結束計時所經歷的時間，一般情況下，響應時間是由網絡傳輸時間。服務器處理時間和瀏覽器顯示時間三部分組成。
（TTLB，即爲請求響應時間，意思是從發送一個請求開始，到客戶端收到最後一個字節的響應爲止所耗費的時間。）
吞吐量：就是吞吐量/傳輸時間，用來指單位時間內網絡上傳輸的數據量，也可以指單位時間內處理的客戶端請求數量。
TPS：每秒鐘系統能夠處理的交易或事務的數量。
點擊率：指每秒鐘用戶向Web服務器提交的HTTP請求數。
（注意：這裏的點擊不是指用鼠標的一次單擊操作，困爲在一次單擊操作中，客戶端可能向服務器發出多個HTTP請求）
總體上，LR的性能測試的工作流程大概如下：
1、創建腳本(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;
}
在我們錄製了腳本後，可以完善腳本呢？
1、 錄製完腳本後，第一件事情就是回放腳本，如果沒有報錯，可以在腳本中插入事務，也可以在錄製的時候插入事務，建議採用在腳本的錄製過程中插入事務的方法，這樣就不至於遺漏程序中應插入事務的操作了。
2、 插入集合點，需要明確的是，需要在併發哪個業務任務操作前插入集合點，如：在一個登錄操作或者查詢操作插入，輸入集合點的名字要顧名思義。（注意：集合點只能在Action中插入，不能在vuser_init 或 vuser_end中插入）
3、 插入註釋，“Insert——Comment”。
4、 插入LR API常用函數。
如： web_custom_request();
Web_image();
Web_link();
5、 腳本參數化，必須選定參數化的格式類型，如是日期型、還是導入數據庫參數化。
參數化設置如下操作：
- 用參數替換腳本中的常量；
- 爲參數設置屬性和數據源；
需要注意事項： 在參數化的過程中，只有函數中的參數能被參數化，而且也不是所有的函數中的參數都能參數化，如Lrd_stmt只能參數化mpcText；參數化只可以用於一個函數中的參量，但不能用參數表示非函數參數的字符串，關聯函數是不能參數化的。
6、 腳本關聯(手動關聯)，操作步驟如下：
- 使用相同的業務流程與數據，錄製兩份腳本；
- 使用WinDiff工具協助找出需要關聯的數據；
- 使用web_reg_save_param函數手動建立關聯；
- 將腳本中有用到關聯的數據，以參數取代；
在這裏必須說明：在Recording Log（單協議）或是 Generation Log（多重協議）中找到不能確定是否需要關聯的數據時，這時要確認數據是否爲從服務器端傳送過來的。首先可以檢查數據的標頭，從標頭的Receiving response可以知道數據是否是從服務器端傳送到客戶端的。假如此數據第一次出現是在Sending request中，則表示此數據是由客戶端產生，不需要做關聯，但是有可能需要做Parameterized（參數化）。
2、創建場景（Controller）
在創建場景的設置中，就需要對用戶的需求來設置場景了，可以按方案計劃實施（Schedule by Scenario），也可以案組計劃實施(Schedule by Group)，然後打開“Scenario Start”設置方案開始策略。
配置方案：在配置方案時，需要對運行時環境的設置“Tools——Options”
方案模式的選擇有兩種情況：一種是百分比方案模式，一種是面向目標的方案模式。如果用戶需求比較明確，可以選擇面向目標的方案模式，設置期望值。
注意：在設置方案計劃中，持續時間設置將覆蓋Vuser迭代設置。這意味着，如果將持續時間設置爲5分鐘，那麼Vuser將繼續在5分鐘時間內運行儘可能多的迭代，即使運行時設置僅指定一次迭代。
3、結果分析(Analysis)
當場景運行結束後，可以通過Analysis採集到數據信息（主要是圖表），我們可以根據以一幾種方式分析這些數據：
1、 查看Vuser Log文件，這些文件包括了場景運行過程中每個用戶的跟蹤數據，Vuser Log 文件一般放在腳本目錄中；
2、 在控制檯中輸出窗口查看場景的執行過程信息；
3、 使用Aanalysis模塊分析執行結果圖表；
4、 使用直接生成的圖表查看原始數據——Graph Data 或者 Raw Data ；
5、 讓LR自動生成HTML或Word格式的測試報告，通過報告進行分析。
在這裏說下，Analysis摘要報告包含一個事務百分比列，默認爲90%的事務響應時間（90%是一個統計響應時間的參數，表明該事務所有的運行次數中，90%的次數落在這個響應時間內），此數值如沒有特殊要求不用改動。
二、提高篇
設置關聯：在腳本中設置手動關聯一向是個難題，有些關聯的地方是有多處，前面的關聯如果沒有執行通過，執行將停止驗證腳本的正確性，後面需要做關聯的部分無法被掃描出來。
在關聯中，如何打印出參數值？
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的客戶端中配置服務名，步驟如下圖：
1、啓動“Net Configuration Assistant”界面，選擇：
2、下一步，選擇“添加”
3、下一步，填寫數據庫名：
4、下一步，選擇協議：
6、 下一步，填寫機器的IP：
7、 最後一步進行配置測試：
若測試配置連接未成功，則需要 ”更改口令”，因爲默認值爲系統管理員的用戶名和口令（都是“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/
三、實戰篇
1、 如何分析性能需求指標呢？
1）、併發用戶指標：併發用戶數>=？？
2）、系統響應時間指標：頁面響應時間<=？？
3）、系統穩定性指標：系統有效工作時間要求>=？？%
Web服務持續穩定工作時間>=？？天或（小時）
4）、系統吞吐量指標：吞吐量？？如：完成業務情況（數據庫容量）>=？？萬筆交易數
5）、業務處理能力性能指標：每筆業務的響應時間<=？？
登錄要求響應時間<=？？
業務處理能力（即每秒請求數）>=？？
TPS（每秒交易數）>=？？
6）、風險需求：容災需求中的性能指標，如當併發用戶數達到多少、每天完成最大的交易數等等時系統會崩潰的情況。
2、 估算過程參考的行業標準？
1）、併發強度指標：使用80/20法則確定，即併發用戶峯值數按日高峯訪問量的80%計算，併發用戶最小值按照日均訪問量的20%計算。
2）、日高峯業務處理能力：使用80/20法則推算，即假設80%的工作在20%的工作時間內完成。在工作時間內，80%的業務是在整個工作日的20%時間內完成，此時的業務量按照每天可能發生的最大交易量乘以80%來計算，工作時間按照正常時間8小時的20來進行計算。
3）、高峯日的業務處理能力：使用80/20法則推算，即假設每年80%的業務集中在20%的時間內完成。
4）、容災處理能力：業務處理總量/2
LR注意事項：
- 測試服務器在承受壓力時，要儘量避免網絡造成的瓶頸問題，即服務器端和客戶端一定要同一個局域網內，否則網絡因素可能會成爲性能測試的瓶頸；
- 性能測試腳本中要注意檢查點的設置，否則將難以發現腳本本身的錯誤；
- 需要對腳本的參數化設置和關聯設置；
- 設置在回放腳本時忽略思考時間（Think Time），在“Runtime Setting——Think Time”中設置；
- 儘量爲每一個頁面設置一個事務，否則不知道哪個頁面最慢；
- 真正運行性能測試腳本時，關閉日誌功能（在Runtime Setting設置），當我們調試腳本時，可以打開日誌功能；
- 性能測試前的數據準備很重要，設計併發用戶數量應由少到多，逐漸遞增（20—30—50—100）；
- 在性能測試時，每個用戶登錄的用戶名和密碼儘量不要相同（用參數化設置）；
- 通常情況下，可以將登錄錄製到Vuser_init部分中，將客戶端活動錄製到Actions部分中，將退出貨註銷過程錄製到Vuser_end部分中；
- 在使用腳本時，可以參考LR API函數；