IT目錄TOC\o"1-1"\h\u2291第1章 4252261.1 430941.2 6254551.3 6155161.4 7168591.5 913437第2 1030568 10144372.1 1024682.2 1212662.3 157292.4 24171222.5 29312292.6 3016828第3 3127450 31216923.1 31280853.2 33194553.3 43308353.4 5151963.5 5214229第4 536635 53154254.1 53121364.2 69258334.3 9332564 9422685.1 9419175.2VisualVM 9423655.3Nmon 107229785.4 11215063JMeter 113255666.1JMeter 113305656.2搭建JMeter 113303776.3開發JMeter 117231116.4使用JMeter 12077726.5 1373008第7 13917243 139223117.1 139322797.2 139275817.3 13979657.4 141258517.5 143134607.6 14524221第8 14724759 147147728.1 147125598.2 14790838.3 150257128.4 151132688.5 15215890第9 15426762 154138819.1 154112189.2 15474949.3 154183359.4 156113059.5 162298889.6 16755149.7 17227631 17313219.8 181205239.9 182100501 183176892 183245613 186228514 188232815 189274956 18977317 189110678 189第1作。典型的術語主要有并發用戶、并發用戶數量、請求響應時間、事務響應時間、吞吐量、吞吐率、TPS可多算，不可少算”。例如，OA系統統計并發用戶數量的經驗公式為：使用系統的用戶數量×(5%～10%)。對于經驗公式，沒有必要拘泥于計明：如果一個系統期望用戶1000個，則在100個以內并發條件下測試系統的響應時間和TPS是否滿足性能需求即可。端接收到從服務器端返的響應結果為止計時結束。在某些工具中，請求響應時間通常會被稱為TTLB，即TimetoLastByte，意思是從發起一個請求開始，到客戶端收到最后一個字節的響應所耗費的時間。請求響應時間的單位一般為“秒(s)”或者“毫秒(ms)”。請求響應時間的分解如圖1-1所示。圖1-1Web吞吐率(Throughput)：衡量網絡傳輸性能的重要指標。通常情況下，吞吐率可以用“字節數/秒”“請求數/秒”或者“頁面數/秒”來衡量，在LoadRunner中則用每秒傳輸的字節數來衡量。TPS(TransactionPerSecond)：點擊率(HitPerSecond)：HTTPWeb應用特有的一個指標。Web應用是“請求—響應”模需要注意的是，這里的點擊不是指鼠標的一次“單擊”操作，因為在一次“單擊”操作中，客戶端可能向服務器發出多個HTTP資源利用率主要針對Web對于這些概念，最好的方式仍然是歸本質，不以這些互相存在關聯關系的名詞來劃分測試種類正常壓力下用戶點擊率為“1000次/秒”，運行點擊率為“2000運行CPU或內存利用率在90%2.2舉個例子：如果距離工作單位只有10——這樣純屬資源浪費。做性能測試也是這樣，只要系統在性能方面能滿足用戶的需求并留有30%～50%的擴展空間即可。一個系統預估一兩這種現象主要歸結于對系統性能需求的不了解。很多時候，尤其是用戶會提出很多不切實際的性能指標，例如，針對500個用戶使用的OA系統，可能有的業務負責人會提出要滿足100個，甚至500個用戶并發的性能目標，而實際并發數量不會高于50通來確定合理的性能需求。并定位性能問題。對于性能測試中發現的問題，通常由性能測試工程師、DBA、系統管理員、開發人員共同來解決，但是對于測試人員，了解調整的相關知識則是十分必要的。數據庫配置：數據庫配置經常會引起整個系統運行緩慢，一些諸如Oracle的大型數據庫都是需要DBACPU的使用率是否很低而I/O系統資源監控的結果是否正常：CPU的使用是否到了極限？I/O第2第2通過第1組織來進行。統一組織性能測試的巨大好處是可以按照層次由淺入深對系統進行測試，進而減少不必要的工作量，以實現節約測試成本的目的。為此，本章提出了“全面性能測試方案”。2.41000”“3獨立業務性能測試：獨立業務實際是指一些核心業務模塊對應的業務，這些模塊通常具有功能比較復雜、使用比較頻繁、屬于核心業模塊對并發用戶的響應情況。模塊主要由性能測試策略決定，讀者可以參考第2.2節“全面性能測試策略制定原則”部分。例。第2.3節會對這部分內容進行更詳細的討論。網絡性能測試：網絡性能測試主要是為了準確展示帶寬、延遲、負載和端口的變化是如何影響用戶的響應時間的。在實際的軟件項目員來完成。服務器性能測試(操作系統、應用服務器、數據庫服務器)：服務器性能測試分為初級和高級兩種形式?！俺跫壏掌餍阅軠y試”主要器由專門的DBA來進行測試和調優。本書主要討論在測試中常見的“初級服務器性能測試”，即通過工具對服務器資源進行監控的性能測試。(5)測試場景設計通用模型在第2.3IT第四部分：全面性能測試方案如何應用。本部分內容講解如何在工作中使用“全面性能測試方案”，具體在第2.52-1表2-12-1賞。因此不管用戶是否重視性能測試，甚至根本不關心，對于性能要求高的軟件產品也應按照表2-1的策略來執行性能測試。只是如果用戶表2-2案例二：一個電子政務系統的測試案例，其性能測試策略和案例一差別很大，見表2-3表2-3案例三：一個門戶系統的測試案例，見表2-4表2-420、50、100…等不同數目并發用戶的響應情況，但是測試時發現系統性能太低，支持50在第2.1節“全面性能測試方案”中，已經介紹了性能測試分為八個方面。本節將在此基礎上進一步講解“全面性能測試方案”的核心本部分的場景可以用表2-5表2-5本節的用戶并發測試融合了第2.1節中的“獨立業務性能測試”和“組合業務性能測試”兩類內容，主要是為了使性能測試按照一定邏在第2.1用戶并發性能測試分類如圖2-1下面介紹圖2-1圖2-1盡早發現性能問題，以降低修復缺陷的成本。眾所周知，缺陷越早發現，修復的成本越低，而性能問題的修復成本還要遠遠高于一般缺陷，甚至有些不可以修復的性能問題會導致整個項目工作到起點。因此，盡管性能測試成本有些高，但對于一些特殊應用領域的、性能要求較高的軟件系統，早進行“單元性能測試”仍然是十分“合算”的一件事情。從圖2-1行正確的響應。這種測試一般通過測試工具或者編程實現，例如可以通過LoadRunner控制其模擬的部分/全部用戶在同一時間點開始同一個事務(Transaction),很容易完成上面測試場景的執行。相同/不同的子功能并發?！巴耆粯拥牟l測試”和“完全一樣操作的并發測試”關注的是同一個功能的測試，而實際上，在同一個參考后面組合模塊用戶并發性能測試的場景設計。1，就實現了同2-62-69點左右可能是收發郵件的高峰，因為大量用表2-6例如下面的案例：A模塊把數據記錄傳給B模塊，B1，然后對該記錄進行但是很容易看出，在多用戶并發的情況下這種算法肯定存在問題：多個用戶并發使用B錄都不能寫入數據庫。這種問題通過組合模塊并發測試是很容易發現的(類似問題常見于對登錄用戶進行在線跟蹤的情況，大量用戶同時登錄就會生成相同的主鍵，導致部分用戶無法登錄)。從圖2-1彼此獨立的、內部具有耦合關系的核心模塊組的并發測試。這類測試比較接近用戶的使用情況，是前面具有耦合關系模塊并發測試的關的測試場景時，可以直接把前面具有耦合關系核心模塊的并發測試的一些場景組合起來，然后考慮一下用戶的實際使用場景即可?；谟脩魣鼍暗牟l測試。基于場景的組合模塊用戶并發測試的特點是選擇用戶的一些典型場景進行測試，因此測試對象既可以是核充分考慮實際場景，選擇最接近實際的場景進行設計。例如，話費管理系統可以分別選擇日常、每月20日左右收費高峰等場景。試，也關注“性能”測試，通過發現一些接口和綜合性能方面的問題，使系統更加穩定的運行。表2-7是組合模塊測試場景設計的模板，列表2-7中的數據是某電子政務系統組合模塊的一個測試場景：在早上上班后，大家常做的工作就是處理公文、閱讀公告、發送和接收郵表2-7疲勞強度測試場景的設計模板如表2-8表2-8表2-9網絡性能測試場景設計模板如表2-10表2-10圖2-2圖2-32-22-3試場景設計模型”(簡稱“五一模型”)，五一模型解決了在這類項目中如何設計測試場景的問題。在民生銀行新一代系統建設過程中，很多系統會在UAT疲勞強度與大數據量、穩定性與健壯性等測試種類?！拔逡粶y試場景設計模型”中的批處理場景對應前臺手工發起的批量作業和后臺的日間/日終批量作業，主要測試前后臺發起的批處理任務的性能。獨立場景在測試計劃中的設計規劃如表2-11表2-11圖2-4進式加壓的方式來進行的混合交易性能測試，在壓力時間內的交易數量應超過系統全天的交易數量。每個場景測試多組并發，例如并發數從1逐步增加到200。對于具體的場景，測試幾組并發依據實際情況來確定，通常會在五組左右?；旌蠄鼍霸跍y試計劃中的設計規劃如表2-12表2-12圖2-5圖2-524峰值場景在測試計劃中的設計規劃如表2-13表2-13圖2-6圖2-6最佳并發數/最佳處理能力：最佳處理能力是指在業務處理能力滿足上線需求(例如≥100筆/s)且80%最大并發數/最大處理能力：對于性能較好系統，最大并發數是指響應時間和業務吞吐量同時滿足生產需求時系統所能支持的最大并發數，最大處理能力是指系統所能達到的最大業務吞吐量(TPS)。對于性能較差系統(未完成調優、80%交易響應時間＞1s)，理能力是指業務吞吐量(TPS)達到最大值時對應的并發數以及相應的業務處理能力。系統容量上限：系統交易成功率＜99%表2-14圖2-7圖2-7疲勞場景主要用來驗證系統的穩定性與健壯性，通常會選擇常用交易，以系統生產環境的1～3好，疲勞場景可以以容量測試結果得到的最大處理能力對應的并發數來進行加壓。疲勞場景涉及的交易通常會覆蓋系統全部交易80%以上的交易量，而且往往會和批量作業同步進行測試。表2-15圖2-8圖2-8批處理場景在測試計劃中的設計規劃如表2-16表2-16圖2-9圖2-9IT系統性能測試而設計的模型，比較適合對性能要求較高的大型項目的性能測試，可以在實際IT低成本并沒有明確的衡量標準。對于一個應用系統，只要經過反復的“測試—調優—歸測試”后，系統符合性能需求并有一定的擴展策略為中心原則。本原則不但對性能測試工作有效，對其他類型的測試工作都同樣具有指導意義。測試策略不但決定了測試場景設計行一部分。性能測試策略應該貫穿整個性能測試過程。適當裁剪原則。裁剪原則主要是針對性能場景設計而言?！皽y試場景設計通用模型”和“五一測試場景設計模型”是針對電信、銀行級的應用而提出來的，包含的測試內容比較全面，而這類項目的性能測試一般周期較長、投入較大，第9章的銀行信用卡項目實際是周期為一樣做的主要目的是為了適合特定項目的實際測試需求，進而節約測試成本。裁剪的主要依據是性能測試策略。根據第2.2節的方法制訂出測試策略，然后根據策略從“五類性能測試場景”中選擇適當的類別來編完善方案原則。本模型只是作者的工作經驗總結，不同的性能測試任務都有自己的項目背景，因而需要對模型內容進行不斷地調整、案”。只有“自己的”測試方案，才是最符合自己需要的方案。第3圖3-1本階段應用了第2.2本階段仍然應用了第2.22.4節“五一測試場景設計模型”來進行。測試腳本開發2.2測試一下系統的性能“看看”。一些不懂性能測試的項目負責人經常會隨意地安排性能測試，而且一般不會給予性能測試充裕的時間客戶現場的一些驗收性能測試。這種情況多在項目團隊不重視性能測試時發生，之所以在驗收測試階段進行性能測試，是因為客戶提客戶代表：通過和客戶代表交流，可以了解一些項目背景知識，例如客戶在軟件性能方面的需求、是否關注性能測試等，這些都是制訂性能測試策略的依據。例如，在第9驗收，因此客戶對再次重新開發的系統非常關注性能，要求項目必須先通過性能測試才可以投產，因而本項目需要更加重視性能測試。(5)人力資源的考慮：毋庸置疑，測試工作最終由人來執行，因此首先要確定能否有足夠的人力資源來完成測試任務。實際上，在國內大制訂的目標應該保證有足夠的人來完成。需求的成本較高也應該進行測試，因為有義務向客戶證明和保證系統的性能。例如在第9章的銀行信用卡項目測試案例中，一些強度測試和大數據量測試盡管測試成本很高，但是對系統投產具有重大指導意義，而且客戶十分關注，所以仍然要執行。表3-1是第9表3-19.6確定系統的核心模塊。核心模塊一般很容易確定，通常業務比較復雜或者用戶使用比較頻繁的都是核心模塊。比較復雜是針對系統開塊。確定模塊件的耦合關系。確定模塊間耦合關系是為了更加清晰地了解核心模塊間的數據傳輸方式，為設計“集成性能測試”即組合模第9章的銀行信用卡的案例中，可以看到在明確模塊間耦合關系后，可以很容易發現一些算法方面的問題。場景設計的詳細方法將會在第.1網絡環境設計。網絡環境設計主要涉及對帶寬和拓撲結構進行設計，以測試不同帶寬和拓撲環境下系統的性能。通常網絡帶寬越大，的網絡測試規劃，一般在項目中很少見，不是本書重點講解的內容，讀者可以根據實際的測試需求來進行設計。2.3數據庫環境規劃。數據庫環境規劃與操作系統環境規劃類似，主要是指在產品開發中，由于目標測試系統可能在不同數據庫平臺上運的數據庫。一般測試系統重點支持的數據庫，如果時間和人力資源允許，可以考慮測試其他的數據庫。用Ghost軟件保證環境：比較常見的做法就是反復用Ghost來維護一些測試環境，例如可以用Ghost軟件復制出多個數據庫系統在同用VMWare保證環境：VMWare備份/恢復策略：備份/恢復主要針對數據庫，通過反復的備份/恢復可以重現測試中發現的性能問題，為調優提供有力的依據試工具。不過，盜版軟件終究不是“正道”，而且隨著對盜版軟件打擊力度的加強，IT行業終究會以正版軟件為主。事實上，國內很多規模LoadRunner。LoadRunner是一種預測系統行為和性能的負載測試工具，也是目前很多公司執行性能測試的首選工具。它主要通過模RationalPerformance。Rational系列產品之一，功能非常強大，在性能測試領域和LoadRunnerQALoad。CompuWare公司的產品，它足以應付大多數的性能測試任務。QALoad是企業范圍的負載測試工具，該工具支持的范圍廣，測WebLoad。專門用于Web性能測試的工具，使用比較簡單，應用也很廣泛。WebLoadWAS。全稱是MicrosoftWebApplicationStressTool，微軟提供的免費性能測試工具。通過錄制與放，可以完成對頁面響應數等基本指標的性能測試。WAS的升級版本是ACT，隨.NET一起發布，既可以對錄制的代碼進行修改，也可以自己開發代碼。此外，開源的性能測試工具也有很多，例如ApacheJMeter、OpenSTA等，這里不再一一介紹。了解測試工具特性。選擇測試工具前首先要了解備選工具的特性，包括該工具的運行平臺、工具支持的協議等。首先應該保證工具能了解工具的主要功能。了解工具特性后，接下來評估備選工具是否能完成相關的測試任務。通過向工具廠商的售前人員咨詢很容易得了解工具的價格。價格信息主要指足以完成測試任務的工具價格，包括相關License價格、培訓價格、廠商支持價格。同時還要考慮測試人員進行學習的成本，有些工具較難使用，意味著測試小組將要投入更多的間接成本。有很多軟件例如LoadRunner的License，又可以購買永久使用的License，應該根據實際需要進行選擇。表3-2表3-23-2用戶的態度影響，讀者可以參考第2.2節中的相關內容，自己對照思考一下如何根據軟件特點和用戶的態度來確定團隊角色。略的制訂方法可以參考第2.2節中的內容和第5章案例的相關部分。階段的相關軟硬件測試環境要求，例如應用服務器和數據庫服務器的軟硬件運行環境、測試工具的軟硬件運行環境、客戶端軟硬件運行環境等。在計劃中一定要明確各種資源什么時間到位，以保障測試進度的順利進行。表3-3從表3-3在測試計劃中，時間進度安排和人員的角色與職責經常編寫在一起，表3-4表3-4很多時候，編制計劃還要明確如表3-5表3-5景的方法。第2.3節“測試場景設計通用模型”中的性能測試種類是設計性能測試場景的一個框架，在實際項目中，需要對其進行適當地裁有測試場景的依據。例如在第9章的銀行信用卡項目性能測試案例中，雖然系統備份歷史數據的周期為一年，但是測試按照由淺入深的順序更的典型場景。一天內不同時間段的使用場景。在同一天內，大多數系統的使用情況都會隨著時間發生變化。例如對于新浪、網易等門戶網站，在周壓力較大的場景進行測試。系統運行不同時期的場景。系統運行不同時期的場景是大數據量性能測試場景設計的依據。隨著時間的推移，系統歷史數據將會不斷的上限是系統歷史記錄轉移前可能產生的最大數據量，模擬的時間點是系統預計轉移數據的某一時間，例如第5.3節的銀行卡系統每年轉移一次歷史數據，設計時把“一年”的數據量作為大數據量測試的最大值。圖3-2很多時候，通過和用戶溝通不能掌握其使用系統的詳細情況，尤其是諸如圖3-2在具體設計過程中，一般是兩種方法結合使用。圖3-2的網上視頻點播系統就是通過兩種方法得到的測試數據：通過和用戶進行溝通得并發用戶數量的方法(注：這里的最大并發用戶數量不是指系統支持的最大并發用戶數量，而是指系統在生存周期內可能達到的最大并發用戶數量)。在具體項目中，通常是其中的兩種或者三種方法結合起來估計系統的最大用戶數量。下面舉兩個估計最大并發用戶數量的例子。例1：某電子政務系統的使用用戶為600，預計使用周期內不會發生大的變化，通過分析日志得出系統的最大在線數目為2002：30%左右，我們根據經驗得出第二個最大并發用戶數60(200×30%=60)。例2：對于圖3-2的網上視頻點播系統，可以看出系統最大在線用戶數為1000，200%的速度遞增，則最大在線用戶數3000，電影網站的并發數量一般為在線數的50%左右，因此最大并發用戶數量為1500。完成最大并發用戶數量的評估后，接下來就可以設計每個場景要模擬的用戶數量。表3-6是第8表3-6通過表3-6可以看出并發用戶數量的設計很簡單，基本是按照最大并發用戶數量的百分比來設計，例如可以按照最大用戶的20%作為基不同時間段場景分析的數據來源主要是前面的需求分析和日志分析結果。通過圖3-2，發的。有了上面的信息，就可以設計各個時間段的組合模塊測試場景。表3-7是如圖3-2所示的網上電影點播系統在0～2點場景的一個測試場景。表3-7網上電影點播系統在0～2以圖3-2表3-8電影瀏覽模式在12～14這里需要注意雖然在圖3-2中12～14點內系統并發用戶數目最多，但是系統登錄用戶仍然取了24小時內最大值280，而不是210，理由是系統登錄用戶在10～12點內達到了高峰280然后進行調優，更能保證系統的擴展性。運行時大數量測試主要是通過模擬系統運行時可能產生的大數據量來進行測試。例如圖3-2測試場景執行時則具有不確定性，有些場景執行時間可能很長(例如疲勞強度測試)，有些場景則需要不斷地探索進行測試(例如測試系統的最大并發用戶數)，而且可能會有部分性能測試場景不能通過。因此，性能測試的實施與監控有其自己獨特的特點。????本階段性能測試范圍。用戶現場性能測試主要是為了驗收與調優，因此對于系統軟件和特殊應用系統，性能測試應該盡可能全方面覆是即將準備投產的系統，甚至是可能已經投產的系統。投產環境的硬件資源配置通常較高，因此各類性能基本都可以開展。LoadRunner圖3-3LoadRunner測試場景運行基本都是通過測試工具來實現的。下面以LoadRunner創建虛擬用戶腳本：實際就是錄制或者編寫測試腳本。LoadRunner通過VirtualUserGenerator的模擬，錄制時通常會加入Transactions與Rendezvous。Transactions一般是指最小的原子事務，是測試中要進行重點分析的用戶操作；Rendezvous即并發點或者集合點，Controller通過Rendezvous可能會加入檢查點，對一些運行狀態信息進行檢查。參數化、修改、試運行腳本：腳本錄制完成后的首要工作是參數化，LoadRunner可能對腳本進行一些其他方面的修改。當腳本編譯通過后就可以在VirtualUserGenerator里試運行，然后放到Controller里來創建場景。設計測試場景：測試場景主要在LoadRunner的Controller里來完成，LoadRunner的場景設計過程如圖3-4圖3-4LoadRunner分析與優化測試結果：LoadRunner通過Analysis常發現瓶頸問題會著手進行優化，然后歸執行場景，直到當前場景的性能達標；如果測試結果正常，則運行下一測試場景。圖3-5LoadRunnerLoadRunner等測試工具均可以收集各種性能計數器執行時的數圖3-6LoadRunner的Controller當然也會碰到測試人員不能對某些運行數據進行監控的情況，例如工具不能直接監控一些數據庫表的記錄變化信息，或者測試在夜間進行，測試人員不便全程監視運行狀態，這時候就需要自己開發一些輔助工具來采集數據。例如在第9試基本在夜間進行，不方便監控各個時段的業務處理情況，于是作者便開發了如圖3-7成下面格式的文本文件。圖3-7性能測試結果的分析方法將會在第4測試過程需要的軟硬件資源。性能測試對軟硬件環境有著明確的需求，同時數據庫、應用服務器參數配置等相關的調優在生產環境下進行意義更大，因而性能測試最好在接近生產環境下進行，所有軟硬件資源是否具備會影響到進度。例如：可能需要測試100時使用系統，而測試團隊所擁有的開發版數據庫系統最多能支持10下性能測試進度肯定會受到影響，極有可能導致部分測試場景無法執行或延期執行。新的技術。不管是測試的系統采用了新的技術，還是測試工具采用了新的技術，這些都意味著一定的風險。例如要測試的系統采用了新的協議，需要采用團隊不熟悉的協議開發腳本等，這些都會影響測試進度。按照合理的流程規劃性能測試。按照項目管理流程來執行性能測試，是應對變更的根本方法。通常從項目初期按照流程來規劃性能測1.3節的一些誤區時，則很容易使性能測試陷入混亂的局面。保證測試方案得到項目干系人的認可。項目初期就應該和項目干系人明確測試范圍、進度目標、成本預算、質量目標等，使測試方案經常召開例會處理遇到的變更。變更不應該堆積起來，大量的變更可能會對項目造成一個較大的沖擊，甚至會影響整個項目的進度。學會接受合理的變更。測試經理應該認識到很多變更是合理的，對于那些有意義的、對項目沒有過大影響的變更，應該“從容”地接9章的銀行信用卡項目案例，在用戶現場測試階段就變更了測試場景范圍，這種為了加快進度而進行的測試范圍變更，是十分合理的。很多公司建立諸如ISO9000或者CMMI體系只是為了取得資質，從而可以更好地給客戶展示實力，這實際是一個誤區。從長遠來看，一個不但是只要有著明確的目標并付諸實踐，一定會取得良好的效果。該考慮聘請專家加入團隊。例如團隊中沒有DBA，恰巧又碰到數據庫性能問題，這個時候完全可以聘請專業DBA性能測試進度控制是很復雜的一項工作，尤其當性能測試工作作為系統測試的一部分來開展，更加大了控制的難度。要想控制好性能測試，首先應該按照第3.2項目具體特點進行靈活的調整。此外，也可以總結一些性能測試本身的經驗。例如：可以分析本次性能測試中，CPU2GB512MB團隊成員是否勝任工作。每個項目都是一個考驗成員能力的機會，所以作為測試管理者應該認真總結分析團隊各個成員的工作情況。安排“高手”去執行任務；二是發現一些能力優秀的員工，可以推廣其在本次測試中積累的經驗，為建立學習型團隊打好基礎。工具提供參考。例如，有些工具不能對網站上的視頻內容進行錄制放，下次規劃類似項目時就應該考慮其他適合的工具。工具的學習成本是否很高。工具的使用難度是規劃測試工具時應該考慮的一個重要因素，因為如果不精通工具將很難完成測試任務，為下次選擇工具提供參考。試提供參考：當下次測試進度壓力較大時，可以先執行重要的場景，后執行或延期那些不容易發現性能問題的場景。在第9章的銀行信用卡項目性能案例中，開發階段執行了12個性能測試場景，之后對場景執行效果進行分析，把用戶現場測試階段的性能場景調整成5個，不但順利完成了任務，還節約了測試成本。同目標客戶同時需要進行參數配置的產品，很多時候由于配置不正確導致系統性能不高。通過對產品在以往客戶產生的性能瓶頸原因進行總結，可以為以后測試時快速解決性能問題提供參考。題快速定位。例如，Oracle100多個可以配置的參數，經常由于配置問題導致運行緩慢，通過積累解決這方面問題的經驗，測試人員完停止、結束標準。有的性能測試計劃中還會明確性能測試方案，例如第9章的銀行信用卡項目測試案例。因此性能測試計劃應該根據自己的項目需要進行編寫，不應該流于形式，避免“為了寫計劃而寫計劃”。主要是設計“不同時間段場景”“不同時期場景”“不同業務模式場景”“大數據量”等內容相關的場景，然后落實到第2.4節“五一測試第4Analysis如何分析AnalysisAnalysis第一步：在整個測試場景的執行過程中，測試環境是否正常。如果在測試過程發生過異常，這樣得出的結果往往不準確，不需要分析。例如，在測試執行過程中，測試機的CPU利用率經常達到100%的應用服務器CPU利用率過高或者內存不足等。對于這類測試結果，性能測試人員就要開始借助Analysis對其進行深入分析，以發現一些潛在的性能問題。本節先介紹性能測試分析的基礎知識，之后介紹LoadRunnerAnalysis圖4-1則如圖4-1所示，首先應該從原始測試數據中查看系統響應時間，判斷它是否滿足用戶對性能的期望。如果不滿足，則說明系統的性能出現了問題。發現系統存在問題后，接著就要判斷系統在哪個環節出現了瓶頸。如圖4-2所示，用戶從客戶端發起的請求數據包經過網絡，傳遞到應用服務器，最后到達數據庫服務器，服務器處理完畢后按原路返到數據庫服務器的響應時間。對比Tn和Ts，就很容易知道系統在哪些環節的響應時間比例較大。圖4-2圖4-3客戶請求??一個Buffer的性能問題進行正確定位。例如，服務器的內存不夠可能會引起較大的磁盤I/0，進而導致CPU利用率高居不下——而根本原因可能是程序Analysis啟動Analysis有四種方式：①在Controller啟動場景前選擇菜單的“Run＞AutoLoadAnalysis”；②在Controller工具欄中單擊第一個圖標；③在Controller工具欄中單擊第二個圖標；④從“開始”菜單依次單擊“MercuryLoadRunner＞Applications＞Analysis”。其中，前兩種方式打開Analysis后會自動分析當前場景的運行結果，后兩種方式僅僅打開Analysis結果文件來產生分析圖。在測試結束并完成測試結果數據收集后，就可以啟動Analysis打開測試結果文件，將其導入MicrosoftAccess數據庫，然后按照設置的模利用Analysis進行分析的第一步是查看分析概要報告(AnalysisSummary)，圖4-4中顯示的即為分析概要報告。分析概要展示了場景運行圖4-4Analysis圖4-5WebWeb資源圖主要有Web服務器的吞吐率圖、點擊率圖、返的HTTP狀態代碼圖、每秒HTTP響應數圖、每秒重試次數圖、重試概述圖、服務器在Contoller中啟動網頁細分功能后，才可以在Analysis中查看到網頁細分圖。啟動細分功能的具體步驟是：在Contoller菜單中選擇“Diagnostics＞Distribution”，進入如圖4-6所示的界面，按照圖4-6中所示同時選中“Enablethefollowingdiagnostics”和“WebPageDiagnostics(MaxAllowedDistribution10%)”復選框。圖4-6(6)在第4.4第一步：從分析Summary用戶是否全部運行、最大運行并發用戶數(MaximumRunningVusers)是否與場景設計的最大運行并發用戶數一致。如果沒有，則需要(5)4-7所示的就是一個性能逐步下降的服務器，需要進一步分析其性能下降的原因，例如查找是否存在內存泄露問題；圖4-8則是一個性能相對穩定的服務器，但是響應時間偏大，這時需要分析程序查看整個測試過程中的事務平均響應時間是否逐步變大，正常情況下，事務平均響應時間應該是趨近于平行X圖4-7圖4-8AnalysisAnalysis菜單“Reports＞CrystalReport”下找到。這部分內容將在第4.3節中進行講解。4-9所圖4-9第五步：查看Web我們將在第4.2節對Web本案例講解的是一個已經上線的視頻網站遇到的性能問題。該系統的設計目標是滿足每天150萬的PV(頁面瀏覽量)。在上線后，由于用戶并發量較大，CPU的利用率經常高居100%，導致Oracle致終端用戶不能正常訪問網站。顯而易見，這類問題是不能容忍的。容易想到兩個常見的原因：程序算法上的缺陷或者數據庫配置不正確。算法上的缺陷會導致CPU資源過度消耗，而配置不正確也會引起數據庫系統運行異常。下面的性能測試設計和實施將圍繞這兩個目標來進行。Insert、Update、Delete、Select表4-1注：讀者碰到類似項目時可以根據系統自身的特點來選擇并發用戶數量，這里的50Analysis4-104-10中可以看出：視頻首頁(Index頁面)不能訪問，收費圖4-1050的錯誤很容易糾正，更是常見的性能問題的原因，而分析軟件本身則是后面測試工作的主要內容。因此，在首先查看了Oracle的服務器配置后，立刻發現了一個參數配置問題：Oracle數據庫的運行模式是“專有服務器模式”！而“共享服務器模式”才是相對更適合大規模并發的在專用服務器模式下，用戶連接所需要的資源全部在PGA中分配。該內存區為指定連接私有，其他進程不能訪問。專用連接采用一對一的因此，首先把Oracle從上面的內容可以看出，SummarySummary看出系統性能非常令人不滿下面是Oracle調成了“共享服務器模式”后的測試實施過程。為了更好地對問題定位，測試只針對播放頁面來進行。圖4-11是800用戶并發、壓力持續30分鐘的測試結果“Summary”圖4-11共享模式下8001782%的通過率。82%的事務通過率標志著后續的性能測試任務十分圖4-12共享模式下9004-11過率為85%，與82%相比沒有太大變化。稍稍提高的通過率很可能是由于測試時間較長、打開的部分頁面存在于服務器緩存中造成的。這個時候，打開Oralce的管理工具，借助Oralce提供的工具進行分析。結果一下子發現了五個問題！如圖4-13圖4-13打開圖4-13中的“發現SQL語句消耗了大量數據庫時間?！辨溄舆M行查看，發現Oracle找出了三個SQL放頁面頻繁使用的語句！終于找到了程序本身的一個原因：SQL語句消耗了大量的數據庫時間，其他原因極有可能是語句不合理引起的。主要推理如下：當一些反復執行的SQL語句效率過低時，首先會造成高速緩存不夠用，隨之引起較大的I/O；而頻繁的I/O勢必會消耗大量的CPU此整個系統的瓶頸極有可能是這三個語句引起的。再借助Analysis打開圖4-14的“事務平均響應時間圖”和圖4-15圖4-14圖4-15建立??開發人員優化了SQL語句后，進行了900個用戶并發、持續1.5小時的壓力測試，測試結果如圖4-164-16圖4-16SQL由此可以得出結論：調整SQL圖4-17根據常理，本次測試用只是普通的PC服務器，900個并發用戶1秒的響應時間顯然不合理，而391①把Oracle②增大了分配給Oracle的內存：把內存調整成系統內存的55%③增大共享池(SHARED_POOL)和緩沖區高速緩存(DB_CACHE)圖4-18事務響應時間的詳細情況如表4-2表4-2CPU利用率如圖4-19圖4-19CPU其中，服務器CPU利用率(%)的詳細情況如表4-3表4-3服務器CPU每秒下載播放頁面數如圖4-20每秒下載播放頁面數的詳細情況如表4-4圖4-20表4-4Oracle服務器CPU的平均利用率為82.723%，說明數據庫系統穩定運行。Web服務器的CPU平均利用率是67.543%。如果按一天8臺服務器每天的PV均值為67.126×3600×8≈193萬，足可以支撐150萬的PV。運行的最大用戶數：1000圖4-21表4-5測試過程中CPU利用率如圖4-22圖4-22CPU其中，服務器CPU利用率(%)的詳細情況如表4-6表4-6服務器CPU測試過程中每秒下載播放頁面數如圖4-23圖4-23每秒下載播放頁面數的詳細情況如表4-7表4-7OracleCPU8.267%，這說明靜態頁面緩存技術大大節省了對數據庫的資源消耗，系統更加穩定運行。Web服務器的CPU平均利用率是67.323%。如果按一天8小時計算，一臺服務器每天的PV均值為69.043×3600×8≈199萬，足可以支撐在滿足系統性能測試目標的前提下，Oracle數據庫CPU的利用率不足10%，本節將以某銀行信用卡審批系統項目的性能測試作為背景，來詳細介紹AnalysisVuserVuserVuser虛擬用戶圖主要包含三類：正在運行的虛擬用戶圖(RunningVusers)、虛擬用戶概要圖(VuserSummary)和集合圖(Rendezvous)，下面逐正在運行的虛擬用戶圖(Running正在運行的虛擬用戶圖(RunningVusers)顯示在場景運行的整個過程內，執行虛擬用戶腳本的Vuser數量及其狀態。圖4-24為一個運行正圖4-24圖4-25擇“SetFilter/GroupBy”，進入如圖4-26所示的界面，即可以選擇相關狀態的虛擬用戶。圖4-26虛擬用戶概要圖(Vuser使用虛擬用戶概要圖(VuserSummary)可以查看各類虛擬用戶數量，為分析提供參考。圖4-27是一個典型的虛擬用戶概要圖。集合點圖(Rendezvous)VuserVuser數量，有助于理解事務的執行時間。如果將集合點圖與平均事務響應時間圖相比較，可以了解集合所產生的負載峰值對事務時間產生的影響。在集合點圖中，X示從方案開始運行以來已用的時間，Y軸表示從集合點中釋放的Vuser數。圖4-27虛擬用戶概要圖(Vuser圖4-28圖4-28集合點圖(Vuser數小于場景設置的Vuser數時，意味著部分Vuser發生了超時，應該進一步追蹤這些用戶的超時原因。Analysis務響應時間與負載圖、事務響應時間(百分比模式)圖、事務響應時間分布圖等。通過這些圖表可以很容易地分析整個測試過程的事務執行情況。事務綜述圖(TransactionVuser圖4-30會像錄制的程序一樣繼續進行提交操作(錄制的虛擬用戶腳本沒有進行判斷主要是為了提高執行效率)。此外，從圖4-30中還可以看出，1小時內通過的總業務量超過了948筆。圖4-29圖4-30事務平均響應時間圖(AverageTransactionResponse從圖4-31變化，整體性能逐步下降的趨勢。對測試過程的硬件資源進行監控后發現，Web服務器存在內存泄漏現象，是內存不足導致了系統性能逐漸下降。圖4-32從圖4-31和圖4-32圖4-31圖4-32每秒通過事務數圖(Transactionsper“每秒通過事務數(TPS)”圖顯示在場景運行的每一秒中，每個事務通過、失敗以及停止的數量，是考查系統性能的一個重要參數。通過事務數(TPS)”圖與“平均事務響應時間”圖進行對比，以分析事務數目對執行時間的影響。圖4-33每秒通過事務總數圖(TotalTransactionsper在同等壓力下，“每秒事務總數”圖應該接近一條直線，而不是逐漸傾斜。與“每秒事務數(TPS)”相比，“每秒事務總數”更關注服務器整體處理事務的情況，是一個?觀的概念。圖4-34是與圖4-31事務性能摘要圖(TransactionPerformance圖4-34圖4-35在圖4-35中右擊選擇“ShowTransactionBreakdownTree”，將顯示如圖4-36所示的“事務細分樹”，雙擊較為關注的子事務，將會顯在第4.2.4圖4-36圖4-37事務響應時間與負載分析圖(TransactionResponseTimeUnder圖4-38事務響應時間(百分比模式)(TransactionResponseTime(Percentile))分析“事務響應時間(百分比模式)”圖時應從整體出發，例如事務的最大響應時間可能會很長，但如果大多數事務(例如95%以上)都具有行對比。事務響應時間分布圖(TransactionResponse圖4-39圖4-40WebWebWeb服務器的性能進行分析。通過分析壓力下點擊率圖(HitsperWebHTTP請求數?？梢罁c擊次數來評估虛擬用戶吞吐率圖HTTP圖4-41圖4-42圖4-43每秒HTTP響應次數圖(HTTPResponsesper每秒HTTP響應次數圖顯示場景運行過程中每秒從Web服務器返的不同HTTP狀態代碼的數量，該圖按照狀態代碼分組。表4-8列出了常見的表4-8常見的HTTP可以看出，圖4-44中HTTP的代碼為200，即正常返的HTTP請求數量在不斷下降。對比圖4-42和圖4-43可以看出，點擊率圖、吞吐率圖和圖4-44每秒HTTP每秒HTTP響應數圖還能返其他各類狀態碼信息。通過分析狀態碼，可以判斷服務器在壓力下的運行情況。此外，也可以對圖中顯示的結每秒連接數圖(ConnectionsPer除了上面介紹的分析圖外，Analysis還提供了“Web服務器返的HTTP狀態代碼”“連接數”“每秒服務器重試次數”“場景運行期間服圖4-45圖4-46載期間發生問題的時間點。LoadRunnerAnalysis能夠顯示平均下載時間和動態下載時間。頁面分解總圖(WebPage圖4-47通過“下載時間細分”圖可以很容易地看出各個元素所用時間的大小及下載過程分解，為調整程序提供依據。圖4-48是與圖4-47對應的“下載時間細分”圖?？梢钥闯?，消耗時間最多的是主頁上的JSP注：JSP代碼是指網頁中的動態部分，而gif再根據訪問過程對每類進行細分，這些獨立的頁面元素均可以通過瀏覽器獨立訪問。在圖4-48中，有兩個JSP頁面，其余均為網頁上的靜態圖片。圖4-484-494-49圖4-49圖4-50“第一次緩沖時間細分(隨時間變化)”圖顯示選定網頁的第一次緩沖時間細分(隨時間變化)情況。分析“第一次緩沖時間細分(隨時間變化)”圖，首先要理解FirstBufferTime傳送到客戶端后，到瀏覽器接收到第一個緩沖所用的時間?！暗谝淮尉彌_時間細分”圖主要顯示頁面不同元素在傳輸過程中的響應時間，并用兩種顏色來區分服務器和網絡各自所用的時間。圖514-50JSP主頁面運行時間花在了服務器上，而不是網絡傳圖4-51??Analysis還有七種詳細的網頁細分圖，可以手工打開這些分析圖進行分析。頁面組件細分圖(PageComponent3)頁面組件分解(隨時間變化)圖(PageComponentBreakdown(OverTime))4-53圖4-52圖4-53圖4-54頁面下載時間細分圖(PageDownloadTime“頁面下載時間細分”圖根據DNS解析時間、連接時間、第一次緩沖時間、SSL握手時間、接收時間、FTP表4-9圖4-55圖4-56頁面下載時間細分(隨時間變化)圖(PageDownloadTimeBreakdown(Over圖4-57為“電話審核通過”事務的“頁面下載時間細分(隨時間變化)”圖，它與圖4-53的分析結果。通過對圖4-57和圖4-53的綜合分析可以看出，“電話審核通過”事務的時間主要消耗在業務處理過程，即JSP頁面建立第一次緩沖的時間上，因而可以考慮優化“電話審核通過”事務的算法。圖4-57第一次緩沖時間細分圖(TimetoFirstBuffer“第一次緩沖時間細分”圖顯示成功收到從Web服務器返的第一次緩沖之前的這一段時間內的每個網頁組件的相關服務器/網絡時間?；D4-59是一個網絡時間所占比例較大的“第一次緩沖時間細分”圖，如果想進一步提高性能，則需要優化網絡。不過從圖4-59后面的測試結果數據可以看出，網絡的平均時間為0.065秒。這個速度已經很快了，沒有必要進行優化。這也說明在測試分析過程中，不但要分析圖圖4-58??圖4-59??第一次緩沖時間細分(隨時間變化)圖(TimetoFirstBufferBreakdown(Over“第一次緩沖時間細分(隨時間變化)”圖顯示成功收到從Web服務器返的第一次緩沖之前的這段時間內，場景運行的每一秒中每個網頁已下載組件大小圖(DownloadedComponent圖4-60??圖4-61圖4-62本小節介紹了Analysis中，通常不會孤立地分析某一“網頁細分分析”圖，而是把各種“網頁細分”圖結合起來進行分析。同時還要綜合用戶事務、Web資源、數據庫以及Web服務器等測試結果，共同來查找原因。本節介紹了查看Analysis者引起性能問題的原因時，因為不會進行性能分析而不知道如何進行答。慢慢地，很多測試工程師把性能測試分析看成是最難的工作——因能測試報告，更可以深入場景的執行，以對性能問題進行深入追蹤。Analysis主要提供了三類報告，即事務活動報告、事務性能報告、HTML與Word報告。其中，事務活動報告與事務性能報告用于分析用戶及其事務執行的細節。第5Nmon、Glance現在越來越多的應用開始使用Java來開發，基于Java的軟件系統也越來越多，因此調優工作很多時候就是對JavaJavaVisualVM。如何借助這一強大的工具來對JavaVisualVMVisualVMVisualVMJavaJava應用程序運行過程中的CPU、執行內存、垃圾收、線程等方面進行監控和分析，并能生成性能分析快照。VisualVM同時是一款免費的性能分析工具，在JDK6Update7以后，VisualVM作為JDK的一部分發布；它同時支持插件擴展，具有很強的擴展能力；它能自動選擇更快、更輕量級的技術，降低監控數據采集過程對應用程序本身造成的性能影響。VisualVM是一款免費的\集成了多個JDK命令行工具的可視化工具，它能為您提供強大的分析能力，對Java應用程序做性能分析和調優。這些功能包括生成和分析海量數據、跟蹤內存泄漏、監控垃圾收器、執行內存和CPU分析，同時它還支持在MBeans上進行瀏覽和操作。本文主要介紹如何使用VisualVM進行性能分析及調優VisualVM是一款免費的\集成了多個JDK命令行工具的可視化工具，它能為您提供強大的分析能力，對Java這些功能包括生成和分析海量數據、跟蹤內存泄漏、監控垃圾收器、執行內存和CPU分析，同時它還支持在MBeans上進行瀏覽和操作。本文主要介紹如何使用VisualVM進行性能分析及調優VisualVM是一款免費的\集成了多個JDK力，對Java應用程序做性能分析和調優。這些功能包括生成和分析海量數據、跟蹤內存泄漏、監控垃圾收器、執行內存和CPU分析，同時它還支持在MBeans上進行瀏覽和操作。本文主要介紹如何使用VisualVM進行性能分析及調優VisualVMVisualVMJDKJDK，VisualVM位于JDK根目錄下的bin目錄，如圖5-1VisualVM雙擊jvisualvm.exe，即可啟動VisualVM監控平臺，如圖5-2圖5-2VisualVMVisualVM支持本地連接以及遠程JMX連接。VisualVM能自動發現本地Java進程，如果本地啟動了JMeter等Java列出來，如圖5-3所示。圖5-3添加本地Java雙擊ApacheJmeter.jar，即可進入詳細的監控界面，如圖5-4圖5-4VisualVM監控本地JavaVisualVM同時可以監控遠程Java應用程序，此時需要開啟遠程服務端的JMX端口，在Java應用程序啟動腳本MEM_ARGS可。-Dcom.sun.management.jmxremote.authenticate=false-Dcom.sun.management.jmxremote.port=7654//ViusualVM-Djava.rmi.server.hostname=8//遠程主機IP-Dcom.sun.management.jmxremote.ssl=false//不需要SSL添加上述參數，開啟JMX端口之后，即可添加遠程主機，如圖5-5圖5-5輸入主機名，如圖5-6圖5-6單擊“確定”按鈕，并添加JMX連接，如圖5-7圖5-7添加JMX輸入主機名：端口號，如圖5-8圖5-8單擊“確定”按鈕，此時遠程Java應用程序的ViusalVM監控部署完成，如圖5-9圖5-9遠程JavaVisualVM圖5-10VisualVM圖5-11在概述頁面中，可以查看JVM內存參數信息。常用的JVM-Xms3072m：-Xmx3072m：-Xmn1024m：-XX:PermSize=1024m：-XX:MaxPermSize=1024m：Xloggc:/log/gc.log：表示輸出gc-XX:+PrintGCDetails：表示每次GC-XX:+PrintGCTimeStamps：表示打印GC-XX:HeapDumpPath=/log/heapdump.hprof：表示指定堆Dump-XX:SurvivorRatio=8：表示Eden區與Survivor-XX:ParallelGCThreads=16：-XX:+HeapDumpOnOutOfMemoryError：表示出現OOM時生成堆Dump監視頁面顯示CPU、類、堆及PermGen、線程等指標的統計情況，如圖5-12圖5-12CPU：表示查看CPU使用率以及垃圾收活動所消耗的CPU資源。如果垃圾收活動過于頻繁，占用了較高的CPU資源，可能是JVM參數配類：JVM堆及PermGen：線程頁面顯示當前程序中所有線程的運行狀態，以及是否有線程阻塞或者死鎖等情況的發生，如圖5-13圖5-13抽樣器頁面可以進行CPU抽樣、內存抽樣，如圖5-14CPU抽樣完成后，單擊“快照”按鈕，即可生成快照文件，如圖5-16打開該快照文件，我們能看到調用樹、熱點、組合(調用樹與熱點的組合圖)等信息，并可以追蹤到具體代碼的耗時，如圖5-17在熱點—方法界面中，可以看出各個方法占用的CPU時間以及方法的調用次數，能夠發現那些方法耗時多，需要進行性能優化。從圖5-17中可以看出，目前最消耗CPU資源的方法為語句println。在該方法上右鍵，在彈出的快捷菜單中選擇“顯示反向跟蹤”命令，如圖5-18圖5-14圖5-15CPU圖5-16CPU圖5-17圖5-18即可獲取該方法的調用關系，如圖5-19圖5-19同樣，我們也可以進行內存采樣，如圖5-20圖5-20通過內存采樣，可以查看到堆及永久區中包含類的字節數以及實例數等，如圖5-21圖5-21線程及堆內存通過VsiualVM可以方便地獲取Java應用程序的CPU使用率、GC活動、堆和永久區內存使用情況、加載的類的數量和正在運行的線程數等信息。為了進一步進行性能分析，我們可以對線程及堆進行Dump操作，獲取更多Java運行的細節信息，如圖5-22所示。單擊線程Dump，線程Dump信息。圖5-22線程DumpNEW：RUNNABLE：BLOCKED：WAITING：TIMED_WAITING：TERMINATED：圖5-23線程Dump通過分析線程的狀態，當我們看到一個線程經常處于WAITINGBLOCKED狀態的時候，可能是該線程在等待的資源沒有得到及時釋放，同樣，我們也可以對堆進行Dump操作，如圖5-24所示，單擊“堆Dump”圖5-24堆Dump獲取的堆Dump信息，如圖5-25所示。通過分析堆程Dump圖5-25堆Dump生成的堆hprof文件可以通過MAT工具進行分析，如圖5-26圖5-26MAT對堆DumpNmonNmonNmon工具可以為AIX和LinuxCPU磁盤I/O網絡I/ONmonNmonAIXLinux圖5-27啟動NmonNmonNmonNmon析。比如：nmon-s10-c720-f-m./perf，其中，s，c，f＜hostname＞_YYYYMMDD_HHMM.nmon，m存放路徑。配合Crontab的使用，可以實現Nmon自動按照需要的采集間隔進行監控數據的采集。監控結果文件生成之后，可以通過NmonAnalyser結果分析工具來進行測試結果的分析，如圖5-28所示，單擊“Analysenmondata”按圖5-28Nmon結果文件分析完成后，將會生成詳細的性能統計圖表，如圖5-29圖5-29NmonCPU該值較高時，說明IOIdle%：CPU另外需要注意的是，監控CPU利用率時，也需要觀察多個CPU圖5-30CPU輸入命令“m”，則可以對內存利用率進行實時監控，如圖5-31圖5-31RAMTotalMB：RAMFreeMB：RAMFreePercent：SwapTotalMB:SwapFreeMB：SwapFreePercent：磁盤IO輸入命令“d”，則可以對磁盤IO進行實時監控，如圖5-32圖5-32IOBusy：Read/WriteKB：輸入命令“n”，則可以對網絡流量進行實時監控，如圖5-33圖5-33Name：Recv=KB/s：Trans=KB/s：Packin：Packout：Insize：Outsize：Peak-＞Recv：Trans：本章首先對系統性能調優技術做了介紹，同時，介紹了JavaVisualVMDump本章針對操作系統的性能監控，重點介紹Nmon第6JMeterJMeterApacheJMeter是一款非常優秀的開源測試工具，采用純Java語言開發。JMeter最初用于Web應用的功能與性能測試，后來逐步擴展到更多JMeterLoadRunnerLoadrunner11僅能支持到JDK1.6，而JMeter則可以支持到較新的JDK1.7版本；JMeterLoadrunner，但可以通過自主開發相關插件來彌補，這也恰恰體現了JMeterJMeterWeb-HTTP,HTTPSSOAP/RESTFTPDatabaseviaJDBCLDAPMessage-orientedmiddleware(MOM)viaJMSMail-SMTP(S),POP3(S)andIMAP(S)MongoDB(NoSQL)NativecommandsorshellscriptsTCP搭建JMeterJMeterJMeter的安裝非常簡單，從\h/網站下載最新版的JMeter軟件，本地解壓縮之后即可使用，如圖6-1圖6-1JMeter接下來我們需要對JMeter的環境變量進行設置，主要是設置JMETER_HOME和CLASSPATH變量，如圖6-2和圖6-3圖6-2JMETER_HOMEJMETER_HOME設置為D:\apache-jmeter-2.10圖6-3CLASSPATHCLASSPATH：%JMETER_HOME%\lib\ext\ApacheJMeter_core.jar;%JMETER_HOME%\lib\jorphan.jar;%JMETER_HOME%\lib\logkit-進入%JMETER_HOME%\bin目錄下，執行jmeter.bat文件即可啟動JMeter軟件，如圖6-4圖6-4JMeterJMeter啟動之后，工作臺界面如圖6-5圖6-5JMeter至此，JMeterANT子項目，也是純Java語言編寫的，具有跨平臺特性。ANTXMLTarget樹，就可以執行各種Task任務。ANT接下來我們需要對ANT的環境變量進行設置，主要是設置ANT_HOME變量，如圖6-7所示。圖6-6ANT圖6-7ANT_HOMEANT_HOME:D:\apache-ant-1.9.6至此，ANT軟件安裝配置完成，后續我們將通過ANT調度JMeterJMeterJMeter不會出現性能瓶頸，從而影響測試結果的有效性。JMeter比較關鍵的三個配置文件為jmeter.bat、jmeter.log和jmeter.batsetHEAP=-Xms512m-Xmx512msetNEW=-XX:NewSize=128m-setSURVIVOR=-XX:SurvivorRatio=8-XX:TargetSurvivorRatio=50%setTENURING=-XX:MaxTenuringThreshold=2setPERM=-XX:PermSize=64m-XX:MaxPermSize=128m-XX:+CMSClassUnloadingEnabledremsetDEBUG=-verbose:gcjmeter.logremote_hostsjmeter.save.saveservice.*例如：jmeter.save.saveservice.output_format配置項，可以設置輸入格式為xml或者csv；jmeter.save.saveservice.thread_counts置項，可以設置為true或者false，設置為true后會記錄當前并發線程的數量。測試執行效率越來越低，以及測試結果失真。為了解決這個問題，JMeter提供了一個分布式運行的解決方案，通過多臺壓力負載機同時執行首先，我們在一臺機器上安裝JMeter，并確定其作為主控機，其他的機器作為壓力負載機。在主控機%JMETER_HOME%\bin目錄下的pertities文件中配置壓力負載機，編輯文件中的remote_hosts=。其中的表示運行JMeterAgent的機器，這里圖6-8啟動成功后，在主控機打開JMeter工作臺，可以選取已經配置好的壓力負載機來執行測試，如圖6-9圖6-9監控JMeterJMeterJavaJavaVisualVMJVMJMeterJMeter測試平臺本身的運行效率進行性能分析，合理調整其JVM參數，只有測試平臺本身不出現性能瓶頸，才圖6-10JMeter運行時JVM如果JMeter測試腳本出現內存溢出，或JVM參數配置不合理，均可以通過分析JavaVisualVM監控結果找到問題根源。JavaVisualVM具體開發JMeter實現AbstractJavaSamplerClient對于JavaVuser類型的測試腳本，可以在Eclipse中進行測試腳本的開發，主要是實現JMeterAbstractJavaSamplerClient接口。具體步驟Eclipse，JavaJMeterjar(ApacheJMeter_core.jar、ApacheJMeter_java.jar、packagecom.perf.jmeter;importtocol.java.sampler.AbstractJavaSamplerClient;importtocol.java.sampler.JavaSamplerContext;importpublicclassJmeterSampleextendsprivateStringtimeout;privateStringusername;privateStringsetupTest類似于Loadrunner中的init/＊重寫析構函數teardownTest類似于Loadrunner中的endpublicArgumentsgetDefaultParameters(){Argumentsparams=newArguments();returnparams;LR的lr_start_transactionSampleResultsrnewSampleResult();//代碼里面通過此方法獲取參數定義，從外部獲取參數取值usernamearg0.getParameter(＂username＂);password=arg0.getParameter(＂password＂);timeout=System.out.println(＂username:＂+username+＂＂+＂password:＂java.util.Randomrandom=newjava.util.Random();intresult=random.nextInt(100);定義事務的結束，類似于LR的lr_end_transactioncatch(Exceptionreturnpublicstaticvoidmain(String[]args)throwsInterruptedException{JmeterSamplerunTestSample=newJmeterSample();Argumentsparams=newArguments();JavaSamplerContextarg0=newJavaSamplerContext(params);導入JMeterJavaVuser測試腳本在Eclipse中編譯、運行無誤之后，將整個Java項目導出為jar包，復制至%JMETER_HOME%\lib\ext目錄下，該腳本jar使用JMeter圖6-11進入測試計劃設計界面，如圖6-12圖6-12在測試計劃設計界面中可以設置線程組名稱、線程數、Ramp-UpPeriod以及注釋等。如果將Ramp-UpPeriod設置為10秒，所有線程將在秒內啟動起來，即每秒啟動1個線程。循環次數表示運行的總迭代次數，如果設置為1000次，則測試請求將執行1000次。如果需要持續不斷地運行測試計劃，需選中“永遠”復選框。如果選中了調度器，則可以配置測試計劃的啟動時間、結束時間、持續時間(秒)、啟動延時(秒)等參數，如圖6-13圖6-13下面示例中設置線程數為10個，Ramp-UpPeriod設置為1秒，循環次數1000次，如圖6-14圖6-14接下來，在線程組上右擊添加Sampler取樣器，添加java請求，如圖6-15圖6-15在下拉列表中選取寫好的測試類JmeterSample，如圖6-16圖6-16元件CSVDataSetConfig。在CSVDataSetConfig界面，可以指定參數化文件路徑、編碼、分隔符、取值方式以及設置線程共享模式，如圖6-18所示。Filename：Fileencoding：VariableNames(comma-delimited)：Delimiter(use‘\t’fortab)：Allowquoteddata：是否允許引用數據，如果設置為True，圖6-17添加配置元件CSVDataSet圖6-18配置CSVRecycleonEOF：設置為True，當讀取文件到結尾時，再循環讀取文件。設置為False，StopthreadonEOF：當RecycleonEOF為True當RecycleonEOF為False時，StopthreadonEOF設置為True：當RecycleonEOF為False時，StopthreadonEOF設置為False：在參數化文件提供的參數數量不夠的情況下，仍然會發起線程請求，請Sharingmode：-Allthreads：所有線程。參數文件供所有線程使用，類似于Loadrunner中的unique取值模式。當線程1取了第一行數據后，線程2取值-Currentthreadgroup：當前線程組，如果有多個線程組，線程組內采用unique-Currentthread：當前線程。類似于Loadrunner中的sequence配置完成CSVDataSetConfig后，即可使用該參數文件中的測試數據。在參數對應的取值列，如圖6-19${username},${password}，圖6-19另外需要注意的是，JMeter參數文件不需要列頭，第一行即為測試數據，如圖6-20圖6-20取樣器添加完成后，我們需要新增監聽器，添加聚合報告，如圖6-21圖6-21單擊configure按鈕，可以對測試結果相關字段進行自定義，選取需要保存的字段，如圖6-22圖6-22至此，一個簡單的JMeter測試計劃已經設計完成，測試計劃保存后為*.jmxUI測試計劃設計完成之后可以通過UI模式來執行測試，在JMeter工作平臺單擊“啟動”按鈕，啟動測試執行，如圖6-23圖6-23UILabel：表示請求的名稱(類似于LoadrunnerSamples：Average：Mdedian：表示中位數，即50%90%Line：表示90%Min：Max：Error%：Throughput：KB/Sec：另外，還可以通過JMeterDos窗口能實時查看運行情況，如圖6-24圖6-24JMeterprintusageinformationandprinttheversioninformationandthejmeterpropertyfiletoadditionalJMeterpropertythejmetertest(.jmx)filetothefiletologsamplesjmeterrunlogfilerunJMeterinnonguiruntheJMeterSetaproxyserverforJMetertoSetproxyserverportforJMetertoSetnonproxyhostlistSetusernameforproxyserverthatJMeteristoSetpasswordforproxyserverthatJMeteristoDefineadditionalJMeterDefineGlobalproperties(senttoservers)or-Defineadditionalsystemadditionalsystemproperty[category=]levele.g.jorphan=INFOorStartremoteservers(asdefinedinStarttheseremoteservers(overridesthejmeterhomedirectorytoExittheremoteserversatendoftest(non-命令行執行測試的命令如下：jmeter.batntJmeterSamplePerfTest.jmxR95:1099lres_JmeterSamplePerfTest.jtl-joutput.log，如圖6-25所示。圖6-25-n：表示JMeter以非GUI-t：表示測試計劃的名稱(JmeterSamplePerfTe