LoadRunner學習筆記積累

LR 對伺服器資源的監視

LR隻能監視它支援的伺服器的資源，它支援大部分常見的伺服器。

System Resource：包括windows平台，Unix平台等

Web Server：包括Apache、IIS、Sun的iplanet等

Application server：包括Weblogic、WebSphere等

Database server：包括DB2，Oracle，Sql server，Sybase等

Java： ejb，J2ee等，需要一個ejbdetector.jar檔案

1.對Windows（Win2k server）的監視：

對windows的監視相對比較簡單，監視前首先需要用有管理者權限的帳号連接配接被監

server，例如：net use  //qa-test  /user:donny ,輸入密碼。然後就可以添加計數器，

比較常用的計數器有：

Memory：Available Mbytes  實體記憶體的可用數（機關 Mbytes）至少要有10% 的實體記憶體值

Processor：%Processor Time CPU 使用率。這是檢視處理器飽和狀況的最佳計數器。顯示所有 CPU 的線程處理時間。如果一個或多個處理器的該數值持續超過 90%，則表示此測試的負載對于目前的硬體過于沉重。為多處理器伺服器添加該計數器的 0 到 x 個執行個體。

Processor Queue Length：是指處理列隊中的線程數，小于2。處理器瓶頸會導緻該值持續大于2。

Context Switches/sec：如果切換次數到5000*CPU個數和10000*CPU個數中，說明它忙于切換線程

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

SQL Server2000：%Processor Time，CPU 使用率

General Statistics，Logins/sec，這是每秒登入到 SQL Server 的計數。

SQL Statistics： Batch Requests/sec，每秒收到的 Transact-SQL 指令批數。這一統計資訊受所有限制（如I/O、使用者數、高速緩存大小、請求每秒收到的 Transact-SQL 指令批數。這一統計資訊受所有限制（如I/O、使用者數、高速緩存大小、請求的複雜程度等）影響。

批請求數值高意味着吞吐量很好。

2.對Unix（Linux等）的監視，需要配置相應的伺服器端，可以檢視幫助檔案，這裡就隻舉

一個例子了。

1)  LoadRunner 如何監控Apache，需要修改apache的配置檔案httpd.conf.

<Location /server-status>

SetHandler server-status

Order deny,allow

Allow from all

Allow from .your-domain.com

</Location>

把這節加在httpd.conf裡面， restart apache即可。

頁面分解

如果某個transaction的時間過長，為了分析問題出在哪裡？就可以利用頁面分解了，它可

以把每個頁面分解成：

DNS解析時間：浏覽器通路一個網站的時候，一般用的是域名，需要dns伺服器把這個域名解析為IP，這個過程就是域名解析時間，如果我們在區域網路内直接使用IP通路的話，就沒有這個時間了。

Connection：解析出Web Server 的IP位址後，浏覽器請求被送到了Web Server，然後浏覽器和Web Server 之間需要建立一個初始化HTTP連接配接，伺服器端需要做2件事：一是接收請求，二是配置設定程序，建立該連接配接的過程就是connection時間。

First Buffer：建立連接配接後，從Web Server 發出第一個資料包，經過網絡傳輸到用戶端，浏覽器成功接受到第一位元組的時間就是First Buffer。這個度量時間不僅可以表示Web Server 的延遲時間，還可以表示出網絡的反應時間。

Receive：從浏覽器接收到第一個位元組起，直到成功收到最後一個位元組，下載下傳完成止，這段時間就是receive時間。

其他的時間還有SSL Handshaking（SSL 握手協定，用到該協定的頁面比較少）、

ClientTime（請求在用戶端浏覽器延遲的時間，可能是由于用戶端浏覽器的think time 或者用戶端其他方面引起的延遲）、Error Time（從發送了一個HTTP 請求，到Web Server發送回一個HTTP 錯誤資訊，需要的時間）

為了确認問題緣由到底是伺服器還是網絡，選擇“Time to First Buffer(緩沖器) Breakdown”發現network時間比Server時間要高的多，進而确定問題是network引起的。