Web系統壓力測試方法研究與實踐

摘 要：Web系統已是當今信息系統開發和部署的主流選擇。在大數據時代，性能更是衡量信息系統可靠性的重要指標。文章在對Web系統壓力測試方法進行研究的基礎上，指出高效壓力測試的關鍵在于測試方案應盡可能接近真實應用負載，給出的項目實踐經驗很好地驗證了這一觀點。

關鍵詞：Web系統；性能；壓力測試

1 概述

近年來，隨著信息化技術的不斷發展，Web系統（瀏覽器/服務器，C/S架構）已經成為了信息系統開發和部署的主流選擇。相對于傳統的客戶端/服務器（B/S架構）信息系統，Web系統具有開發便捷、部署快速和易于維護的特點。同時，因其易于和其他系統及接口協同工作，具備了同時向上向下兼容的特性。如今高速發展的移動互聯網，大多數移動客戶端軟件后臺連接的都是Web應用系統。

對于任何一個商用信息系統，可靠性要求都是必須考慮的重要問題。對可靠性而言，除了基本的功能性保證，在大數據時代，系統的性能更是不能回避的問題。龐大的用戶群以及海量數據給Web應用系統的性能帶來了諸多挑戰。

2 Web系統壓力測試方法研究

2.1 影響Web系統性能的主要因素

作為依托網絡部署的系統，除去網絡這一相對外部的因素后，影響Web系統性能的自身內在因素主要有以下幾方面：

用戶并發數。并發數是建立在用戶量基礎上的、反應系統繁忙程度的重要指標。每一個在線用戶都會產生到后臺服務器的會話連接，對系統CPU、內存、I/O等資源產生開銷。在線用戶大量累積后一般都會引起系統性能的下降。

后臺數據量。每一次前臺頁面訪問對應都是后臺數據庫增、刪、改、查操作，其執行返回時間與系統后臺數據庫的基礎數據量直接相關。

用戶行為。業務邏輯復雜程度及在線用戶的行為特點也直接影響著性能。同樣數量的在線用戶，大面積地進行復雜綜合報表查詢，與僅僅進行靜態頁面瀏覽相比，對系統性能影響的差異是不言而喻的。

2.2 衡量Web系統性能的重要指標

一方面是系統的響應時間。完整的系統響應時間應該從用戶發起前臺頁面請求算起，涵蓋經過網絡傳輸、后臺服務器響應請求并返回結果，最終在用戶瀏覽器端完成頁面渲染、加載等環節全過程。響應時間是用戶可感知的，是系統性能的直觀體驗。

另一方面是系統的吞吐率。吞吐率是系統在單位時間內能夠處理的請求數，影響系統吞吐率最直接的因素是系統資源總量和完成單次請求所需的系統資源。在實踐中，一般指系統在單位時間內能夠成功完成的交易或事務數量。

2.3 Web系統主流壓力測試工具

進行Web系統壓力測試，需要高效的工具支持。在商業軟件方面，比較著名的產品有Loadrunner（原為Mercury產品，現已被惠普公司收購）、SilkPerformer（Borland公司產品）等；開源軟件方面，比較著名的有JMeter、Grinder，以及WebLOAD等。這些產品基本工作方式都是通過“錄制-回放”模式來編寫壓力測試腳本。

Web系統壓力測試是項目實踐工作中最關鍵的環節，是設計壓力測試場景。好的場景設計應盡可能接近真實應用負載，才能充分暴露系統性能瓶頸點，提高測試效率。要做到這一點，項目實施人員需充分認識影響Web系統性能的主要因素，依據業務邏輯設定實際、合理的測試參數。結合高效的測試工具，在測試中密切關注衡量Web系統性能的重要指標，不斷修正測試場景，實踐一個與系統真實應用負載逐漸擬合的過程。

3 項目實踐案例

作者作為項目負責人，于前期完成了一次Web應用系統建設工作。該項目為全市各商業銀行基層網點提供某人民幣對公業務網上辦理服務。系統使用標準J2EE三層架構設計，為減輕商業銀行負擔，采取純B/S架構，不在各商業銀行架設前置機服務器，全市2000余家基層網點均采取直連方式（一點接入）訪問中心服務器。在上線前測試階段，為解決系統出現的性能問題，作者帶領項目開發人員組織了多輪壓力測試。壓力測試工作依據如下步驟開展：

第一步，排除系統外圍因素。網絡因素是Web系統自身之外的性能影響因素，但是當出現性能問題時，必須對其影響程度做到心中有數。在不對應用系統做任何調整的情況下，單純加大并發壓力便有了收獲，在此環節找到了一個服務器區接入層交換機品牌型號兼容性導致的性能問題。

第二步，合理設計測試場景，利用壓力測試定位系統性能瓶頸。經與業務需求部門充分交流，作者很快就掌握了該系統的業務訪問特點：在每日下午特定訪問時段，用戶的高頻訪問全部集中在幾個關鍵頁面上。當此“尖峰時刻”到來時，大部分在線用戶的行為是在對當日的交易結果進行確認，同時還有相當一部分用戶在利用系統日切前的最后機會對交易數據進行補錄。系統響應時間隨著用戶并發量和“尖峰時刻”的臨近逐漸增大，性能拐點明顯。在性能下降到一定程度后，新用戶甚至已經無法登陸系統，在線用戶交易請求開始出現大量失敗。

根據“場景設計應盡可能接近真實應用負載”的原則，作者在此項目壓力測試方案設計中重點考量了用戶行為、數據量鋪墊以及并發數等幾個因素。業務部門提供的需求數據，是數據量鋪墊和并發數估算的原始基礎；為達到盡可能接近真實的目標，作者對前期全市聯調階段系統后臺記錄的日志展開深入分析，統計出系統高峰訪問時段用戶增、刪、改、查等具體行為的分布比例，并根據商業銀行接入數量、線路帶寬等因素進行相應調整，修正場景設計中用戶行為的權重。之后利用企業級Loadrunner測試工具，反復錄制調試測試腳本。同時采取對應用服務器與數據庫服務器分離部署的方法，在壓力測試中分別監測操作系統、數據庫、應用各部分對應性能指標。

通過幾輪壓力測試，項目組很快就定位到了影響系統性能的關鍵問題，并提交開發人員進行對應處置。在應用層面，局部針對性修改代碼，對高頻訪問頁面涉及到的數據庫基礎表做全局內存靜態化處理，優化高耗能SQL語句；數據庫層面，對涉及復雜查詢的業務表進行分表處理，實現當前熱數據與歷史冷數據的合理隔離；在系統整體集成層面，對操作系統、數據庫及應用中間件分別進行參數調優。

通過上述努力，經壓力測試優化后的系統再次提交測試，整體性能有了顯著提升，“尖峰時刻”的性能拐點已經完全消失，無論從系統的響應時間還是吞吐率指標看，均達到了預期建設目標，并且完全能夠支撐未來五年業務發展的性能預留空間。目前系統已投產上線，運行平穩，為全市金融服務水平提升起到了重要推動作用。

4 結束語

性能是信息系統建設和運維中永恒的話題。做好Web系統壓力測試，第一要務是在排除外部干擾因素，充分了解業務邏輯的基礎上，設計出盡可能接近真實應用負載的測試場景。

要達成這一目標，最重要的是對用戶并發數、鋪墊數據量以及用戶行為的把握，并借助有效的工具軟件進行迭代驗證。實踐經驗證明，高質量的壓力測試是系統項目建設中進度與質量的重要保證。