性能測試調研報告1概述性能測試是通過自動化的測試工具模擬多個正常、峰值以及異常負載條件來對系統的各項性能指標進行測試。負載測試和壓力測試都屬于性能測試，兩者能夠結合進行。通過負載測試，擬定在多個工作負載下系統的性能，目的是測試當負載逐步增加時，系統各項性能指標的變化狀況。壓力測試是通過擬定一種系統的瓶頸或者不能接受的性能點，來獲得系統能提供的最大服務級別的測試。性能測試在軟件的質量確保中起著重要的作用，它涉及的測試內容豐富多樣。中國軟件評測中心將性能測試概括為三個方面：應用在客戶端性能的測試、應用在網絡上性能的測試和應用在服務器端性能的測試。普通狀況下，三方面有效、合理的結合，能夠達成對系統性能全方面的分析和瓶頸的預測。1.1應用在客戶端上性能的測試應用在客戶端性能測試的目的是考察客戶端應用的性能，測試的入口是客戶端。它重要涉及并發性能測試、疲勞強度測試、大數據量測試和速度測試等，其中并發性能測試是重點。并發性能測試是重點并發性能測試的過程是一種負載測試和壓力測試的過程，即逐步增加負載，直到系統的瓶頸或者不能接受的性能點，通過綜合分析交易執行指標和資源監控指標來擬定系統并發性能的過程。負載測試（LoadTesting）是擬定在多個工作負載下系統的性能，目的是測試當負載逐步增加時，系統構成部分的對應輸出項，例如通過量、響應時間、CPU負載、內存使用等來決定系統的性能。負載測試是一種分析軟件應用程序和支撐架構、模擬真實環境的使用，從而來擬定能夠接受的性能過程。壓力測試（StressTesting）是通過擬定一種系統的瓶頸或者不能接受的性能點，來獲得系統能提供的最大服務級別的測試。并發性能測試的目的重要體現在三個方面：以真實的業務為根據，選擇有代表性的、核心的業務操作設計測試案例，以評價系統的現在性能；當擴展應用程序的功效或者新的應用程序將要被布署時，負載測試會協助擬定系統與否還能夠解決盼望的顧客負載，以預測系統的將來性能；通過模擬成百上千個顧客，重復執行和運行測試，能夠確認性能瓶頸并優化和調節應用，目的在于尋找到瓶頸問題。測試的基本方略是自動負載測試，通過在一臺或幾臺PC機上模擬成百或上千的虛擬顧客同時執行業務的情景，對應用程序進行測試，同時統計下每一事務解決的時間、中間件服務器峰值數據、數據庫狀態等。通過可重復的、真實的測試能夠徹底地度量應用的可擴展性和性能，擬定問題所在以及優化系統性能。預先懂得了系統的承受力,就為最后顧客規劃整個運行環境的配備提供了有力的根據。并發性能測試前的準備工作測試環境：配備測試環境是測試實施的一種重要階段，測試環境的適合與否會嚴重影響測試成果的真實性和對的性。測試環境涉及硬件環境和軟件環境，硬件環境指測試必需的服務器、客戶端、網絡連接設備以及打印機/掃描儀等輔助硬件設備所構成的環境；軟件環境指被測軟件運行時的操作系統、數據庫及其它應用軟件構成的環境。一種充足準備好的測試環境有三個優點：一種穩定、可重復的測試環境，能夠確保測試成果的對的；確保達成測試執行的技術需求；確保得到對的的、可重復的以及易理解的測試成果。測試工具：并發性能測試是在客戶端執行的黑盒測試，普通不采用手工方式，而是運用工具采用自動化方式進行。現在，成熟的并發性能測試工含有諸多，選擇的根據重要是測試需求和性能價格比。出名的并發性能測試工含有QALoad、LoadRunner、BenchmarkFactory和Webstress等。這些測試工具都是自動化負載測試工具，通過可重復的、真實的測試，能夠徹底地度量應用的可擴展性和性能，能夠在整個開發生命周期、跨越多個平臺、自動執行測試任務，能夠模擬成百上千的顧客并發執行核心業務而完畢對應用程序的測試。測試數據：在初始的測試環境中需要輸入某些適宜的測試數據，目的是識別數據狀態并且驗證用于測試的測試案例，在正式的測試開始以前對測試案例進行調試，將正式測試開始時的錯誤降到最低。在測試進行到核心過程環節時，非常有必要進行數據狀態的備份。制造初始數據意味著將適宜的數據存儲下來，需要的時候恢復它，初始數據提供了一種基線用來評定測試執行的成果。在測試正式執行時，還需要準備業務測試數據，例如測試并發查詢業務，那么規定對應的數據庫和表中有相稱的數據量以及數據的種類應能覆蓋全部業務。模擬真實環境測試，有些軟件，特別是面對大眾的商品化軟件，在測試時經常需要考察在真實環境中的體現。如測試殺毒軟件的掃描速度時，硬盤上布置的不同類型文獻的比例要盡量靠近真實環境，這樣測試出來的數據才有實際意義。并發性能測試的種類與指標并發性能測試的種類取決于并發性能測試工具監控的對象，以QALoad自動化負載測試工具為例。軟件針對多個測試目的提供了DB2、DCOM、ODBC、ORACLE、NETLoad、Corba、QARun、SAP、SQLServer、Sybase、Telnet、TUXEDO、UNIFACE、WinSock、WWW、JavaScript等不同的監控對象，支持Windows和UNIX測試環境。最核心的仍然是測試過程中對監控對象的靈活應用，例如現在三層構造的運行模式廣泛使用，對中間件的并發性能測試作為問題被提到議事日程上來，許多系統都采用了國產中間件，選擇JavaScript監控對象，手工編寫腳本，能夠達成測試目的。采用自動化負載測試工具執行的并發性能測試，基本遵照的測試過程有：測試需求與測試內容，測試案例制訂，測試環境準備，測試腳本錄制、編寫與調試，腳本分派、回放配備與加載方略，測試執行跟蹤，成果分析與定位問題所在，測試報告與測試評定。并發性能測試監控的對象不同，測試的重要指標也不相似，重要的測試指標涉及交易解決性能指標和UNIX資源監控。其中，交易解決性能指標涉及交易成果、每分鐘交易數、交易響應時間（Min：最小服務器響應時間；Mean：平均服務器響應時間；Max：最大服務器響應時間；StdDev：事務解決服務器響應的偏差，值越大，偏差越大；Median：中值響應時間；90％：90％事務解決的服務器響應時間）、虛擬并發顧客數。疲勞強度與大數據量測試疲勞測試是采用系統穩定運行狀況下能夠支持的最大并發顧客數，持續執行一段時間業務，通過綜合分析交易執行指標和資源監控指標來擬定系統解決最大工作量強度性能的過程。疲勞強度測試能夠采用工具自動化的方式進行測試，也能夠手工編寫程序測試，其中后者占的比例較大。普通狀況下以服務器能夠正常穩定響應請求的最大并發顧客數進行一定時間的疲勞測試，獲取交易執行指標數據和系統資源監控數據。如出現錯誤造成測試不能成功執行，則及時調節測試指標，例如減少顧客數、縮短測試周期等。尚有一種狀況的疲勞測試是對現在系統性能的評定，用系統正常業務狀況下并發顧客數為基礎，進行一定時間的疲勞測試。大數據量測試能夠分為兩種類型：針對某些系統存儲、傳輸、統計、查詢等業務進行大數據量的獨立數據量測試；與壓力性能測試、負載性能測試、疲勞性能測試相結合的綜合數據量測試方案。大數據量測試的核心是測試數據的準備，能夠依靠工具準備測試數據。速度測試現在重要是針對核心有速度規定的業務進行手工測速度，能夠在多次測試的基礎上求平均值，能夠和工具測得的響應時間等指標做對比分析。1.2應用在網絡上性能的測試應用在網絡上性能的測試重點是運用成熟先進的自動化技術進行網絡應用性能監控、網絡應用性能分析和網絡預測。網絡應用性能分析網絡應用性能分析的目的是精確展示網絡帶寬、延遲、負載和TCP端口的變化是如何影響顧客的響應時間的。運用網絡應用性能分析工具，例如ApplicationExpert，能夠發現應用的瓶頸，我們可知應用在網絡上運行時在每個階段發生的應用行為，在應用線程級分析應用的問題。能夠解決多個問題：客戶端與否對數據庫服務器運行了不必要的請求？當服務器從客戶端接受了一種查詢，應用服務器與否耗費了不可接受的時間聯系數據庫服務器？在投產前預測應用的響應時間；運用ApplicationExpert調節應用在廣域網上的性能；ApplicationExpert能夠讓你快速、容易地仿真應用性能，根據最后顧客在不同網絡配備環境下的響應時間，顧客能夠根據自己的條件決定應用投產的網絡環境。網絡應用性能監控在系統試運行之后，需要及時精確地理解網絡上正在發生什么事情；什么應用在運行，如何運行；多少PC正在訪問LAN或WAN；哪些應用程序造成系統瓶頸或資源競爭，這時網絡應用性能監控以及網絡資源管理對系統的正常穩定運行是非常核心的。運用網絡應用性能監控工具，能夠達成事半功倍的效果，在這方面我們能夠提供的工具是NetworkVantage。通俗地講，它重要用來分析核心應用程序的性能，定位問題的本源是在客戶端、服務器、應用程序還是網絡。在大多數狀況下顧客較關心的問題尚有哪些應用程序占用大量帶寬，哪些顧客產生了最大的網絡流量，這個工具同樣能滿足規定。網絡預測考慮到系統將來發展的擴展性，預測網絡流量的變化、網絡構造的變化對顧客系統的影響非常重要。根據規劃數據進行預測并及時提供網絡性能預測數據。我們運用網絡預測分析容量規劃工具PREDICTOR能夠作到：設立服務水平、完畢日網絡容量規劃、離線測試網絡、網絡失效和容量極限分析、完畢日常故障診療、預測網絡設備遷移和網絡設備升級對整個網絡的影響。從網絡管理軟件獲取網絡拓撲構造、從現有的流量監控軟件獲取流量信息（若沒有這類軟件可人工生成流量數據），這樣能夠得到現有網絡的基本構造。在基本構造的基礎上，可根據網絡構造的變化、網絡流量的變化生成報告和圖表，闡明這些變化是如何影響網絡性能的。PREDICTOR提供以下信息：根據預測的成果協助顧客及時升級網絡，避免因核心設備超出運用閥值造成系統性能下降；哪個網絡設備需要升級，這樣可減少網絡延遲、避免網絡瓶頸；根據預測的成果避免不必要的網絡升級。1.3應用在服務器上性能的測試對于應用在服務器上性能的測試，能夠采用工具監控，也能夠使用系統本身的監控命令，例如Tuxedo中能夠使用Top命令監控資源使用狀況。實施測試的目的是實現服務器設備、服務器操作系統、數據庫系統、應用在服務器上性能的全方面監控，測試原理以下。UNIX資源監控指標和描述監控指標描述平均負載系統正常狀態下，最后60秒同時進程的平均個數沖突率在以太網上監測到的每秒沖突數進程/線程交換率進程和線程之間每秒交換次數CPU運用率CPU占用率（％）磁盤交換率磁盤交換速率接受包錯誤率接受以太網數據包時每秒錯誤數包輸入率每秒輸入的以太網數據包數目中斷速率CPU每秒解決的中斷數輸出包錯誤率發送以太網數據包時每秒錯誤數包輸出率每秒輸出的以太網數據包數目讀入內存頁速率物理內存中每秒讀入內存頁的數目寫出內存頁速率每秒從物理內存中寫到頁文獻中的內存頁數目或者從物理內存中刪掉的內存頁數目內存頁交換速率每秒寫入內存頁和從物理內存中讀出頁的個數進程入交換率交換區輸入的進程數目進程出交換率交換區輸出的進程數目系統CPU運用率系統的CPU占用率（％）顧客CPU運用率顧客模式下的CPU占用率（％）磁盤阻塞磁盤每秒阻塞的字節數2為什么進行性能測試？目的是驗證軟件系統與否能夠達成顧客提出的性能指標，同時發現軟件系統中存在的性能瓶頸，優化軟件，最后起到優化系統的目的。2.1性能測試的目的（1）．評定系統的能力：測試中得到的負荷和響應時間數據能夠被用于驗證所計劃的模型的能力，并協助作出決策。（2）．識別體系中的弱點：受控的負荷能夠被增加到一種極端的水平，并突破它，從而修復體系的瓶頸或單薄的地方。（3）．系統調優：重復運行測試，驗證調節系統的活動得到了預期的成果，從而改善性能。（4）．檢測軟件中的問題：長時間的測試執行可造成程序發生由于內存泄露引發的失敗，揭示程序中的隱含的問題或沖突。（5）．驗證穩定性（resilience）可靠性（reliability）：在一種生產負荷下執行測試一定的時間是評定系統穩定性和可靠性與否滿足規定的唯一辦法。2.2性能測試的類型性能測試類型涉及負載測試，強度測試，容量測試等負載測試：Loadtesting（負載測試），通過測試系統在資源超負荷狀況下的體現，以發現設計上的錯誤或驗證系統的負載能力。在這種測試中，將使測試對象承當不同的工作量，以評測和評定測試對象在不同工作量條件下的性能行為，以及持續正常運行的能力。負載測試的目的是擬定并確保系統在超出最大預期工作量的狀況下仍能正常運行。另外，負載測試還要評定性能特性，例如，響應時間、事務解決速率和其它與時間有關的方面。強度測試：強度測試檢查程序對異常狀況的抵抗能力，是檢查系統在極限狀態下運行的時候性能下降的幅度與否在允許的范疇內。強度測試總是迫使系統在異常的資源配備下運行。例如，①當中斷的正常頻率為每秒一至兩個時，運行每秒產生十個中斷的測試用例；②定量地增加數據輸入率，檢查輸入子功效的反映能力；③運行需要最大存儲空間（或其它資源）的測試用例；④運行可能造成虛存操作系統崩潰或磁盤數據激烈抖動的測試用例，等等。容量測試：通過性能測試，如果找到了系統的極限或苛刻的環境中系統的性能體現，在一定的程度上，就完畢了負載測試和容量測試。容量還能夠看作系統性能指標中一種特定環境下的一種特定性能指標，即設定的界限或極限值。容量測試的目的是通過測試預先分析出反映軟件系統應用特性的某項指標的極限值（如最大并發顧客數、數據庫統計數等），系統在其極限狀態下沒有出現任何軟件故障或還能保持重要功效正常運行。容量測試還將擬定測試對象在給定時間內能夠持續解決的最大負載或工作量。軟件容量的測試能讓軟件開發商或顧客理解該軟件系統的承載能力或提供服務的能力，如某個電子商務網站所能承受的、同時進行交易或結算的在線顧客數。懂得了系統的實際容量，如是不能滿足設計規定，就應當謀求新的技術解決方案，以提高系統的容量。有了對軟件負載的精確預測，不僅能對軟件系統在實際使用中的性能狀況充滿信心，同時也能夠協助顧客經濟地規劃應用系統，優化系統的布署。觀察指標：性能測試重要是通過自動化的測試工具模擬多個正常、峰值以及異常負載條件來對系統的各項性能指標進行測試。負載測試和壓力測試都屬于性能測試，兩者能夠結合進行。通過負載測試，擬定在多個工作負載下系統的性能，目的是測試當負載逐步增加時，系統各項性能指標的變化狀況。壓力測試是通過擬定一種系統的瓶頸或者不能接受的性能點，來獲得系統能提供的最大服務級別的測試。在實際中作中我們經常會對兩種類型軟件進行測試：bs和cs，這兩方面的性能指標普通需要哪些內容呢？BS構造程序普通會關注的通用指標以下（簡）：Web服務器指標：*AvgRps:平均每秒鐘響應次數＝總請求時間/秒數；*Avgtimetolastbyteperterstion（mstes）:平均每秒業務角本的迭代次數,有人會把這兩者混淆；*SuccessfulRounds：成功的請求；*FailedRounds：失敗的請求；*SuccessfulHits：成功的點擊次數；*FailedHits：失敗的點擊次數；*HitsPerSecond：每秒點擊次數；*SuccessfulHitsPerSecond：每秒成功的點擊次數；*FailedHitsPerSecond：每秒失敗的點擊次數；*AttemptedConnections：嘗試鏈接數；CS構造程序，由于普通軟件后臺普通為數據庫，因此我們更重視數據庫的測試指標：*User0Connections：顧客連接數，也就是數據庫的連接數量；*Numberofdeadlocks：數據庫死鎖；*ButterCachehit：數據庫Cache的命中狀況固然，在實際中我們還會察看多顧客測試狀況下的內存，CPU，系統資源調用狀況。這些指標其實是引申出來性能測試中的一種：競爭測試。什么是競爭測試，軟件競爭使用多個資源（數據紀錄，內存等），看他與其它有關系統對資源的爭奪能力。我們懂得軟件架構在實際測試中制約著測試方略和工具的選擇。如何選擇性能測試方略是我們在實際工作中需要理解的。普通軟件能夠按照系統架構分成幾個類型：c/sclient/Server客戶端/服務器架構基于客戶端/服務器的三層架構基于客戶端/服務器的分布式架構b/s基于瀏覽器/Web服務器的三層架構基于中間件應用服務器的三層架構基于Web服務器和中間件的多層架構3性能測試的環節在每種不同的系統架構的實施中，開發人員可能選擇不同的實現方式，造成實際狀況紛繁復雜。我們不可能對每種技術都具體解說，這里只是介紹一種辦法提供應你如何選擇測試方略，從而協助分析軟件不同部分的性能指標，進而分析出整體架構的性能指標和性能瓶頸。由于工程和項目的不同，所選用的度量,評定辦法也有不同之處。但是仍然有某些通用的環節協助我們完畢一種性能測試項目。環節以下（1）．制訂目的和分析系統（2）．選擇測試度量的辦法（3）．學習的有關技術和工具（4）．制訂評定原則（5）．設計測試用例（6）．運行測試用例（7）．分析測試成果3.1制訂目的和分析系統每一種性能測試計劃中第一步都會制訂目的和分析系統構成。只有明確目的和理解系統構成才會澄清測試范疇，懂得在測試中要掌握什么樣的技術。目的：1．擬定客戶需求和盼望2．實際業務需求3．系統需求系統構成系統構成這里包含幾方面含義：系統類別，系統構成，系統功效等。理解這些內容的本質其實是協助我們明確測試的范疇，選者適宜的測試辦法來進行測試。系統類別：分清系統類別是我們掌握什么樣的技術的前提，掌握對應技術做性能測試才可能成功。例如：系統類別是bs構造,需要掌握http合同，java，html等技術。或者是cs構造，可能要理解操作系統，winsock，com等。因此甄別系統類別對于我們來說很重要。系統構成：硬件設立，操作系統設立是性能測試的制約條件，普通性能測試都是運用測試工具模仿大量的實際顧客操作，系統在超負荷情形下運作。不同的系統構成性能測試就會得到不同的成果。系統功效：系統功效指系統提供的不同子系統，辦公管理系統中的公文子系統，會議子系統等，系統功效是性能測試中要模擬的環節，理解這些是必要的。3.2選擇測試度量的辦法通過第一步，將會對系統有蘇醒的認識。接下來我們將把精力放在軟件度量上，收集系統有關的數據。度量的有關方面：*制訂規范*制訂有關流程,角色，職責*制訂改善方略*制訂成果對比原則3.3學習的有關技術和工具性能測試是通過工具，模擬大量顧客操作，對系統增加負載。因此需要掌握一定的工具知識才干進行性能測試。大家都懂得性能測試工具普通通過winsock,http等合同紀錄顧客操作。而合同選擇是基于軟件的系統架構實現（web普通選擇http合同,cs選擇winsock合同），不同的性能測試工具，腳本語言也不同，例如rationalrobot中vu腳本用類c語言實現。開展性能測試需要對多個性能測試工具進行評定，由于每一種性能測試工具都有本身的特點，只有通過工具評定，才干選擇符合現有軟件架構的性能測試工具。擬定測試工具后，需要組織測試人員進行工具的學習，培訓有關技術。3.4制訂評定原則任何測試的目的都是確保軟件符合預先規定的目的和規定。性能測試也不例外。因此必須制訂一套原則。普通性能測試有四種模型技術可用于評定：*線性投射：用大量的過去的，擴展的或者將來可能發生的數據構成散布圖，運用這個圖表不停和系統的現在狀況對比。*分析模型：用排隊論公式和算法預測響應時間，運用描述工作量的數據和系統本質關聯起來*模仿：模仿實際顧客的使用辦法測試你的系統*基準：定義測試和你最初的測試作為原則，運用它和全部后來進行的測試成果進行對比3.5設計測試用例設計測試用例是在理解軟件業務流程的基礎上。設計測試用例的原則是受最小的影響提供最多的測試信息，設計測試用例的目的是一次盡量的包含多個測試要素。這些測試用例必須是測試工具能夠實現的，不同的測試場景將測試不同的功效。由于性能測試不同于平時的測試用例，盡量把性能測試用例設計的復雜，才有可能發現軟件的性能瓶頸。3.6運行測試用例通過性能測試工具運行測試用例。同一環境下作的性能測試得到的測試成果是不精確的，因此在運行這些測試用例的時候，需要用不同的測試環境，不同的機器配備上運行。3.7分析測試成果運行測試用例后，收集有關信息，進行數據統計分析，找到性能瓶頸。通過排除誤差和其它因素，讓測試成果體現靠近真實狀況。不同的體系構造分析測試成果的辦法也不同，bs構造我們會分析網絡帶寬，流量對顧客操作響應的影響，而cs構造我們可能更關心系統整體配備會對顧客操作的影響。4性能測試辦法對于公司應用程序，有許多進行性能測試的辦法，其中某些辦法實施起來要比其它辦法困難。所要進行的性能測試的類型取決于想要達成的成果。例如，對于可再現性，基準測試是最佳的辦法。而要從現在顧客負載的角度測試系統的上限，則應當使用容量規劃測試。本文將介紹幾個設立和運行性能測試的辦法，并討論這些辦法的區別。如果不進行合理的規劃，對J2EE應用程序進行性能測試將會是一項令人望而生畏且有些混亂的任務。由于對于任何的軟件開發流程，都必須收集需求、理解業務需要，并在進行實際測試之前設計出正式的進度表。性能測試的需求由業務需要驅動，并由一組用例闡明。這些用例能夠基于歷史數據（例如，服務器一周的負載模式）或預測的近似值。搞清晰需要測試的內容之后，就需要懂得如何進行測試了。在開發階段前期，應當使用基準測試來擬定應用程序中與否出現性能倒退。基準測試能夠在一種相對短的時間內收集可重復的成果。進行基準測試的最佳辦法是，每次測試變化一種且只變化一種參數。例如，如果想懂得增加JVM內存與否會影響應用程序的性能，就逐次遞增JVM內存（例如，從1024MB增至1224MB，然后是1524MB，最后是2024MB），在每個階段收集成果和環境數據，統計信息，然后轉到下一階段。這樣在分析測試成果時就有跡可循。下一小節我將介紹什么是基準測試，以及運行基準測試的最佳參數。開發階段后期，在應用程序中的bug已經被解決，應用程序達成一種穩定狀態之后，能夠運行更為復雜的測試，擬定系統在不同的負載模式下的體現。這些測試被稱為容量規劃測試、滲入測試(soaktest)、峰谷測試(peak-resttest)，它們旨在通過測試應用程序的可靠性、強健性和可伸縮性來測試靠近于現實世界的場景。對于下面的描述應當從抽象的意義上理解，由于每個應用程序的使用模式都是不同的。例如，容量規劃測試普通都使用較緩慢的ramp-up（下文有定義），但是如果應用程序在一天之中的某個時段中有快速突發的流量，那么自然應當修改測試以反映這種狀況。但是，要記住，由于更改了測試參數（例如ramp-up周期或顧客的考慮時間(think-time)），測試的成果必定也會變化。一種不錯的辦法是，運行一系列的基準測試，確立一種已知的可控環境，然后再對變化進行比較。4.1基準測試基準測試的核心是要獲得一致的、可再現的成果。可再現的成果有兩個好處：減少重新運行測試的次數；對測試的產品和產生的數字更為確信。使用的性能測試工具可能會對測試成果產生很大影響。假定測試的兩個指標是服務器的響應時間和吞吐量，它們會受到服務器上的負載的影響。服務器上的負載受兩個因素影響：同時與服務器通信的連接（或虛擬顧客）的數目，以及每個虛擬顧客請求之間的考慮時間的長短。很明顯，與服務器通信的顧客越多，負載就越大。同樣，請求之間的考慮時間越短，負載也越大。這兩個因素的不同組合會產生不同的服務器負載等級。記住，隨著服務器上負載的增加，吞吐量會不停攀升，直到達成一種點。注意，吞吐量以穩定的速度增加，然后在某一種點上穩定下來。在某一點上，執行隊列開始增加，由于服務器上全部的線程都已投入使用，傳入的請求不再被立刻解決，而是放入隊列中，當線程空閑時再解決。注意，最初的一段時間，執行隊列的長度為零，然后就開始以穩定的速度增加。這是由于系統中的負載在穩定增加，即使最初系統有足夠的空閑線程去解決增加的負載，最后它還是不能承受，而必須將其排入隊列。當系統達成飽和點，服務器吞吐量保持穩定后，就達成了給定條件下的系統上限。但是，隨著服務器負載的繼續增加，系統的響應時間也隨之延長，即使吞吐量保持穩定。注意，在執行隊列開始增加的同時，響應時間也開始以遞增的速度增加。這是由于請求不能被及時解決。為了獲得真正可再現的成果，應當將系統置于相似的高負載下。為此，與服務器通信的虛擬顧客應當將請求之間的考慮時間設為零。這樣服務器會立刻超載，并開始構建執行隊列。如果請求（虛擬顧客）數保持一致，基準測試的成果應當會非常精確，完全能夠再現。您可能要問的一種問題是：“如何度量成果？”對于一次給定的測試，應當取響應時間和吞吐量的平均值。精確地獲得這些值的唯一辦法是一次加載全部的顧客，然后在預定的時間段內持續運行。這稱為“flat”測試。與此相對應的是“ramp-up”測試。4.2ramp-up測試ramp-up測試中的顧客是交錯上升的（每幾秒增加某些新顧客）。ramp-up測試不能產生精確和可重現的平均值，這是由于由于顧客的增加是每次一部分，系統的負載在不停地變化。因此，flat運行是獲得基準測試數據的抱負模式。這不是在貶低ramp-up測試的價值。事實上，ramp-up測試對找出后來要運行的flat測試的范疇非常有用。ramp-up測試的優點是，能夠看出隨著系統負載的變化，測量值是如何變化的。然后能夠據此選擇后來要運行的flat測試的范疇。Flat測試的問題是系統會碰到“波動”效果。注意波動的出現，吞吐量不再是平滑的。這在系統的各個方面都有所體現，涉及CPU的使用量。注意，每隔一段時間就會出現一種波形。CPU使用量不再是平滑的，而是有了像吞吐量圖那樣的尖峰。另外，執行隊列也承受著不穩定的負載，因此能夠看到，隨著系統負載的增加和減少，執行隊列也在增加和縮減。注意，每隔一段時間就會出現一種波形。執行隊列曲線與上面的CPU使用量圖非常相似。最后，系統中事務的響應時間也遵照著這個波動模式。注意，每隔一段時間就會出現一種波形。事務的響應時間也與上面的圖類似，只但是其效果隨著時間的推移逐步削弱。當測試中全部的顧客都同時執行幾乎相似的操作時，就會發生這種現象。這將會產生非常不可靠和不精確的成果，因此必須采用某些方法避免這種狀況的出現。有兩種辦法能夠從這種類型的成果中獲得精確的測量值。如果測試能夠運行相稱長的時間（有時是幾個小時，取決于顧客的操作持續的時間），最后由于隨機事件的本性使然，服務器的吞吐量會被“拉平”。或者，能夠只選用波形中兩個平息點之間的測量值。該辦法的缺點是能夠捕獲數據的時間非常短。4.3性能規劃測試對于性能規劃類型的測試來說，其目的是找出，在特定的環境下，給定應用程序的性能能夠達成何種程度。此時可重現性就不如在基準測試中那么重要了，由于測試中普通都會有隨機因子。引入隨機因子的目的是為了盡量模擬含有真實顧客負載的現實世界應用程序。普通，具體的目的是找出系統在特定的服務器響應時間下支持的現在顧客的最大數。例如，您可能想懂得：如果要以5秒或更少的響應時間支持8,000個現在顧客，需要多少個服務器？要回答這個問題，需要懂得系統的更多信息。要擬定系統的容量，需要考慮幾個因素。普通，服務器的顧客總數非常大（以十萬計），但是事實上，這個數字并不能闡明什么。真正需要懂得的是，這些顧客中有多少是并發與服務器通信的。另首先要懂得的是，每個顧客的“考慮時間”即請求間時間是多少。這非常重要，由于考慮時間越短，系統所能支持的并發顧客越少。例如，如果顧客的考慮時間是1秒，那么系統可能只能支持數百個這樣的并發顧客。但是，如果顧客的考慮時間是30秒，那么系統則可能支持數萬個這樣的并發顧客（假定硬件和應用程序都是相似的）。在現實世界中，普通難以擬定顧客確實切考慮時間。還要注意，在現實世界中，顧客不會精確地按照間隔時間發出請求。于是就引入了隨機性。如果懂得普通顧客的考慮時間是5秒，誤差為20%，那么在設計負載測試時，就要確保請求間的時間為5×（1+/-20%）秒。另外，能夠運用“調步”的理念向負載場景中引入更多的隨機性。它是這樣的：在一種虛擬顧客完畢一整套的請求后，該顧客暫停一種設定的時間段，或者一種小的隨機時間段（例如，2×（1+/-25%）秒），然后再繼續執行下一套請求。將這兩種隨機化辦法運用到測試中，能夠提供更靠近于現實世界的場景。現在該進行實際的容量規劃測試了。接下來的問題是：如何加載顧客以模擬負載狀態？最佳的辦法是模擬高峰時間顧客與服務器通信的狀況。這種顧客負載狀態是在一段時間內逐步達成的嗎？如果是，應當使用ramp-up類型的測試，每隔幾秒增加x個顧客。或者，全部顧客是在一種非常短的時間內同時與系統通信？如果是這樣，就應當使用flat類型的測試，將全部的顧客同時加載到服務器。兩種不同類型的測試會產生沒有可比性的不同測試。例如，如果進行ramp-up類型的測試，系統能夠以4秒或更短的響應時間支持5,000個顧客。而執行flat測試，您會發現，對于5,000個顧客，系統的平均響應時間要不不大于4秒。這是由于ramp-up測試固有的不精確性使其不能顯示系統能夠支持的并發顧客的精確數字。以門戶應用程序為例，隨著門戶規模的擴大和集群規模的擴大，這種不擬定性就會隨之顯現。這不是說不應當使用ramp-up測試。對于系統負載在一段比較長的時間內緩慢增加的狀況，ramp-up測試效果還是不錯的。這是由于系統能夠隨著時間不停調節。如果使用快速ramp-up測試，系統就會滯后，從而報告一種較相似顧客負載的flat測試低的響應時間。那么，什么是擬定容量的最佳辦法？結合兩種負載類型的優點，并運行一系列的測試，就會產生最佳的成果。例如，首先使用ramp-up測試擬定系統能夠支持的顧客范疇。擬定了范疇之后，以該范疇內不同的并發顧客負載進行一系列的flat測試，更精確地擬定系統的容量。4.4滲入測試滲入測試是一種比較簡樸的性能測試。滲入測試所需時間較長，它使用固定數目的并發顧客測試系統的總體強健性。這些測試將會通過內存泄漏、增加的垃圾收集(GC)或系統的其它問題，顯示因長時間運行而出現的任何性能減少。測試運行的時間越久，您對系統就越理解。運行兩次測試是一種好主意——一次使用較低的顧客負載（要在系統容量之下，方便不會出現執行隊列），一次使用較高的負載（方便出現主動的執行隊列）。測試應當運行幾天的時間，方便真正理解應用程序的長久健康狀況。要確保測試的應用程序盡量靠近現實世界的狀況，顧客場景也要逼真（虛擬顧客通過應用程序導航的方式要與現實世界一致），從而測試應用程序的全部特性。確保運行了全部必需的監控工具，方便精確地監測并跟蹤問題。4.5峰谷測試峰谷測試兼有容量規劃ramp-up類型測試和滲入測試的特性。其目的是擬定從高負載（例如系統高峰時間的負載）恢復、轉為幾乎空閑、然后再攀升到高負載、再減少的能力。實現這種測試的最佳辦法就是，進行一系列的快速ramp-up測試，繼之以一段時間的平穩狀態（取決于業務需求），然后急劇減少負載，此時能夠令系統平息一下，然后再進行快速的ramp-up；重復重復這個過程。這樣能夠擬定下列事項：第二次高峰與否重現第一次的峰值？其后的每次高峰是等于還是不不大于第一次的峰值？在測試過程中，系統與否顯示了內存或GC性能減少的有關跡象？測試運行（不停地重復“峰值/空閑”周期）的時間越長，您對系統的長久健康狀況就越理解。5慣用性能測試工具現在市場上的性能測試的工具種類諸多，能夠簡樸的劃分為下列幾個：負載壓力測試工具、資源監控工具、故障定位工具以及調優工具。5.1主流負載性能測試工具負載性能測試工具的原理普通是通過錄制、回放腳本、模擬多顧客同時訪問被測試系統，制造負載，產生并統計多個性能指標，生成分析成果，從而完畢性能測試的任務。QALoad：Compuware公司的QALoad是客戶/服務器系統、公司資源配備（ERP）和電子商務應用的自動化負載測試工具。QALoad是QACenter性能版的一部分，它通過可重復的、真實的測試能夠徹底地度量應用的可擴展性和性能。QACenter聚集完整的跨公司的自動測試產品，專為提高軟件質量而設計。QACenter能夠在整個開發生命周期、跨越多個平臺、自動執行測試任務。（無下載源）優點：輕量級性能試工具，簡樸易用。缺點：中文論壇極少，支持的插件太少。SilkPerformer：一種在工業領域最高級的公司級負載測試工具。它能夠模仿成千上萬的顧客在多合同和多計算的環境下工作。不管公司電子商務應用的規模大小及其復雜性，通過SilkPerformer，均能夠在布署前預測它的性能。可視的顧客化界面、實時的性能監控和強大的管理報告能夠協助我們快速的解決問題，例如加緊產品投入市場的時間，通過最小的測試周期確保系統的可靠性，優化性能和確保應用的可擴充性。（無下載源）LoadRunner：一種較高規模適應性的，自動負載測試工具，它能預測系統行為，優化性能。LoadRunner強調的是整個公司的系統，它通過模擬實際顧客的操作行為和實施實時性能監測，來協助您更快確實認和查找問題。另外，LoadRunner能支持最寬范的合同和技術，為您的特殊環境，量身定做地提供解決方案。LoadRunner是一種預測系統行為和性能的負載測試工具，通過模擬上千萬顧客實施并發負載及實時性能監測的方式來確認和查找問題，LoadRunner能夠對整個公司架構進行測試，LoadRunner合用于多個體系架構，能支持廣范的合同和技術（如Web、Ftp、Database等），能預測系統行為并優化系統性能。它通過模擬實際顧客的操作行為和實施實時性能監測，來協助您更快的查找和發現問題。Loadrunner是一種強大有力的壓力測試工具，它的腳本能夠錄制生成，自動關聯。測試場景面對指標，實現了多方監控。并且測試成果采用圖表顯示，能夠自由拆分組合。通過Loadrunner的測試成果圖表對比，你能夠尋找出系統瓶頸的因素，普通來說能夠按照服務器硬件、網絡、應用程序、操作系統、中間件的次序進行分析。特點：1、創立真實的負載用LoadRunner的Controller,能快速組織起多顧客的測試方案，并提供一種互動的環境，在其中既能建立持續且循環的負載，又能管理和驅動負載測試方案。同時，能夠運用日程計劃服務來定義顧客什么時候訪問系統以產生負載。這樣，就能使測試過程自動化。2、實時監測器LoadRunner內含的實時監測器，在負載測試過程的任何時候，都能夠觀察到應用系統的運行性能。這些性能檢測器實時顯示交易性能數據（如響應時間）和其它系統組件涉及ApplicationServer,WebServer，網路設備和數據庫的實時性能。3、分析成果定位問題測試完畢，LoadRunner收集匯總全部的測試數據，并提供高級的分析和報告工具，方便快速查找性能問題并追溯原由。通過分析，能很快的查找到出錯的位置和因素并做出對應的調節。4、LoadRunner能夠推動成千上萬的虛擬顧客執行不同的業務流程以模擬已布署的應用程序將面對的生產條件。能夠在推出之前發現隱藏在產品中的性能和伸縮性瓶頸，盡量減少產品停機時間和造成性能低下，并滿足服務水平和正常運行時間的需求。5、LoadRunner幾乎支持40個合同多于其它任何供應商。它涉及Web、J2EE、.NET、XML、ERP/CRM、無線、Citrix和客戶端服務器應用程序。6、LoadRunner的非侵入性的、實時的性能監控為測試中系統的全部部分提供的具體指標。這涉及Web服務器、應用程序服務器、數據庫、ERP和CRM系統、防火墻、負載平衡等。LoadRunner允許擬定可能檢測不到的硬件限制和軟件配備問題。7、LoadRunner是唯一能夠跟蹤負載中的單個應用程序組件、為其計時并排除其故障的性能測試解決方案。顧客能夠進一步發掘最后顧客的低速交易、有瓶頸的辦法或可能造成低速的SQL語句。數據細微層次確保每個負載測試為開發提供可操作的成果，從而減少優化J2EE和Siebel布署所需的時間和成本。優點：公司級工具，簡樸易用，中英文網上論壇諸多，非常符合BS/CS架構系統測試，國內使用最多的性能測試工具之一。缺點：諸多支持插件（如delphi）需要另外購置，對于復雜的性能測試規定測試員必須含有C語言開發經驗，需要適宜的培訓。價格昂貴。對于數據庫性能測試，LoadRunner很困難。WebLoad：是RadView公司推出的一種性能測試和分析工具,它讓web應用程序開發者自動執行壓力測試;webload通過模擬真實顧客的操作,生成壓力負載來測試web的性能。顧客創立的是基于javascript的測試腳本,稱為議程agenda,用它來模擬客戶的行為,通過執行該腳原來衡量web應用程序在真實環境下的性能。webload提供巡航控制器cruisecontrol的功效,運用巡航控制器,能夠預定義web應用程序應當滿足的性能指標,然后測試系統與否滿足這些需求指標;cruisecontrol能夠自動把負載加到web應用程序,并將在此負荷下能夠訪問程序的客戶數量生成報告。webload能夠在測試會話執行期間對監測的系統性能生成實時的報告,這些測試成果通過一種易讀的圖形界面顯示出來,并能夠導出到excel和其它文獻里。這兩個軟件的功效即使強大，并且能夠自動生成測試報告，但其終究是一種工具，如果你想真正的定位服務器性能的好壞和性能的瓶頸所在，需要使用工具的人對于測試軟件的方方面面都要有理解，例如軟件體系構架，網絡拓撲，服務器硬件等知識。優點：非常符合網站的性能測試。缺點：中文論壇極少。OpenSTA：開源項目，功效強大，自定義功效設立完備，但設立通過Script來完畢。必須學習Script編寫。OpenSTA是專用于B/S構造的、免費的性能測試工具。它的優點除了免費、源代碼開放的優點外，還能對錄制的測試腳本進行,按指定的語法進行編輯。在錄制完測試腳本后，能夠對測試腳本進行編輯，方便進行特定的性能指標分析。其較為豐富的圖形化測試成果大大提高了測試報告的可閱讀性。OpenSTA基于CORBA的構造體系，它通過虛擬一種proxy，使用其專用的腳本控制語言，統計通過proxy的一切HTTP/Straffic。通過分析OpenSTA的性能指標收集器收集的各項性能指標，以及HTTP數據，對系統的性能進行分析。優點：OpenSTA以最簡樸的方式讓大家對性能測試的原理有較深的理解，其較為豐富的圖形化測試成果大大提高了測試報告的可閱讀性。壓力測試引擎含有可擴充性，能夠完畢打規模的壓力測試。提供腳本語言支持。缺點：1、腳本語言過于復雜，自定義腳本相稱困難2、僅支持HTTP1.0/1.1/HTTPS(SSL)合同。3、沒有嵌入虛擬IP、廣域網/局域網仿真功效，不支持集合點功效。4、場景設計方面太過于簡樸，對于構建某些復雜的場景比較麻煩5、沒有嵌入模擬真實顧客不同網絡速度的功效。6、OpenSTA不能跨平臺──它是一種只能執行在Windows平臺上的負載引擎，不能收集Linux性能數據。7、使用Repository管理測試腳本、配備等過于簡樸，保存腳本居然不能自己選擇途徑。8、Results成果報告的圖表太簡陋，功效太少，報告導出功效太簡陋。9、OpenSTA在過去的兩年中，都沒退出新版本，這個項目已經死掉了。JMeter：是一款在國外非常流行和受歡迎的開源性能測試工具，像LoadRunner同樣，它也提供了一種運用本地ProxyServer（代理服務器）來錄制生成測試腳本的功效，但是這個功效并不好用。優點：輕量級性能測試工具，ApacheJMeter是一種100％的純Java桌面應用，用于壓力測試和性能測量。它最初被設計用于Web應用測試但后來擴展到其它測試，源碼開放。缺點：中文論壇極少，需要二次開發，錄制腳本不好用。WAS(WebApplicationStress)：是Microsoft公司下的一款免費產品。WAS允許你以不同的方式創立測試腳本：你能夠通過使用瀏覽器走一遍站點來錄制腳本，能夠從服務器的日志文獻導入URL，或者從一種網絡內容文獻夾選擇一種文獻。固然，你也能夠手工地輸入URL來創立一種新的測試腳本。優點：1、簡樸性

不像其它的工具，你能夠使用任何數量的客戶端運行測試腳本，全部都有一種中央主客戶端來控制。在每一種測試開始前，主客戶機透明地執行下列任務：

*與其它全部的客戶機通訊。

*把測試數據分發給全部的客戶端。

*在全部客戶端同時初始化測試。

*從全部的客戶端收集測試成果和報告。

這個特性非常重要，特別對于要測試一種需要使用諸多客戶端的服務器群的最大吞吐量時非常有用。2、高可用性

WAS是被設計用于模擬Web瀏覽器發送請求到任何采用了HTTP1.0或1.1原則的服務器，而不考慮服務器運行的平臺。除了它的易用性外，WAS尚有諸多其它的有用的特性，涉及：

*對于需要簽名登錄的網站，它允許創立顧客帳號。

*允許為每個顧客存儲cookies和ActiveServerPages(ASP)的session信息。

*支持隨機的或次序的數據集，以用在特定的名字-值對。

*支持帶寬調節和隨機延遲（“思考的時間”）以更真實地模擬顯示情形。

*支持SecureSocketsLayer(SSL)合同。

*允許URL分組和對每組的點擊率的闡明。

*提供一種對象模型，能夠通過MicrosoftVisualBasic?ScriptingEdition(VBScript)解決或者通過定制編程來達成啟動，結束和配備測試腳本的效果。缺點：

1、以前面所發請求返回的成果為基礎，修改URL參數的能力。

2、運行或模仿客戶端邏輯的能力。

3、為所分派的測試指定一種擬定數量的測試周期的能力。

4、對擁有不同IP地址或域名的多個服務器的同時測試能力。5、WAS只支持WindowsNT4.0SP4或者更高及Windows，對于其它系統，不能獲取PerfCounters。6、WAS測試成果報告不能圖形化顯示。成果報告可分析性低。主流負載性能工具的比較圖以下：屬性LoadRunnerQALoadWebLoad出品公司HP(Mercury)CompuwareRadview價格昂貴較貴普通安裝配備的復雜性簡樸簡樸普通操作性較復雜簡樸簡樸支持測試對象多個中間件/數據庫/應用服務器的性能監控/公司架構(j2ee和.net)的測試客戶/服務器系統、公司資源配備(ERP)和電子商務應用WebApplication支持平臺windows,unix或linuxHP-UX,IBMAIX,SunSolaris,Linux,NT/2kUnixWindows支持數據庫DB2,SQLserver,

Orcale,SybaseADO,DB2,Oracle,Sybase,

SQLserver,OdbcADO,DB2,Oracle,Sybase,

SQLserver,Odbc支持合同web,http(s),soap,streaming,

wap,winsock,xmlhttp,ssl,soap,xml,

streaming,mediaxml,java,ejb,

activex,wap,http,snmp,

real/m$streaming腳本語言類似C++C/C++和VC++Javascript自動數據生成YYY腳本調試YYY報表定制功效YYY功效點創立虛擬顧客，創立真實的負載，定位性能問題，分析成果以精擬定位問題所在，重復測試確保系統公布的高性能等預測系統性能、通過重復測試尋找瓶頸問題、從控制中心管理全局負載測試、快速創立仿真的測試、驗證應用的可擴展性。強大的專業網站性能測試，虛擬多顧客虛擬顧客上限數量成千上萬成百上千理論上無限，但是受機器的限制，同時運行太多影響成果的精確性公司網址Http://可下載5.2資源監控工具資源監控作為系統壓力測試過程中的一種重要環節，在有關的測試工具中基本上都有諸多的集成。只是不同的工具之間，監控的中間件、數據庫、主機平臺的能力以及方式各有差別。而這些監控工具更大程度上都依賴于被監控平臺本身的數據采集能力，現在的絕大多數的監控工具基本上是直接從中間件、數據庫以及主機本身提供的性能數據采集接口獲取性能指標。首先，不同的應用平臺有本身的監控命令以及控制界面。例如UNIX主機顧客能夠直接使用topas，vmstat,iostat理解系統本身的健康工作狀況。另外，weblogic以及websphere平臺都有本身的監控臺，在上面能夠理解到現在的JVM的大小、數據庫連接池的使用狀況以及現在連接的客戶端數量以及請求狀況等等。只是這些監控方式的使用對測試人員有一定的技術儲藏規定，需要自己純熟掌握以上監控方式的使用。第三方的監控工具對應的對某些系統平臺的監控進行了集成。例如Loadrunner對現在慣用的某些業務系統平臺環境都提供了對應的監控入口，從而能夠在并發測試的同時，對業務系統所處的測試環境進行監控，更加好的分析測試數據。但Loadrunner工具其提供的監控方式還不是很直觀，某些更直觀的測試工具能在監控的同時提供有關的報警信息，類似的監控產品如QUEST公司提供的一整套監控解決方案涉及了主機的監控、中間件平臺的監控以及數據庫平臺的監控。QUEST系列監控產品提供了直觀的圖形化界面，能讓測試者盡快進入監控的角色。性能測試的監控指標重要涉及下列幾個部分： 1、服務器：Linux應用服務器 具體涉及CPU、Memory、Load、I/O、Disk等。 2、數據庫：1.Mysql

2.Oracle具體涉及緩存命中、索引、單條SQL性能、數據庫線程數、數據池連接數等。 3、中間件：1.Jboss

2.Apache具體涉及線程數、連接數、日志輸出等。 4、網絡具體涉及防火墻、網卡、網線、吞吐量、吞吐率等。 5、應用服務具體涉及JVM內存使用和回收、JAVA內存使用、FullGC頻率、JAVA類裝入和卸載、日志、線程運行狀態（阻塞、等待、正常運行）等。 6、監控工具（LoadRunner）具體涉及顧客執行狀況、場景狀態、事務響應時間、TPS、Load、CPU分析圖表等。 7、測試機資源具體涉及CPU、Memory、網絡、日志輸出、磁盤空間、負載生成器評定等5.3故障定位工具以及調優工具技術的不停發展以及測試需求的不停提高，故障定位工具應運而生，它能更精細的對負載壓力測試中暴露的問題進行故障本源分析。在現在的主流測試工具廠商中，都對應地提供了對應的產品支持。特別是現在.NET以及J2EE架構的流行，測試工具廠商紛紛在這些領域提供了有關的技術產品，例如Loadrunner模塊中添加的診療以及調優模塊、

Quest公司的PerformaSure、Compuware的Vantage套件以及CA公司收購的Wily的Introscope工具等等，都在更深層次上對業務流的調用進行追蹤。這些工具在中間件平臺上引入探針技術，能捕獲后臺業務內部的調用關系，發現問題所在，為應用系統的調優提供直接的參考指南。在數據庫產品的故障定位分析上，Oracle本身提供了強大的診療模塊，同時，Quest公司的數據庫產品也在數據庫設計、開發以及上線運行維護都提供了全套的產品支持。6服務器與終端連接性能測試點6.1服務器性能瓶頸測試點終端顧客訪問服務器。找到在同一場景下，服務器允許終端顧客訪問數量的瓶頸。在測試場景中，需檢測的系統資源項，涉及以下：內存分析內存分析用于判斷系統有無內存瓶頸，與否需要通過增加內存等手段提高系統性能體現。內存分析需要使用的計數器：Memory類別和PhysicalDisk類別的計數器。內存分析的重要辦法和環節：（1）首先查看Memory\AvailableMbytes指標如果該指標的數據比較小，系統可能出現了內存方面的問題。（2）注意Pages/sec、PagesRead/sec和PageFaults/sec的值操作系統會運用磁盤較好的方式提高系統可用內存量或者提高內存的使用效率。這三個指標直接反映了操作系統進行磁盤交換的頻度。如果Pages/sec的計數持續高于幾百，可能有內存問題。但Pages/sec值不一定就表明有內存問題，可能是運行使用內存映射文獻的程序所致。PageFaults/