標籤: 暫無標籤

性能測試是通過自動化的測試工具模擬多種正常、峰值以及異常負載條件來對系統的各項性能指標進行測試。負載測試和壓力測試都屬於性能測試,兩者可以結合進行。通過負載測試,確定在各種工作負載下系統的性能,目標是測試當負載逐漸增加時,系統各項性能指標的變化情況。

性能測試是通過自動化的測試工具模擬多種正常、峰值以及異常負載條件來對系統的各項性能指標進行測試。負載測試和壓力測試都屬於性能測試,兩者可以結合進行。通過負載測試,確定在各種工作負載下系統的性能,目標是測試當負載逐漸增加時,系統各項性能指標的變化情況。壓力測試是通過確定一個系統的瓶頸或者不能接收的性能點,來獲得系統能提供的最大服務級別的測試。

一、概述

      性能測試在軟體的質量保證中起著重要的作用,它包括的測試內容豐富多樣。中國軟體評測中心將性能測試概括為三個方面:應用在客戶端性能的測試、應用在網路上性能的測試和應用在伺服器端性能的測試。通常情況下,三方面有效、合理的結合,可以達到對系統性能全面的分析和瓶頸的預測。

    ·應用在客戶端性能的測試

  應用在客戶端性能測試的目的是考察客戶端應用的性能,測試的入口是客戶端。它主要包括併發性能測試、疲勞強度測試、大數據量測試和速度測試等,其中併發性能測試是重點。

      併發性能測試是重點

  併發性能測試的過程是一個負載測試和壓力測試的過程,即逐漸增加負載,直到系統的瓶頸或者不能接收的性能點,通過綜合分析交易執行指標和資源監控指標來確定系統併發性能的過程。負載測試(Load Testing)是確定在各種工作負載下系統的性能,目標是測試當負載逐漸增加時,系統組成部分的相應輸出項,例如通過量、響應時間、CPU負載、內存使用等來決定系統的性能。負載測試是一個分析軟體應用程序和支撐架構、模擬真實環境的使用,從而來確定能夠接收的性能過程。壓力測試(Stress Testing)是通過確定一個系統的瓶頸或者不能接收的性能點,來獲得系統能提供的最大服務級別的測試。

  併發性能測試的目的主要體現在三個方面:以真實的業務為依據,選擇有代表性的、關鍵的業務操作設計測試案例,以評價系統的當前性能;當擴展應用程序的功能或者新的應用程序將要被部署時,負載測試會幫助確定系統是否還能夠處理期望的用戶負載,以預測系統的未來性能;通過模擬成百上千個用戶,重複執行和運行測試,可以確認性能瓶頸並優化和調整應用,目的在於尋找到瓶頸問題。

  當一家企業自己組織力量或委託軟體公司代為開發一套應用系統的時候,尤其是以後在生產環境中實際使用起來,用戶往往會產生疑問,這套系統能不能承受大量的併發用戶同時訪問? 這類問題最常見於採用聯機事務處理(OLTP)方式資料庫應用、Web瀏覽和視頻點播等系統。這種問題的解決要藉助於科學的軟體測試手段和先進的測試工具。

      舉例說明:電信計費軟體

  眾所周知,每月20日左右是市話交費的高峰期,全市幾千個收費網點同時啟動。收費過程一般分為兩步,首先要根據用戶提出的電話號碼來查詢出其當月產生費用,然後收取現金並將此用戶修改為已交費狀態。一個用戶看起來簡單的兩個步驟,但當成百上千的終端,同時執行這樣的操作時,情況就大不一樣了,如此眾多的交易同時發生,對應用程序本身、操作系統、中心資料庫伺服器、中間件伺服器、網路設備的承受力都是一個嚴峻的考驗。決策者不可能在發生問題后才考慮系統的承受力, 預見軟體的併發承受力, 這是在軟體測試階段就應該解決的問題。

  目前,大多數公司企業需要支持成百上千名用戶,各類應用環境以及由不同供應商提供的元件組裝起來的複雜產品,難以預知的用戶負載和愈來愈複雜的應用程序,使公司擔憂會發生投放性能差、用戶遭受反應慢、系統失靈等問題。其結果就是導致公司收益的損失。

  如何模擬實際情況呢? 找若干台電腦和同樣數目的操作人員在同一時刻進行操作,然後拿秒錶記錄下反應時間? 這樣的手工作坊式的測試方法不切實際,且無法捕捉程序內部變化情況,這樣就需要壓力測試工具的輔助。

  測試的基本策略是自動負載測試,通過在一台或幾台PC機上模擬成百或上千的虛擬用戶同時執行業務的情景,對應用程序進行測試,同時記錄下每一事務處理的時間、中間件伺服器峰值數據、資料庫狀態等。通過可重複的、真實的測試能夠徹底地度量應用的可擴展性和性能,確定問題所在以及優化系統性能。預先知道了系統的承受力,就為最終用戶規劃整個運行環境的配置提供了有力的依據。

      併發性能測試前的準備工作

  測試環境:配置測試環境是測試實施的一個重要階段,測試環境的適合與否會嚴重影響測試結果的真實性和正確性。測試環境包括硬體環境和軟體環境,硬體環境指測試必需的伺服器、客戶端、網路連接設備以及印表機/掃描儀等輔助硬體設備所構成的環境;軟體環境指被測軟體運行時的操作系統、資料庫及其他應用軟體構成的環境。

  一個充分準備好的測試環境有三個優點:一個穩定、可重複的測試環境,能夠保證測試結果的正確;保證達到測試執行的技術需求;保證得到正確的、可重複的以及易理解的測試結果。

  測試工具:併發性能測試是在客戶端執行的黑盒測試,一般不採用手工方式,而是利用工具採用自動化方式進行。目前,成熟的併發性能測試工具有很多,選擇的依據主要是測試需求和性能價格比。著名的併發性能測試工具有QALoad、LoadRunner、Benchmark Factory和Webstress等。這些測試工具都是自動化負載測試工具,通過可重複的、真實的測試,能夠徹底地度量應用的可擴展性和性能,可以在整個開發生命周期、跨越多種平台、自動執行測試任務,可以模擬成百上千的用戶併發執行關鍵業務而完成對應用程序的測試。

  測試數據:在初始的測試環境中需要輸入一些適當的測試數據,目的是識別數據狀態並且驗證用於測試的測試案例,在正式的測試開始以前對測試案例進行調試,將正式測試開始時的錯誤降到最低。在測試進行到關鍵過程環節時,非常有必要進行數據狀態的備份。製造初始數據意味著將合適的數據存儲下來,需要的時候恢復它,初始數據提供了一個基線用來評估測試執行的結果。

  在測試正式執行時,還需要準備業務測試數據,比如測試併發查詢業務,那麼要求對應的資料庫和表中有相當的數據量以及數據的種類應能覆蓋全部業務。

  模擬真實環境測試,有些軟體,特別是面向大眾的商品化軟體,在測試時常常需要考察在真實環境中的表現。如測試殺毒軟體的掃描速度時,硬碟上布置的不同類型文件的比例要盡量接近真實環境,這樣測試出來的數據才有實際意義。

      併發性能測試的種類與指標

  併發性能測試的種類取決於併發性能測試工具監控的對象,以QALoad自動化負載測試工具為例。軟體針對各種測試目標提供了DB2、DCOM、ODBC、ORACLE、NETLoad、Corba、QARun、SAP、SQLServer、Sybase、Telnet、TUXEDO、UNIFACE、WinSock、WWW、Java Script等不同的監控對象,支持Windows和UNIX測試環境。

  最關鍵的仍然是測試過程中對監控對象的靈活應用,例如目前三層結構的運行模式廣泛使用,對中間件的併發性能測試作為問題被提到議事日程上來,許多系統都採用了國產中間件,選擇Java Script監控對象,手工編寫腳本,可以達到測試目的。

  採用自動化負載測試工具執行的併發性能測試,基本遵循的測試過程有:測試需求與測試內容,測試案例制定,測試環境準備,測試腳本錄製、編寫與調試,腳本分配、回放配置與載入策略,測試執行跟蹤,結果分析與定位問題所在,測試報告與測試評估。

  併發性能測試監控的對象不同,測試的主要指標也不相同,主要的測試指標包括交易處理性能指標和UNIX資源監控。其中,交易處理性能指標包括交易結果、每分鐘交易數、交易響應時間(Min:最小伺服器響應時間;Mean:平均伺服器響應時間;Max:最大伺服器響應時間;StdDev:事務處理伺服器響應的偏差,值越大,偏差越大;Median:中值響應時間;90%:90%事務處理的伺服器響應時間)、虛擬併發用戶數。

      應用實例:「新華社多媒體資料庫 V1.0」性能測試

  中國軟體評測中心(CSTC)根據新華社技術局提出的《多媒體資料庫(一期)性能測試需求》和GB/T 17544《軟體包質量要求和測試》的國家標準,使用工業標準級負載測試工具對新華社使用的「新華社多媒體資料庫 V1.0」進行了性能測試。

  性能測試的目的是模擬多用戶併發訪問新華社多媒體資料庫,執行關鍵檢索業務,分析系統性能。

  性能測試的重點是針對系統併發壓力負載較大的主要檢索業務,進行併發測試和疲勞測試,系統採用B/S運行模式。併發測試設計了特定時間段內分別在中文庫、英文庫、圖片庫中進行單檢索詞、多檢索詞以及變檢索式、混合檢索業務等併發測試案例。疲勞測試案例為在中文庫中併發用戶數200,進行測試周期約8小時的單檢索詞檢索。在進行併發和疲勞測試的同時,監測的測試指標包括交易處理性能以及UNIX(Linux)、Oracle、Apache資源等。

  測試結論:在新華社機房測試環境和內網測試環境中,100M帶寬情況下,針對??為200的負載壓力,最大交易數/分鐘達到78.73,運行基本穩定,但隨著負載壓力增大,系統性能有所衰減。

  系統能夠承受200併發用戶數持續周期約8小時的疲勞壓力,基本能夠穩定運行。

  通過對系統UNIX(Linux)、Oracle和Apache資源的監控,系統資源能夠滿足上述併發和疲勞性能需求,且系統硬體資源尚有較大利用餘地。

  當併發用戶數超過200時,監控到HTTP 500、connect和超時錯誤,且Web伺服器報內存溢出錯誤,系統應進一步提高性能,以支持更大併發用戶數。

  建議進一步優化軟體系統,充分利用硬體資源,縮短交易響應時間。

      疲勞強度與大數據量測試

  疲勞測試是採用系統穩定運行情況下能夠支持的最大併發用戶數,持續執行一段時間業務,通過綜合分析交易執行指標和資源監控指標來確定系統處理最大工作量強度性能的過程。

  疲勞強度測試可以採用工具自動化的方式進行測試,也可以手工編寫程序測試,其中後者占的比例較大。

  一般情況下以伺服器能夠正常穩定響應請求的最大併發用戶數進行一定時間的疲勞測試,獲取交易執行指標數據和系統資源監控數據。如出現錯誤導致測試不能成功執行,則及時調整測試指標,例如降低用戶數、縮短測試周期等。還有一種情況的疲勞測試是對當前系統性能的評估,用系統正常業務情況下併發用戶數為基礎,進行一定時間的疲勞測試。

  大數據量測試可以分為兩種類型:針對某些系統存儲、傳輸、統計、查詢等業務進行大數據量的獨立數據量測試;與壓力性能測試、負載性能測試、疲勞性能測試相結合的綜合數據量測試方案。大數據量測試的關鍵是測試數據的準備,可以依靠工具準備測試數據。

  速度測試目前主要是針對關鍵有速度要求的業務進行手工測速度,可以在多次測試的基礎上求平均值,可以和工具測得的響應時間等指標做對比分析。

      ·應用在網路上性能的測試

  應用在網路上性能的測試重點是利用成熟先進的自動化技術進行網路應用性能監控、網路應用性能分析和網路預測。

      網路應用性能分析

  網路應用性能分析的目的是準確展示網路帶寬、延遲、負載和TCP埠的變化是如何影響用戶的響應時間的。利用網路應用性能分析工具,例如Application Expert,能夠發現應用的瓶頸,我們可知應用在網路上運行時在每個階段發生的應用行為,在應用線程級分析應用的問題。可以解決多種問題:客戶端是否對資料庫伺服器運行了不必要的請求?當伺服器從客戶端接受了一個查詢,應用伺服器是否花費了不可接受的時間聯繫資料庫伺服器?在投產前預測應用的響應時間;利用Application Expert調整應用在廣域網上的性能;Application Expert能夠讓你快速、容易地模擬應用性能,根據最終用戶在不同網路配置環境下的響應時間,用戶可以根據自己的條件決定應用投產的網路環境。

      網路應用性能監控

  在系統試運行之後,需要及時準確地了解網路上正在發生什麼事情;什麼應用在運行,如何運行;多少PC正在訪問LAN或WAN;哪些應用程序導致系統瓶頸或資源競爭,這時網路應用性能監控以及網路資源管理對系統的正常穩定運行是非常關鍵的。利用網路應用性能監控工具,可以達到事半功倍的效果,在這方面我們可以提供的工具是Network Vantage。通俗地講,它主要用來分析關鍵應用程序的性能,定位問題的根源是在客戶端、伺服器、應用程序還是網路。在大多數情況下用戶較關心的問題還有哪些應用程序佔用大量帶寬,哪些用戶產生了最大的網路流量,這個工具同樣能滿足要求。

      網路預測

  考慮到系統未來發展的擴展性,預測網路流量的變化、網路結構的變化對用戶系統的影響非常重要。根據規劃數據進行預測並及時提供網路性能預測數據。我們利用網路預測分析容量規劃工具PREDICTOR可以作到:設置服務水平、完成日網路容量規劃、離線測試網路、網路失效和容量極限分析、完成日常故障診斷、預測網路設備遷移和網路設備升級對整個網路的影響。

  從網路管理軟體獲取網路拓撲結構、從現有的流量監控軟體獲取流量信息(若沒有這類軟體可人工生成流量數據),這樣可以得到現有網路的基本結構。在基本結構的基礎上,可根據網路結構的變化、網路流量的變化生成報告和圖表,說明這些變化是如何影響網路性能的。 PREDICTOR提供如下信息:根據預測的結果幫助用戶及時升級網路,避免因關鍵設備超過利用閥值導致系統性能下降;哪個網路設備需要升級,這樣可減少網路延遲、避免網路瓶頸;根據預測的結果避免不必要的網路升級。

      ·應用在伺服器上性能的測試

  對於應用在伺服器上性能的測試,可以採用工具監控,也可以使用系統本身的監控命令,例如Tuxedo中可以使用Top命令監控資源使用情況。實施測試的目的是實現伺服器設備、伺服器操作系統、資料庫系統、應用在伺服器上性能的全面監控,測試原理如下圖。

UNIX資源監控指標和描述

  監控指標 描述
  平均負載 系統正常狀態下,最後60秒同步進程的平均個數
  衝突率 在乙太網上監測到的每秒衝突數
  進程/線程交換率 進程和線程之間每秒交換次數
  CPU利用率 CPU佔用率(%)
  磁碟交換率 磁碟交換速率
  接收包錯誤率 接收乙太網數據包時每秒錯誤數
  包輸入率 每秒輸入的乙太網數據包數目
  中斷速率 CPU每秒處理的中斷數
  輸出包錯誤率 發送乙太網數據包時每秒錯誤數
  包輸入率 每秒輸出的乙太網數據包數目
  讀入內存頁速率 物理內存中每秒讀入內存頁的數目
  寫出內存頁速率 每秒從物理內存中寫到頁文件中的內存頁數
   目或者從物理內存中刪掉的內存頁數目
  內存頁交換速率 每秒寫入內存頁和從物理內存中讀出頁的個數
  進程入交換率 交換區輸入的進程數目
  進程出交換率 交換區輸出的進程數目
  系統CPU利用率 系統的CPU佔用率(%)
  用戶CPU利用率 用戶模式下的CPU佔用率(%)
  磁碟阻塞 磁碟每秒阻塞的位元組數

二、為什麼進行性能測試?

      目的是驗證軟體系統是否能夠達到用戶提出的性能指標,同時發現軟體系統中存在的性能瓶頸,優化軟體,最後起到優化系統的目的。

      包括以?的能力,測試中得到的負荷和響應時間數據可以被用於驗證所計劃的模型的能力,並幫助作出決策。
2.識別體系中的弱點:受控的負荷可以被增加到一個極端的水平,並突破它,從而修復體系的瓶頸或薄弱的地方。
3.系統調優:重複運行測試,驗證調整系統的活動得到了預期的結果,從而改進性能。
檢測軟體中的問題:長時間的測試執行可導致程序發生由於內存泄露引起的失敗,揭示程序中的隱含的問題或衝突。
4.驗證穩定性(resilience)可靠性(reliability):在一個生產負荷下執行測試一定的時間是評估系統穩定性和可靠性是否滿足要求的唯一方法。

性能測試分類

      性能測試類型包括負載測試,強度測試,容量測試等

      負載測試:負載測試是一種性能測試指數據在超負荷環境中運行,程序是否能夠承擔。

      強度測試: 強度測試是一種性能測試,他在系統資源特別低的情況下軟體系統運行情況。

      容量測試:確定系統可處理同時在線的最大用戶數  

觀察指標

      性能測試主要是通過自動化的測試工具模擬多種正常、峰值以及異常負載條件來對系統的各項性能指標進行測試。負載測試和壓力測試都屬於性能測試,兩者可以結合進行。通過負載測試,確定在各種工作負載下系統的性能,目標是測試當負載逐漸增加時,系統各項性能指標的變化情況。壓力測試是通過確定一個系統的瓶頸或者不能接收的性能點,來獲得系統能提供的最大服務級別的測試。

      在實際中作中我們經常會對兩種類型軟體進行測試:bs和cs,這兩方面的性能指標一般需要哪些內容呢?

Bs結構程序一般會關注的通用指標如下(簡):

Web伺服器指標指標:

* Avg Rps: 平均每秒鐘響應次數=總請求時間 / 秒數;

* Avg time to last byte per terstion (mstes):平均每秒業務角本的迭代次數 ,有人會把這兩者混淆;

* Successful Rounds:成功的請求;

* Failed Rounds :失敗的請求;

* Successful Hits :成功的點擊次數;

* Failed Hits :失敗的點擊次數;

* Hits Per Second :每秒點擊次數;

* Successful Hits Per Second :每秒成功的點擊次數;

* Failed Hits Per Second :每秒失敗的點擊次數;

* Attempted Connections :嘗試鏈接數;

CS結構程序,由於一般軟體後台通常為資料庫,所以我們更注重資料庫的測試指標:

* User 0 Connections :用戶連接數,也就是資料庫的連接數量;

* Number of deadlocks:資料庫死鎖;

* Butter Cache hit :資料庫Cache的命中情況

      當然,在實際中我們還會察看多用戶測試情況下的內存,CPU,系統資源調用情況。這些指標其實是引申出來性能測試中的一種:競爭測試。什麼是競爭測試,軟體競爭使用各種資源(數據紀錄,內存等),看他與其他相關係統對資源的爭奪能力。

      我們知道軟體架構在實際測試中制約著測試策略和工具的選擇。如何選擇性能測試策略是我們在實際工作中需要了解的。一般軟體可以按照系統架構分成幾種類型:

c/s

client/Server 客戶端/伺服器架構

基於客戶端/伺服器的三層架構

基於客戶端/伺服器的分散式架構

b/s

基於瀏覽器/Web伺服器的三層架構

基於中間件應用伺服器的三層架構l

基於Web伺服器和中間件的多層架構l

三、性能測試的步驟

      在每種不同的系統架構的實施中,開發人員可能選擇不同的實現方式,造成實際情況紛繁複雜。我們不可能對每種技術都詳細解說,這裡只是介紹一種方法提供給你如何選擇測試策略,從而幫助分析軟體不同部分的性能指標,進而分析出整體架構的性能指標和性能瓶頸。

      由於工程和項目的不同,所選用的度量,評估方法也有不同之處。不過仍然有一些通用的步驟幫助我們完成一個性能測試項目。步驟如下

1.  制定目標和分析系統
2.  選擇測試度量的方法
3.  學習的相關技術和工具
4.  制定評估標準
5.  設計測試用例
6.  運行測試用例
7.  分析測試結果

·制定目標和分析系統

    每一個性能測試計劃中第一步都會制??構成才會澄清測試範圍,知道在測試中要掌握什麼樣的技術。   

目標:

1.  確定客戶需求和期望

2.  實際業務需求

3.  系統需求

系統組成

    系統組成這裡包含幾方面含義:系統類別,系統構成,系統功能等。了解這些內容的本質其實是幫助我們明確測試的範圍,選者適當的測試方法來進行測試。

    系統類別:分清系統類別是我們掌握什麼樣的技術的前提,掌握相應技術做性能測試才可能成功。例如:系統類別是bs結構,需要掌握 http協議,java,html等技術 。或者是cs結構,可能要了解操作系統,winsock,com等。所以甄別系統類別對於我們來說很重要。

    系統構成:硬體設置,操作系統設置是性能測試的制約條件,一般性能測試都是利用測試工具模仿大量的實際用戶操作,系統在超負荷情形下運作。不同的系統構成性能測試就會得到不同的結果。

    系統功能:系統功能指系統提供的不同子系統,辦公管理系統中的公文子系統,會議子系統等,系統工能是性能測試中要模擬的環節,了解這些是必要的。

·選擇測試度量的方法

經過第一步,將會對系統有清醒的認識。接下來我們將把精力放在軟體度量上,收集系統相關的數據。

度量的相關方面:

* 制定規範

* 制定相關流程, 角色,職責

* 制定改進策略

* 制定結果對比標準

·學習的相關技術和工具

      性能測試是通過工具,模擬大量用戶操作,對系統增加負載。所以需要掌握一定的工具知識才能進行性能測試。大家都知道性能測試工具一般通過winsock,http等協議紀錄用戶操作。而協議選擇是基於軟體的系統架構實現(web一般選擇http協議,cs選擇winsock協議),不同的性能測試工具,腳本語言也不同,比如rational robot中vu腳本用類c語言實現。

      開展性能測試需要對各種性能測試工具進行評估,因為每一種性能測試工具都有自身的特點,只有經過工具評估,才能選擇符合現有軟體架構的性能測試工具。確定測試工具后,需要組織測試人員進行工具的學習,培訓相關技術。

·制定評估標準

         任何測試的目的都是確保軟體符合預先規定的目標和要求。性能測試也不例外。所以必須制定一套標準。

      通常性能測試有四種模型技術可用於評估:

         *線性投射:用大量的過去的,擴展的或者將來可能發生的數據組成散布圖,利用這個圖表不斷和系統的當前狀況對比。

         *分析模型:用排隊論公式和演算法預測響應時間,利用描述工作量的數據和系統本質關聯起來

         *模仿:模仿實際用戶的使用方法測試你的系統

         *基準:定義測試和你最初的測試作為標準,利用它和所有後來進行的測試結果進行對比

·設計測試用例

    設計測試用例是在了解軟體業務流程的基礎上。設計測試用例的原則是受最小的影響提供最多的測試信息,設計測試用例的目標是一次儘可能的包含多個測試要素。這些測試用例必須是測試工具可以實現的,不同的測試場景將測試不同的功能。因為性能測試不同於平時的測試用例,儘可能把性能測試用例設計的複雜,才有可能發現軟體的性能瓶頸。

·運行測試用例

    通過性能測試工具運行測試用例。同一環境下作的性能測試得到的測試結果是不準確的,所以在運行這些測試用例的時候,需要用不同的測試環境,不同的機器配置上運行。

·分析測試結果

      運行測試用例后,收集相關信息,進行數據統計分析,找到性能瓶頸。通過排除誤差和其他因素,讓測試結果體現接近真實情況。不同的體系結構分析測試結果的方法也不同,bs結構我們會分析網路帶寬,流量對用戶操作響應的影響,而cs結構我們可能更關心會系統整體配置對用戶操作的影響。

四、性能測試方法

  對於企業應用程序,有許多進行性能測試的方法,其中一些方法實行起來要比其他方法困難。所要進行的性能測試的類型取決於想要達到的結果。例如,對於可再現性,基準測試是最好的方法。而要從當前用戶負載的角度測試系統的上限,則應該使用容量規劃測試。本文將介紹幾種設置和運行性能測試的方法,並討論這些方法的區別。

  如果不進行合理的規劃,對J2EE應用程序進行性能測試將會是一項令人望而生畏且有些混亂的任務。因為對於任何的軟體開發流程,都必須收集需求、理解業務需要,並在??的需求由業務需要驅動,並由一組用例闡明。這些用例可以基於歷史數據(例如,伺服器一周的負載模式)或預測的近似值。弄清楚需要測試的內容之後,就需要知道如何進行測試了。

  在開發階段前期,應該使用基準測試來確定應用程序中是否出現性能倒退。基準測試可以在一個相對短的時間內收集可重複的結果。進行基準測試的最好方法是,每次測試改變一個且只改變一個參數。例如,如果想知道增加JVM內存是否會影響應用程序的性能,就逐次遞增JVM內存(例如,從1024 MB增至1224 MB,然後是1524 MB,最後是2024 MB),在每個階段收集結果和環境數據,記錄信息,然後轉到下一階段。這樣在分析測試結果時就有跡可循。下一小節我將介紹什麼是基準測試,以及運行基準測試的最佳參數。

  開發階段後期,在應用程序中的bug已經被解決,應用程序達到一種穩定狀態之後,可以運行更為複雜的測試,確定系統在不同的負載模式下的表現。這些測試被稱為容量規劃測試、滲入測試(soak test)、峰谷測試(peak-rest test),它們旨在通過測試應用程序的可靠性、健壯性和可伸縮性來測試接近於現實世界的場景。對於下面的描述應該從抽象的意義上理解,因為每個應用程序的使用模式都是不同的。例如,容量規劃測試通常都使用較緩慢的ramp-up(下文有定義),但是如果應用程序在一天之中的某個時段中有快速突發的流量,那麼自然應該修改測試以反映這種情況。但是,要記住,因為更改了測試參數(比如ramp-up周期或用戶的考慮時間(think-time)),測試的結果肯定也會改變。一個不錯的方法是,運行一系列的基準測試,確立一個已知的可控環境,然後再對變化進行比較。

基準測試

  基準測試的關鍵是要獲得一致的、可再現的結果。可再現的結果有兩個好處:減少重新運行測試的次數;對測試的產品和產生的數字更為確信。使用的性能測試工具可能會對測試結果產生很大影響。假定測試的兩個指標是伺服器的響應時間和吞吐量,它們會受到伺服器上的負載的影響。伺服器上的負載受兩個因素影響:同時與伺服器通信的連接(或虛擬用戶)的數目,以及每個虛擬用戶請求之間的考慮時間的長短。很明顯,與伺服器通信的用戶越多,負載就越大。同樣,請求之間的考慮時間越短,負載也越大。這兩個因素的不同組合會產生不同的伺服器負載等級。記住,隨著伺服器上負載的增加,吞吐量會不斷攀升,直到到達一個點。

性能測試

圖1.隨著負載的增加,系統吞吐量的曲線(單位:頁面/秒)

  注意,吞吐量以穩定的速度增長,然後在某一個點上穩定下來。

  在某一點上,執行隊列開始增長,因為伺服器上所有的線程都已投入使用,傳入的請求不再被立即處理,而是放入隊列中,當線程空閑時再處理。

性能測試
圖2. 隨著負載的增加,系統執行隊列長度的曲線

  注意,最初的一段時間,執行隊列的長度為零,然後就開始以穩定的速度增長。這是因為系統中的負載在穩定增長,雖然最初系統有足夠的空閑線程去處理增加的負載,最終它還是不能承受,而必須將其排入隊列。

  當系統達到飽和點,伺服器吞吐量保持穩定后,就達到了給定條件下的系統上限。但是,隨著伺服器負載的繼續增長,系統的響應時間也隨之延長,雖然吞吐量保持穩定。

性能測試
圖3. 隨著負載的增加,系統中兩個事務的響應時間曲線

  注意,在執行隊列(圖2)開始增長的同時,響應時間也開始以遞增的速度增長。這是因為請求不能被及時處理。

  為了獲得真正可再現的結果,應該將系統置於相同的高負載下。為此,與伺服器通信的虛擬用戶應該將請求之間的考慮時間設為零。這樣伺服器會立即超載,並開始構建執行隊列。如果請求(虛擬用戶)數保持一致,基準測試的結果應該會非常精確,完全可以再現。

  您可能要問的一個問題是:「如何度量結果?」對於一次給定的測試,應該取響應時間和吞吐量的平均值。精確地獲得這些值的唯一方法是一次載入所有的用戶,然後在預定的時間段內持續運行。這稱為「flat」測試。

性能測試
圖4. flat測試的情況(所有的用戶都是同時載入的)

  與此相對應的是「ramp-up」測試。

性能測試
圖5. ramp-up測試的情況(在測試期間,用戶以穩定速度(每秒x個)增加)

  ramp-up測試中的用戶是交錯上升的(每幾秒增加一些新用戶)。ramp-up測試不能產生精確和可重現的平均值,這是因為由於用戶的增加是每次一部分,系統的負載在不斷地變化。因此,flat運行是獲得基準測試數據的理想模式。

  這不是在貶低ramp-up測試的價值。實際上,ramp-up測試對找出以後要運行的flat測試的範圍非常有用。ramp-up測試的優點是,可以看出隨著系統負載的改變,測量值是如何改變的。然後可以據此選擇以後要運行的flat測試的範圍。

  Flat測試的問題是系統會遇到「波動」效果。

性能測試
圖6. 一次flat測試中所測得的系統吞吐量的曲線(單位:頁面/秒)

  注意波動的出現,吞吐量不再是平滑的。

  這在系統的各個方面都有所體現,包括CPU的使用量。

性能測試
圖7. 一次flat測試中所測得的系統CPU使用量隨時間變化的曲線

  注意,每隔一段時間就會出現一個波形。CPU使用量不再是平滑的,而是有了像吞吐量圖那樣的尖峰。

  此外,執行隊列也承受著不穩定的負載,因此可以看到,隨著系統負載的增加和減少,執行隊列也在增長和縮減。

性能測試
圖8. 一次flat測試中所測得的系統執行隊列的曲線

  注意,每隔一段時間就會出現一個波形。執行隊列曲線與上面的CPU使用量圖非常相似。

  最後,系統中事務的響應時間也遵循著這個波動模式。

性能測試
圖9. 一次flat測試中所測得的系統事務的響應時間

  注意,每隔一段時間就會出現一個波形。事務的響應時間也與上面的圖類似,只不過其效果隨著時間的推移逐漸減弱。

  當測試中所有的用戶都同時執行幾乎相同的操作時,就會發生這種現象。這將會產生非常不可靠和不精確的結果,所以必須採取一些措施防止這種情況的出現。有兩種方法可以從這種類型的結果中獲得精確的測量值。如果測試可以運行相當長的時間(有時是幾個小時,取決於用戶的操作持續的時間),最後由於隨機事件的本性使然,伺服器的吞吐量會被「拉平」。或者,可以只選取波形中兩個平息點之間的測量值。該方法的缺點是可以捕獲數據的時間非常短。

性能規劃測試

  對於性能規劃類型的測試來說,其目標是找出,在特定的環境下,給定應用程序的性能可以達到何種程度。此時可重現性就不如在基準測試中那麼重要了,因為測試中通常都會有隨機因子。引入隨機因子的目的是為了盡量模擬具有真實用戶負載的現實世界應用程序。通常,具體的目標是找出系統在特定的伺服器響應時間下支持的當前用戶的最大數。例如,您可能想知道:如果要以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測試,更精確地確定系統的容量。

滲入測試

  滲入測試是一種比較簡單的性能測試。滲入測試所需時間較長,它使用固定數目的併發用戶測試系統的總體健壯性。這些測試將會通過內存泄漏、增加的垃圾收集(GC)或系統的其他問題,顯示因長時間運行而出現的任何性能降低。測試運行的時間越久,您對系統就越了解。運行兩次測試是一個好主意——一次使用較低的用戶負載(要在系統容量之下,以便不會出現執行隊列),一次使用較高的負載(以便出現積極的執行隊列)。

  測試應該運行幾天的時間,以便真正了解應用程序的長期健康狀況。要確保測試的應用程序儘可能接近現實世界的情況,用戶場景也要逼真(虛擬用戶通過應用程序導航的方式要與現實世界一致),從而測試應用程序的全部特性。確保運行了所有必需的監控工具,以便精確地監測並跟蹤問題。

峰谷測試

  峰谷測試兼有容量規劃ramp-up類型測試和滲入測試的特徵。其目標是確定從高負載(例如系統高峰時間的負載)恢復、轉為幾乎空閑、然後再攀升到高負載、再降低的能力。

  實現這種測試的最好方法就是,進行一系列的快速ramp-up測試,繼之以一段時間的平穩狀態(取決於業務需求),然後急劇降低負載,此時可以令系統平息一下,然後再進行快速的ramp-up;反覆重複這個過程。這樣可以確定以下事項:第二次高峰是否重現第一次的峰值?其後的每次高峰是等於還是大於第一次的峰值?在測試過程中,系統是否顯示了內存或GC性能降低的有關跡象?測試運行(不停地重複「峰值/空閑」周期)的時間越長,您對系統的長期健康狀況就越了解。

結束語

  本文介紹了進行性能測試的幾種方法。取決於業務需求、開發周期和應用程序的生命周期,對於特定的企業,某些測試會比其他的更適合。但是,對於任何情況,在決定進行某一種測試前,都應該問自己一些基本問題。這些問題的答案將會決定哪種測試方法是最好的。

  這些問題包括:

結果的可重複性需要有多高?
測試需要運行和重新運行幾次?
您處於開放周期的哪個階段?
您的業務需求是什麼?
您的用戶需求是什麼?
您希望生產中的系統在維護停機時間中可以持續多久?
在一個正常的業務日,預期的用戶負載是多少?
  將這些問題的答案與上述性能測試類型相對照,應該就可以制定出測試應用程序的總體性能的完美計劃。

參考資料

WebLogic Server Performance and Tuning——WebLogic Server產品文檔
WebLogic Server performance tools and information——WebLogic Server產品文檔
The Grinder: Load Testing for Everyone(dev2dev,2002年11月),作者Philip Aston
Performance Tuning Guide——WebLogic Portal產品文檔
dev2dev WebLogic Server Product Center
原文出處

http://dev2dev.bea.com/pub/a/2005/09/performance_testing.html


作者簡介
 Matt Maccaux是BEA的一位門戶性能工程師。


上一篇[重組DNA技術]    下一篇 [膽鹼]

相關評論

同義詞:暫無同義詞