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