此文主要用於LR中“運行時參數”各項說明及配置
目錄
1、瀏覽器設置
2、常規設置
一、瀏覽器設置
可以進行Run-Time Setting設置來匹配瀏覽器設置，例如：
| 瀏覽器設置 |
Run-Time Setting |
| 每次訪問此頁時檢查 |
勾選Simulate Browser Cache 勾選Check for newer versions of stored pages every visit to the page. |
| 每次開啟Internet Explorer時檢查 |
僅勾選Simulate Browser Cache |
| 自動 |
僅勾選Simulate Browser Cache |
| 不檢查 |
勾選Simulate Browser Cache 禁用Check for newer versions of stored pages every visit to the page.
|
配置各項說明：
Simulate browser cache:
配置Vuser模擬帶緩存的瀏覽器。缺省緩存是被允許的，可以通過禁止該選項來使得所有VUser模擬的瀏覽器都不帶緩存。
疑問：如訪問百度時IE緩存目錄下會緩存一個jpg文件，手動在IE上重新訪問百度，這個jpg文件項是否有變化？在LR中模擬瀏覽器設置，勾選與不勾選，訪問百度頁面，這個jpg文件信息項是否有變化。
每個緩存文件都有截止期限、上次修改時間、上次訪問時間、上次檢查時間幾項。在已有緩存文件的情況下，測試記錄如下：
a.手動頁面訪問，緩存文件的上次訪問時間、上次檢查時間兩項，時間變化，更新為手動日期；
b.LR中采取默認瀏覽器設置（上圖），vugen中執行1次腳本，查看上次訪問時間、上次檢查時間兩項時間沒有變化；
c.LR中取消瀏覽器設置（上圖中去掉全部勾選），vugen中執行1次腳本，查看上次訪問時間、上次檢查時間兩項時間沒有變化；
這說明什么？LR中無論采取何種瀏覽器模擬策略，都不會去訪問IE緩存目錄下的文件。
Cache URLs requiring content (HTML) 選項
這個選項是指Vugen僅緩存網頁的一些必要信息，這些信息可以是一些必須的驗證信息、分析數據或者關聯數據，當你勾選了這項后，這些信息自動被緩存（默認是啟用）。
提示：為了減少虛擬用戶的內存占用量，可以禁用該選項，除非它是一個明確規定的測試要求
設置瀏覽器緩存URL的上下文(比如，HTML語法，認證或校驗等)，其他的URL的上下文不會被緩存，以減少內存使用。可以通過點擊Advance來定義需要上下文的URLs。
Cache URLs Requiring Content – Advanced 選項
在高級設置里可以設置指定類型的信息存儲到cache中。注意：這里的高級設置時同時針對所有的用戶組，而不能對單獨用戶組進行設置。
修改指定類型信息步驟：
1. 勾選Specify URLs requiring content in addition to HTML page。
2. 點“+”號，添加指定類型信息，如text/plain, text/xml, image/jpeg, and image/gif。
3. 點“-”號，從緩存中去除指定類型信息。
Check for newer versions of stored pages every visit to the page 選項
指瀏覽器會將存儲在cache中的網頁信息和最新瀏覽的頁面進行比較，當你勾選此項時，vugen會增加"If-modified-since"到HTTP包頭，在場景執行過程中這個選項可以顯示最新的網頁信息，但是也增加了更多的網絡流量，通常配置這個選項是用來匹配瀏覽器設置來達到模擬瀏覽器的目的。
通過在header中添加If-Modified-Sinces屬性來設置瀏覽器檢查比當前存儲在緩存中特定URL更新的資源。缺省情況下，瀏覽器不會自動檢測更新的資源。
例：
<!--頁面每10秒自動刷新一次-->
<meta http-equiv="refresh" content="10">
用戶的待處理任務每隔10秒自動刷新獲取最新的待處理任務，此處采取緩存機制。直接訪問此頁面，通過httpwatch工具查看這個請求，因客戶端未更新則一直返回304。而未勾選此選項，LR中get此請求腳本中顯示返回的是200。如果勾選后，再次執行查看還是返回的200.？？？？
兩個疑問：兩種情況下采取的URL與html協議有何不同？腳本錄制時選取錄制header中If-Modified-Since的意義？
Download non-HTML resources 選項
指虛擬用戶在回放期間訪問網站時加載圖片的過程，這里圖片是指隨着頁面錄制的圖片和那些沒有隨頁面錄制下來的圖片。
當真實用戶訪問網頁時，需要等待圖片的加載完成。因此如果想測試整個系統的時候（用戶體驗時間），可以勾選這項（默認勾選），如果為了提高性能且不是模擬真實用戶行為的話，則不要選該項。
提示：禁用此選項后，可能會遇到圖片驗證失敗，因為在訪問網站的時候有些圖片是會發生變化的，如廣告條。
Simulate a new user each iteration 選項
這個選項是指VuGen在迭代過程（即VuGen在每個循環的init會話結束）中重置了所有的HTTP內容，也可以理解為VuGen 將各個迭代之間的所有 HTTP 上下文重置為 init 部分結束時相應的狀態。此設置允許虛擬用戶能夠更准確的模擬用戶開始進行新的會話，它刪除了所有的Cookie，關閉了所有的TCP連接（包含keep-Alive包），清除了模擬瀏覽器的緩存，重置了HTML框架，並且清除了用戶名和密碼，此選項默認是開啟狀態。這樣使得Vuse更加真實的模擬一個新user開始一個瀏覽會話。
去掉這個選項的意思是，始終使用一個tcp/ip鏈接，不斷開，也就是所說的長鏈接或持久連接。
短連接：建立連接-----發送和接收報文1-------關閉連接
長連接：建立連接-----發送和接收報文1.。。。2.。。。3-----關閉連接
cookie有會話cookie與永久cookie的區別。lr 中cookie的解釋與用法
web_add_cookie, web_remove_cookie, and web_cleanup_cookies這些用於設置永久cookie。LR使用web_add_cookie函數進行cookie模擬
Clear cache on each iteration 選項
這個選項是指在每次迭代過程中清除瀏覽器中緩存來達到模擬一個真實用戶第一次訪問網頁。若每個循環模擬一個最新訪問站點的user時，則要選中該選項。
不勾選該復選框以禁用此選項，允許虛擬用戶使用緩存來存儲用戶信息，來模擬一個已經訪問過網頁的用戶。當每一個循環模擬一個最近訪問過站點的user，瀏覽器仍為該用戶保留網頁（從前面的循環中使用緩存頁面）的情況則不要選中該選項。
類似函數web_cache_clearup() ？？？
按照示例腳本描述此函數需要加在action的末尾，而非開始，開始的話場景報錯。末尾則不報錯。
參考：
深入理解Loadrunner中的Browser Emulation
最終這些運行時策略要如何選取，需要根據實際測試項目的策略而定，並非完全一致的。
測試記錄：
腳本設置：每個腳本中所有信息都在action中，action作為一個事務，每個腳本分為登錄、操作，退出。
場景設置：場景中5支腳本，每個腳本配置20VU，迭代執行5分鍾，每個腳本計划執行次數100次。
1、運行時設置：瀏覽器上邊幾項都不勾選
測試結果：每個腳本執行20次后，所有交易腳本的action次數都為失敗。
腳本中登錄的sessionid提示獲取不到，但是腳本中的登錄判斷卻顯示可以登錄成功。---？有點疑惑
成功數 失敗數
20 80
2、運行時設置：Simulate a new user on each iteraton、Clear cache on each iteration兩項勾選
測試結果：所有腳本按計划執行。
成功數 失敗數
100 0
3、性能測試時有遇到發包機端口數不足，調整此兩項后就不報錯的情況。
運行時設置：Simulate a new user on each iteraton不勾選
狀態1：勾選，運行幾分鍾后，發包機顯示端口連接數超6W，大量報錯。
狀態2：其他不變的情況下，這項未勾選，測試運行長時間未報錯。
測試一些響應很快的頁面時simulate a new user on each iteration設置的開啟和關閉會直接導致，要么Lr所在機器的端口間歇性用盡，TPS呈波浪狀上下起伏，要么web服務器TIME_WAIT連接瞬間增大到幾千或幾萬。出現這種時，取消勾選。
關閉這個選項后，各項性能指標會高很多。
二、常規設置
常規設置中包含迭代策略、pacing設置、日志級別、思考時間、Miscellaneous幾項設置。
1、General: Miscellaneous
配置如下：
1）運行時關於錯誤的處理方式。出錯后是否繼續運行，失敗事務后是否發送錯誤日志，是否生成錯誤快照。
2）可以配置運行時按線程運行還是按進程運行。
3）定義是否將每個action作為一個事務，或定義是否將每步當做一個事務。比如，要把init、action、end定義三個事務，則選中相應選項。
其他的沒有什么，這里重點要的說的是關於線程運行還是進程運行？
1. 按線程運行VUSER,LR默認情況下，每50個用戶開啟一個進程mmdrv.exe;controller場景運行結束,進程mmdrv.exe也會相應結束;
2. 按進程運行VUSER,系統為每1個用戶開啟一個進程mmdrv.exe;controller場景運行結束,進程mmdrv.exe也會相應結束;
3. 在Runtime setting中設置為按線程運行VUSER,設置Controller中的虛擬用戶數小於等於50的話，打開windows資源管理器可以看到有一個進程mmdrv.exe; 設置Controller中的虛擬用戶數在51與100之間的話，打開windows資源管理器可以看到有兩個進程mmdrv.exe.
loadrunner controller將使用驅動程序mmdrv運行Vuser。用戶可以在controller的run-time setting中選擇Vuser的運行方式, 是多進程方式or多線程方式。
如果選擇以線程方式來運行虛擬用戶：
在場景設置時，“是單行腳本，還是多行腳本”會決定系統啟動的進程數的多少：
假設並發用戶設置為30，如果是單行30個用戶，系統只需啟動一個進程；
假設並發用戶設置為30，如果是多行，30行，每行一個用戶，系統就需要啟動30個進程；
如果選擇以進程方式來運行虛擬用戶：
那么無論腳本在場景組中怎么設置，是單行多用戶還是多行少用戶方式，系統需要啟動的進程數是一定的，就是並發用戶的總數；
進程方式和線程方式的優缺點
如果選擇按照進程方式運行， 每個用戶都將啟動一個mmdrv進程，多個mmdrv進程會占用大量內存及其他系統資源，這就限制了可以在任一負載生成器上運行的並發用戶數的數量，因為負載機的資源（內存及其他系統資源）是有限的。
如果選擇按照線程方式運行，在默認情況下，controller為每50個用戶僅啟動一個mmdrv進程，而每個用戶都按線程方式來運行，這些線程用戶將共享父進程的內存段，這就節省了大量內存空間，從而可以在一個負載生成器上運行更多的用戶。（如果選擇線程方式來運行用戶，每個進程中會多出幾個線程，例如是53個，多出來的進程可能是用於維護進程之間的運行的）
選擇線程方式雖然可以減少啟動的mmdrv進程數，減少了內存的占用，但是也容易出現一個問題，例如，同一個測試場景，用線程並發就會出現超時失敗或報 錯，而用進程並發就沒錯。為什么呢？因為線程的資源是從進程資源中分配出來的，因此同一個進程中的多個線程會有共享的內存空間，假設a線程要用資源就必須 等待b線程釋放，而b線程也在等待其他資源釋放才能繼續，這樣就會出現這個問題。
系統需要啟動的mmdrv進程數與哪些因素有關：
與在controller 的運行時設置中選擇的是進程方式or線程方式來運行虛擬用戶有關
進程方式：無論是單行or多行腳本，需要啟動的進程數就是並發用戶數；
線程方式：假設是單行腳本，每50個用戶才啟動一個進程；多行腳本，有幾行（每行<50人）就啟動幾個進程，而不是每個用戶啟動一個進程。
如果選擇了線程方式，需啟動的進程數，進一步還與腳本是單行還是多行有關
單行腳本，多用戶，假設少於50，只需啟動一個進程，100個用戶，只需啟動2個進程，依此類推；
多行腳本，即使每行一個用戶，也需要啟動一個進程，多一行就需要多啟動一個進程；不是每個用戶啟動一個進程，有幾行（每行<50人）就需要啟動幾個進程。
在啟動了IP欺騙功能后，所需啟動的進程數，還與選擇的是按進程還是按線程來分配IP地址有關
按進程分IP：每個ip（負載生成器）就需要多啟動一個進程；
按線程分IP：每個ip（負載生成器）不需要多啟動一個進程。
備注：這里的單行是指場景中只有一支腳本，多行腳本是指場景里有多支腳本。
多支腳本時，分別為每支腳本設置是按進程方式運行還是按線程方式運行。默認都是線程模式運行。
Loadrunner 關於進程和線程的設置
虛擬用戶已線程還是進程的方式運行，對被測服務器的壓力是完全不同的，首先我們要知道在loadrunner中有3個地方涉及到虛擬用戶的運行方式，分別是：
1、在Vug->run-time settings->miscellane->multithreading中可以設置虛擬用戶是以線程還是進程的方式運行。文中所列的位置。
2、在controller中設置場景時，是以單場景模式運行還是以場景組方式運行，在這兩種不同的運行方式下，虛擬用戶的運行方式也是不同的
3、在controller中使用IP欺騙時，在專家模式（選中tools-export mode）下的tools->options->general->multiple IP address mode中也可以選擇每個IP是以線程還是進程方式運行。是不是專家模式，在options選項中的標簽數量與內容是不同的。
下面我們介紹一下這三個設置線程和進程之間的關系：
首先說一下run-time settings中的設置與controller中單場景和場景組的關系：
要記住虛擬用戶是以線程還是進程方式運行是在Vug->run-time settings中設置的；
其次在controller中如果使用單場景運行，那么該場景中無論有多少個腳本、多少個負載生成器，運行這些腳本的虛擬用戶均依照Vug->run-time settings中設置的線程還是進程方式運行；但是如果在controller中如果以場景組方式運行時，每個場景組均會作為一個進程被啟動，而每個組中的用戶又是按照Vug->run-time settings中設置的線程還是進程方式運行。
再說一下在controller中使用IP欺騙時，在專家模式下的tools->options->general->multiple IP address mode中的設置：
如果選擇的是進程方式：
1、如果這個ip是在單場景中，那么有幾個不同的ip的負載生成器就會啟動幾個進程，每個負載生成器的虛擬用戶的運行方式仍然按照Vug->run-time settings中設置的線程還是進程方式運行
2、如果是在場景組中運行，這就要看場景組是如何設置的了，有兩種情況：
a、每個場景組中添加一個虛擬ip，這時運行每個場景組時只啟動一個進程 b、每個場景組中添加多個虛擬ip，這時運行每個場景組時，每個場景組啟動一個進程，每個ip啟動一個進程，每個ip的虛擬用戶的運行方式按照Vug->run-time settings中設置的線程還是進程方式運行
如果在controller中使用IP欺騙時，在專家模式下的tools->options->general->multiple IP address mode中選擇的線程方式：
1、如果這個ip是在單場景中，那么對於不同的ip的負載生成器只會啟動一個進程，每個負載生成器的虛擬用戶的運行方式仍然按照Vug->run-time settings中設置的線程還是進程方式運行
2、如果是在場景組中運行，每個場景組啟動一個進程，所有ip已線程的方式在組進程中運行，每個ip的虛擬用戶的運行方式按照Vug->run-time settings中設置的線程還是進程方式運行
在場景中測試結果：
