【正文】 可能會引起各種各樣的問題。 判斷應用程序是否存在處理器瓶頸的方法：如果Processor Queue Length 顯示的隊列長度保持不變（=2）個并且處理器的利用率%Processor Time 超過90%，那么很有可能存在處如果發(fā)現(xiàn)Processor Queue Length 顯示的隊列長度超過2，而處理器的利用率卻一直很如果系統(tǒng)由于應用程序代碼效率低下或者系統(tǒng)結構設計有缺陷而導致大量的上下文切換（Context Switches/sec 顯示的上下文切換次數(shù)比較大），那么就會占用大量的系統(tǒng)資源。如果系統(tǒng)的吞吐量降低并且CPU 的使用率很高，并且此現(xiàn)象發(fā)生時切換水平在15000 以上，同時還可以比較Context Switches/sec 和%Privileged Time 來判斷上下文切換是否過量。如果后者的值超過40%，且上下文切換的速率也很高，那么應該檢查為什么會產(chǎn)生這樣高 網(wǎng)絡吞吐量以及帶寬 磁盤相關7．5，數(shù)據(jù)庫的監(jiān)視（oracle）數(shù)據(jù)庫的監(jiān)視本圖主要以oracle事例，oracle主要信息表來源oracle v$ 表對象中的sesstat和sysstat中現(xiàn)在主要對sysstat表進行說名。Measurement Description CPU used by this session 一個用戶請求從開始到結束所占用的CPU時間(10ms為單位)Bytes received via SQL*Net from client 客戶通過NET8收到的字節(jié)數(shù)Logons current 當前登錄數(shù)Opens of replaced files 因為已不在文件處理緩沖區(qū)而需要重新打開的文件數(shù)User calls Oracle分配資源以記錄相應的用戶請求數(shù)據(jù)結構當每次你登錄，或發(fā)出請求時SQL*Net roundtrips to/from client 收發(fā)的NET8消息數(shù)Bytes sent via SQL*Net to client 從前臺進程通過NET8發(fā)送到客戶的字節(jié)數(shù)Opened cursors current 當前打開的游標數(shù)DB block changes 系統(tǒng)全局區(qū)中的所有數(shù)據(jù)塊改變的次數(shù)Total file opens 數(shù)據(jù)庫實例打開并且正在處理的文件數(shù) 、Network Delay如果要監(jiān)視的兩臺計算機在同一個局域網(wǎng)絡內(nèi)，建議不要使用Network Delay Monitor。因為在同一局域網(wǎng)內(nèi)，Network Delay 會非常的小，網(wǎng)絡監(jiān)視器會有足夠的時間在每秒鐘內(nèi)發(fā)送成百上千的請求，這樣會導致源計算機（source machine）的CPU 和內(nèi)存超負荷工作。默認情況下“Enable display of network nodes by DNS names”選擇是沒有選中的，因為選中它會明顯的降低該監(jiān)視器的速度。、分析實時監(jiān)視圖表Q1 事務響應時間是否在可接受的時間內(nèi)？哪個事務用的時間最長？看Transaction Response Time 圖，可以判斷每個事務完成用的時間，從而可以判斷出那個事務用的時間最長，那些事務用的時間超出預定的可接受時間。下圖可以看出，隨著用戶數(shù)的不斷增加，login 事務的響應時間增長的最快！Q2 網(wǎng)絡帶寬是否足夠?“Throughput”圖顯示在場景運行期間的每一秒鐘，從Web Server 上接受到的數(shù)據(jù)量的值。拿這個值和網(wǎng)絡帶寬比較，可以確定目前的網(wǎng)絡帶寬是否是瓶頸。如果該圖的曲線隨著用戶數(shù)的增加，沒有隨著增加，而是呈比較平的直線，說明目前的網(wǎng)絡速度不能夠滿足目前的系統(tǒng)流量。Q3 硬件和操作系統(tǒng)能否處理高負載?“Windows Resources”圖實時地顯示了Web Server 系統(tǒng)資源的使用情況。利用該圖提供的數(shù)據(jù)，可以把瓶頸定位到特定機器的某個部件。loadrunner的analysis分析結果場景運行結束后，需要使用Analysis 組件分析結果。Analysis 組件可以在“開始程序”菜單中啟動，也可以在Controller 中啟動。由于我本人對怎樣分析結果最有效沒有進行比較多的實踐，所以這里只能按照常規(guī)的方法進行簡單介紹。注意：這里介紹的分析方法只適用于Web 測試第一步，看“Transaction Performance Summary”圖，確認那個事務的響應時間比較大，超出了我們的標準?？聪聢D，login 事務的平均響應時間最長然后我們再看“Average Transaction Response Time”，觀察login 在整個場景運行中每一秒的情況。從圖中可以看出，login 事務的響應時間并不是一直都比較高，只是隨著用戶數(shù)的增加，響應時間才明顯增加的。為了定位問題，明白為什么login 事務的響應時間比較長，現(xiàn)在我們要分解login 事務，分析該頁面上每一個元素的性能。在上圖中，選擇要分解的事務曲線，然后點鼠標右鍵，選擇“Web Page Breakdown for login” 分解頁面通過分解頁面可以得到：比較大的響應時間到底是頁面的哪個組件引起的？問題出在服務器上還是網(wǎng)絡傳輸上。這里為了解說各個時間（比如：DNS 解析時間、連接時間、接受時間等）其他的時間還有SSL Handshaking（SSL 握手協(xié)議，用到該協(xié)議的頁面比較少）、ClientTime（請求在客戶端瀏覽器延遲的時間，可能是由于客戶端瀏覽器的think time 或者客戶端其他方面引起的延遲）、Error Time（從發(fā)送了一個HTTP 請求，到Web Server 發(fā)送回一個HTTP 錯誤信息，需要的時間）。熟悉了以上各個時間的含義后，我們開始看分解頁面的圖形。首先看“Downlaod Time Breakdown”，可以看出login 事務分解的各個組件的大小，以及各個組件的下載時間。從下圖可以看出，login 頁面有5 個組件組成， 下載用的時間最長，并且?guī)缀跛械臅r間都用在了First Buffer 上，并不是很大。上圖提供的組件大小的信息比較簡單，更詳細的信息參考“Download Component SizeGraph”。利用該圖可以看出該頁面各種組件的大小所占的比例關系。同樣，要看各個組件下載時間的更詳細的信息，可以參考“Page Component Breakdown”。利用該圖可以看出該頁面各種組件下載時間的比例關系。然后再選擇“Download Time BreakDown（Over Time）”，從中可以看出在場景運行中的每一秒鐘，組件用在傳輸?shù)母鞑糠值臅r間。要看到具體的值，可以參考Page Download TimeBreakdown（Over Time）為了確認問題緣由到底是服務器還是網(wǎng)絡，選擇“Time to First Buffer Breakdown”，可以看出Server 時間比network 時間要高的多，從而確定問題是服務器引起的。然后我們就可以參考Web Server 的相關圖表，來確定問題是由服務器的哪個部分引起。遵從這樣的步驟，可以一步步的接近問題源；如果問題由網(wǎng)絡引起，可以參考NetWork 相關的圖表，確定什么樣的網(wǎng)絡問題是性能的瓶頸。同時可以參考“Time To First Buffer BreakDown(Over Time)” 的問題網(wǎng)站的性能問題可能是由多種因素引起的，其中大約有一半的性能問題最終歸結到WebServer、Web 應用程序和數(shù)據(jù)庫服務器上。采用編程語言（ASP、JSP、 等）的網(wǎng)站非常依賴于數(shù)據(jù)庫操作，這些都可能是引起性能問題的因素。最常見的數(shù)據(jù)庫問題是效率比較低的索引設計，數(shù)據(jù)碎片太多，過時的統(tǒng)計表以及不完善的應用程序設計。在20%的壓力測試中，發(fā)現(xiàn)Web Server 和Web 應用程序是性能的瓶頸。這些瓶頸主要是由于服務器配置不當和資源不足。比如，編程比較差的代碼以及形成的DLL 能夠使用所有的計算機處理器資源，導致了CPU 的瓶頸。同樣，對內(nèi)存的操作不當和管理不善也很容易造成內(nèi)存的瓶頸，所以我們建議在排除其他可能的因素外，首先檢查CPU 和物理內(nèi)存 比較每次運行的結果一般情況下，我們進行性能測試的步驟是這樣：1 首先進行一次性能測試，記錄下結果，然后分析結果，提出改進的建議2 開發(fā)人員根據(jù)建議對代碼或者服務器的配置進行修改3 測試人員在相同的條件下進行第二輪測試4 測試人員對兩輪測試結果比較，確定開發(fā)人員修改的結果是否有效那么在Analysis 中怎樣進行對兩輪結果進行比較呢？可以采用菜單操作：然后出現(xiàn)對話框，需要選擇需要比較的結果文件(lrr),選擇多個 對圖表進行組合合并Analysis 默認的圖表都是以時間作為橫坐標，然而在分析結果的過程中，我們可能需要以“運行的用戶數(shù)”作為橫坐標，來比較結果。假如我們要畫出Windows Resources ——VUsers 的圖表，可以這樣操作。首先打開Windows Resources 圖表，然后在圖表上點鼠標右鍵，選擇Merge Graphs選擇第一項“Overlay”，出現(xiàn)以下的圖表，這樣是把兩個圖表進行了合并，兩條曲線的縱軸我們應該這樣，打開Running VUsers 圖表，在圖表上執(zhí)行前面提到的操作，不過選擇第三項“Correlate”，即可，顯示圖表如下圖這樣就是以運行的用戶數(shù)為橫軸，Windows Resouces 為縱軸畫出的圖