【正文】 他有用的設(shè)置 Options 設(shè)置 首先使用 Export Mode（專家模式） 然后選擇上述菜單中的 Options 由于我們在 Controlller 的 RunTime Setting 中設(shè)置了以多線程方式運行，所以這里我們應(yīng)該選擇第二項，為每一個線程分配不同的IP。 分析以及監(jiān)視場景 監(jiān)視場景需要在 Run 視圖中設(shè)置 分析以及監(jiān)視場景 然后，出現(xiàn)添加計數(shù)器的對話框 分析以及監(jiān)視場景 Memory 相關(guān) 內(nèi)存是第一個監(jiān)視對象，確定系統(tǒng)瓶頸的第一個步驟就是排除內(nèi)存問題。 內(nèi)存泄漏應(yīng)該通過一個長時間的，用來研究分析當(dāng)所有內(nèi)存都耗盡時，應(yīng)用程序反應(yīng)情況的測試來檢驗。 如果系統(tǒng)的吞吐量降低并且 CPU 的使用率很高，并且此現(xiàn)象發(fā)生時切換水平在 15000 以上，那么意味著上下文切換次數(shù)過高 . 同時還可以比較 Context Switches/sec 和 %Privileged Time 來判斷上下文切換是否過量。因為在同一局域網(wǎng)內(nèi)， Network Delay 會非常的小，網(wǎng)絡(luò)監(jiān)視器會有足夠的時間在每秒鐘內(nèi)發(fā)送成百上千的請求，這樣會導(dǎo)致源計算機(jī)（ source machine）的 CPU 和內(nèi)存超負(fù)荷工作。利用該圖提供的數(shù)據(jù)，可以把瓶頸定位到特定機(jī)器的某個部件。從圖中可以看出， login 事務(wù)的響應(yīng)時間并不是一直都比較高 ,只是隨著用戶數(shù)的增加，響應(yīng)時間才明顯增加的 . 分解頁面 通過分解頁面可以得到：比較大的響應(yīng)時間到底是頁面的哪個組件引起的？問題出在服務(wù)器上還是網(wǎng)絡(luò)傳輸上。如果 DNS Server 運行情況比較好，該值會比較小。 建立連接后，從 Web Server 發(fā)出第一個數(shù)據(jù)包，經(jīng)過網(wǎng)絡(luò)傳輸?shù)娇蛻舳?，瀏覽器成功接受到第一字節(jié)的時間就是 。 分解頁面 分解頁面 分解頁面 分解頁面 分解頁面 分解頁面 分解頁面 確定 WebServer 的問題 網(wǎng)站的性能問題可能是由多種因素引起的，其中大約有一半的性能問題最終歸結(jié)到 Web Server、 Web 應(yīng)用程序和數(shù)據(jù)庫服務(wù)器上。比如，編程比較差的代碼以及形成的 DLL 能夠使用所有的計算機(jī)處理器資源，導(dǎo)致了 CPU 的瓶頸。解決方法：在安裝 LoadRunner 的第七步驟，應(yīng)該選擇第二項，如果選擇了第一項，就會有這種問題。為了確定問題出在 Controller 中的場景 ,而不是腳本的問題 ,你應(yīng)該在所有的 Load Generators 機(jī)器上使用 VuGen 運行測試腳本，確保都能夠運行正確。解決方法：要得到監(jiān)視的數(shù)據(jù)，必須要在被監(jiān)視的服務(wù)器（ Web Server）上獲得管理員權(quán)限。解決方法：可能是一些 LoadRunner 默認(rèn)的計數(shù)器在WebServer 上已經(jīng)不存在的原因，尤其是數(shù)據(jù)庫的計數(shù)器方面。當(dāng)然使用下面的控制臺命令也可以： use \\機(jī)器名 然后登陸用戶名和密碼即可。在 VuGen 中運行時使用的是完整的瀏覽器，而在 Controller 中運行時使用的只是瀏覽器的基本的部分。 在 VuGen 中運行良好的腳本，到 Controller 中運行卻出問題。 其他有用的功能 比較每次運行的結(jié)果 對圖表進(jìn)行組合合并 比較每次運行的結(jié)果 一般情況下進(jìn)行性能測試的步驟是： 首先進(jìn)行一次性能測試，記錄下結(jié)果，然后分析結(jié)果，提出改進(jìn)的建議 開發(fā)人員根據(jù)建議對代碼或者服務(wù)器的配置進(jìn)行修改 測試人員在相同的條件下進(jìn)行第二輪測試 測試人員對兩輪測試結(jié)果比較，確定開發(fā)人員修改的結(jié)果是否有效 比較每次運行的結(jié)果 對圖表進(jìn)行組合合并 Analysis 默認(rèn)的圖表都是以時間作為橫坐標(biāo)，然而在分析結(jié)果的過程中，我們可能需要以“運行的用戶數(shù)”作為橫坐標(biāo)，來比較結(jié)果。 最常見的數(shù)據(jù)庫問題是效率比較低的索引設(shè)計 ,數(shù)據(jù)碎片太多 ,過時的統(tǒng)計表以及不完善的應(yīng)用程序設(shè)計 . 在 20%的壓力測試中，發(fā)現(xiàn) Web Server 和 Web 應(yīng)用程序是性能的瓶頸。 從瀏覽器接受到第一個字節(jié)起，直到成功收到最后一個字節(jié)，下載完成止，這段時間就是 。這個度量時間可以簡單的判斷網(wǎng)絡(luò)情況，也可以判斷 Web Server 是否能夠響應(yīng)這個請求。解析的過程的時間就是 ?？聪聢D， login 事務(wù)的平均響應(yīng)時間最長。 分析實時監(jiān)視圖表 摘要 Transaction Response Time Throughput Windows Resources Transaction Response Time 看 Transaction Response Time 圖，可以判斷每個事務(wù)完成用的時間，從而可以判斷出那個事務(wù)用的時間最長 ,那些事務(wù)用的時間超出預(yù)定的可接受時間 . 下圖可以看出，隨著用戶數(shù)的不斷增加， login 事務(wù)的響應(yīng)時間增長的最快！ Throughput “ Throughput”圖顯示在場景運行期間的每一秒鐘 ,從 Web Server上接受到的數(shù)據(jù)量的值 .拿這個值和網(wǎng)絡(luò)帶寬比較 ,可以確定目前的網(wǎng)絡(luò)帶寬是否是瓶頸 . 如果該圖的曲線隨著用戶數(shù)的增加，沒有隨著增加，而是呈比較平的直線，說明目前的網(wǎng)絡(luò)速度不能夠滿足目前的系統(tǒng)流量。 分析以及監(jiān)視場景 網(wǎng)絡(luò)吞吐量以及寬帶 分析以及監(jiān)視場景 磁盤相關(guān) 判斷磁盤瓶頸的方法是通過以下公式來計算： 每磁盤的 I/O 數(shù) = [讀次數(shù) + （ 4 * 寫次數(shù)） ] / 磁盤個數(shù) 如果計算出的每磁盤的 I/O 數(shù) 大于 磁盤的處理能力，那么磁盤存在瓶頸。 如果發(fā)現(xiàn) Processor Queue Length 顯示的隊列長度超過2，而處理器的利用率卻一直很低，那么或許更應(yīng)該去解決處理器阻塞問題，這里處理器一般不是瓶頸。 內(nèi)存問題主要檢查應(yīng)用程序是否存在內(nèi)存泄漏。 下面重點講講需要添加那些計數(shù)器，以及那些計數(shù)器代表什么意思。 然后“ OK” ，然后 IP Wizard 開始檢查該范圍內(nèi)沒有使用的 IP，并把沒有使用的 IP添加到本機(jī)的 IP 窗口中。 要使用 IP 欺騙，各個 Load Generator 機(jī)器必須使用固定的 IP，不能使用動態(tài) IP（即 DHCP）。為了更加真實的模擬實際情況， LoadRunner允許運行的虛擬用戶使用不同的 IP 訪問統(tǒng)一網(wǎng)站，這種技術(shù)稱為“ IP 欺騙”。 如果出現(xiàn)以下情況， Pages per Minute、 Hits/Transactions per Second 類型的場景會置于“ Failed” 狀態(tài)： Controller 使用了指定的最大數(shù)量的用戶，并且兩次都沒有達(dá)到目標(biāo) . 所有的用戶運行都失敗 . 沒有足夠的 Load Generators 機(jī)器 (現(xiàn)有的機(jī)器已經(jīng)超載運行的情況下 ). Controller 增加了幾批用戶后， pages per minute 或者h(yuǎn)its/transactions per second 沒有增加 . Controlller 加載第一批用戶后，定義的目標(biāo)沒有被捕捉到 . 其他有用的設(shè)置 場景類型的轉(zhuǎn)化 啟用 IP Spoofer（ IP 欺騙） Options 設(shè)置 優(yōu)化 Controller和 Load Generators計算機(jī) 其他有用的設(shè)置 場景類型的轉(zhuǎn)化 使用這個選項，可以在Percentage Mode 和Vusers Group 之間互相轉(zhuǎn)化，不過一些設(shè)置可能會丟失。 Goal— Oriented Scenario 理解各種類型 每加載一批用戶后， LoadRunner 會判斷是否達(dá)到這批用戶的目標(biāo)。 Goal— Oriented Scenario 理解各種類型 如果你定義的類型是 Pages per Minute、 Hits/Transactions per Second， Controller 首先用最小用戶數(shù)除以定義的目標(biāo)，得到一個值，然后確定每個用戶應(yīng)該達(dá)到的hits/transactions或者 pages per minute，然后 controller 開始按照以下的策略加載用戶： 如果選擇的是自動的加載虛擬用戶， LoadRunner 會首先加載 50 個用戶。如果使用了最多的虛擬用戶數(shù)，定義的目標(biāo)還沒有實現(xiàn)，那么需要增加最大用戶數(shù)，重新執(zhí)行場景。運行定義該目標(biāo)類型的場景和運行Manual 類型的場景類似。 Manual Scenario 點 按鈕，進(jìn)入 Scenario Start Time 窗口 Manual Scenario 設(shè)置集合點 如果在腳本中設(shè)置了集合點，還需要在 C