大型票務系統性能測試淺析
其中，優化項所有內容必須滿足，附加項可以不滿足，在評測結果中Y代表滿足、N代表不滿足、Null代表無優化項相關技術。評測結果共分為A、B、C、D、E和U六個級別。具體對應關系如下表所示：
表2 評級標準
4.2 后端性能測試方法
測試主要采用商業級別的性能測試工具進行測試，如HP Loadrunner。通過大規模模擬實際用戶的操作行為，測試核心售票系統中注冊、瀏覽、座位選擇、支付等關鍵業務的響應時間和服務器實時處理能力，重點關注CPU、內存、I/O等信息，為操作系統、中間件和數據庫以及服務器的性能優化和調整提供數據依據。
通常情況下，數據中心中用于支撐售票業務的服務器多達幾百臺，通過軟件在測試中進行監控更容易實現，如UC Berkeley的開源集群監視軟件Ganglia。Ganglia的核心包含gmond、gmetad以及一個Web前端，通過自動解析linux操作系統proc目錄下的文件來獲取操作系統的主要性能指標。Ganglia帶來的系統負載非常少，幾乎不會影響被監控系統性能。對于中間件和數據庫等基礎軟件，可采用其自帶的監視器或命令來獲取性能指標。
在測試場景設計中，應考慮準確模擬混合業務的并發操作，以及過載訪問的情況，可借鑒下表中的思路進行測試：
表3后端性能測試場景
通過測試考察運行環境的抗壓能力，在成本和風險可接受范圍內對整個運行環境進行合理優化，提高核心售票系統的處理能力。總的來說，高效的核心售票系統在上線前達到以下要求：
A、核心業務模塊中無明顯效率低下的模塊
B、多個數據中心間實現了良好的負載均衡，整個運行環境中不存在明顯的服務器資源消耗過度的情況
C、整個運行環境的網絡承受負載的能力良好，各銀行支付網點進行了合理的組網規劃，網站與支付系統的流量實現良好分離
D、在正常和過載情況下，系統的定單數量/小時指標在合理范圍內，代理服務器、交易服務器以及數據庫服務器的資源消耗合理
5、總結
通過分析大型票務系統的訪問特點和規律，提出了大型票務系統的性能測試策略和方法，該方法經具備普遍的合理性和較強的操作性，但是該方法還有待在更多大型票務系統性能測試中進行應用和完善。
1、引言
隨著互聯網的普及，越來越多的傳統業務轉移到了網絡進行。但是由于大型票務系統受眾訪問高峰、持續性等特殊性，使得傳統的性能測試策略并不適合該類系統的測試。例如北京奧運會票務系統和倫敦奧運會票務系統的在運營階段不斷的癱瘓、修復、上線運營的循環中，大型票務系統的性能測試顯得尤為重要。
2、關鍵技術
2.1 Web應用響應時間
其中C1是用戶發請求前在客戶端完成預處理階段；C2是客戶端接收到服務器返響應后，對處理結果展現的階段；A1是WEB Server或者APP Server對請求進行處理階段；A2是數據庫服務器對請求進行處理階段；A3是WEB Server或者APP Server對DB Server 返回結果進行處理的階段；N1是請求由客戶端發出并達到Web/App Server 的階段；N2是如果需要進行數據庫相關的操作，由Web/App Server 將請求發送至DB Server 階段；N3是DB Server 完成處理并將結果返回Web/App Server 階段；N4是Web/App Server 完成處理并將結果返回給客戶端階段。
從用戶的角度來看，響應時間＝（C1+C2）+（A1+A2+A3）+（N1+N2+N3+N4）；但是從系統的角度來看，響應時間只包括（A1+A2+A3）+（N1+N2+N3+N4）。
2.2 前端性能
所謂前端是相對于后端而言的，后端是用戶分析用戶請求、執行數據查詢并對結果進行組織，形成瀏覽器可以完全呈現的內容；前端是負責將后端生成的內容通過網絡發送給客戶段瀏覽器，展現后端請求處理結果的。前端開發技術主要有（X）HTML/CSS/JavaScript/DOM/Flash等各種Web技術。前端性能主要是在客戶端通過瀏覽器發送了一個請求，除去后端處理消耗的時間的瀏覽器展示后端訪問請求的時間。也就是圖1中C1+C2+N1+N2階段，其中主要衡量接受到的數據的大小、接受響應數據的碎片程度等方面。
在交互式應用中，響應時間大于15秒，對于大多數人是無法容忍的，相應時間大于4秒時，人的短期記憶會受到影響，工作的連續性就會被破壞。對于一個用戶的每次訪問來說，80%的響應時間消耗在了前端。而且對于提升網站的訪問速度而言，如果通過后端優化將響應速度提升一賠，那么整體的響應時間僅僅只能減少5%到10%；而如果通過優化前端將響應時間減少一半，則整體響應時間至少減少40%到45%。
2.3 后端性能
后端性能是指web Server或者APP Server在收到客戶端響應后，對其進行處理，通過數據庫數據返回結果，經過處理將返回響應發送給客戶端的過程。也就是圖1中邏輯業務流經過A1、A2、A3、N2、N3的過程中對各個階段的響應時間、服務器資源利用率、網絡負載等方面的衡量。
性能度量就是通過定義一系列可以反映程序性能的指標，并從程序實際運行的數據中獲得度量結果的過程。性能度量的結果可以用于評估系統的性能好壞、分析性能瓶頸和改進系統性能等。針對Web應用性能，有兩種常用度量指標：度量資源使用情況，度量響應時間。
3、大型票務系統性能評價方法
3.1 前段性能評價方法
對于大型票務系統而言，前端性能的優化主要是為了加快響應結果在客戶端的響應速度，這樣能夠避免用戶誤以為無響應而反復的刷新造成服務器端壓力。在評測過程中主要從如下幾個方面進行考慮：
A、CSS文件或者代碼至于頂部
B、JavaScript腳本文件或者代碼至于文件的底部
C、CSS文件或者代碼中無CSS表達式
D、JavaScript腳本文件或者代碼中無重復腳本
E、移除無用的CSS
F、對JavaScript腳本進行了精簡
G、精簡CSS腳本
H、外鏈JavaScript腳本并且合并多個javascript腳本文件
I、外鏈CSS并且合并多個CSS文件
J、應用圖片地圖或者CSS Sprites
K、應用Expires頭
L、無重定向
M、應用GZip壓縮
N、配置ETag
在上述的評測內容中主要包括了兩方面，其一是腳本文件的優化，資源文件的優化和CSS文件的優化三大方面。服務器文件優化就是降低在客戶端訪問服務器端時，除去HTML文檔外其他所有內容的物理大小，減小傳輸時間和加載時間。其二是依據HTTP協議特性，通過配置中間件、修改源程序等操作進行的優化。在完成上述14項技術評價指標后，仍有如下4項附加項需要考慮：
O、應用Ajax緩存
P、應用CDN
Q、混淆JavaScript
R、頁面DNS查找最小化
由于上述四項附加是由相對復雜，風險較大、實現成本較高技術決定的，因此附加項的滿足條件就視項目的投入成本情況而定，并不一定要完全滿足。
3.2 后端性能評價方法
由于票務系統通常在短時間內進行集中售票，存在短時間內訪問量陡增、售票期間持續高壓力以及與銀行支付業務緊密相關等特點，因此保證大壓力下的核心售票系統能夠提供高性能的服務水平，將直接影響終端用戶的購票體驗。糟糕的用戶體驗包括：
A、超長的等待時間
B、頁面無響應
C、支付失敗
從性能測試角度看，整個運行環境在承受來自世界各地高強度的并發訪問過程中，可能存在以下問題：
A、網絡擁塞導致頁面請求響應緩慢或超時報錯
B、頁面刷新機制導致在用戶鎖票、坐席分配以及支付階段時，用戶等待時間增長，訂單處理速度急劇下降
C、大量的金額統計以及票務更新導致交易服務器和后臺數據庫繁忙
D、大量的VISA卡支付操作導致支付網點服務器繁忙，處理效率底下
為準確模擬實際情況，需將歷史經驗同本次售票方案相結合，預計并發訪問人數、網點規模、數據規模等指標，在保證數據中心實現良好數據共享的情況下，測試的重點應涉及一下幾個方面：
A、網絡負載
B、多個數據中心間的負載均衡
C、峰值期間每小時定單數量
D、代理服務器、交易服務器、數據庫服務器的資源消耗情況
E、長時間高效服務的能力
4、大型票務系統性能測試方法
4.1 前段性能測試方法
前端性能主要的評測工具有Google的Page Speed和Yahoo的YSlow。Google開發團隊針對SteveSounder網頁性能最優方法，成功地推出一款基于Firefox/Firebug的開發類插件Page Speed，旨在幫助開發人員分析網站性能存在的主要問題，并有針對性地提出優化改進意見。它支持的操作系統為Linux、Mac、Windows。在此之前， Google內部已經廣泛使用PageSpeed優化網頁前端性能。YSlow是有雅虎公司開發的免費前端性能檢測工具。YSlow通過檢測網頁上的所有組件，包括JavaScript動態創建的組件，分析網頁的前端性能。同時，YSlow依據前端性能的分析結果提出改進建議。
在應用上述兩款任意一款給你工具進行測試后，將測試結果對應的填入下面的前段性能評測記錄表中。
表1 前段性能評測記錄表
其中，優化項所有內容必須滿足，附加項可以不滿足，在評測結果中Y代表滿足、N代表不滿足、Null代表無優化項相關技術。評測結果共分為A、B、C、D、E和U六個級別。具體對應關系如下表所示：
表2 評級標準
4.2 后端性能測試方法
測試主要采用商業級別的性能測試工具進行測試，如HP Loadrunner。通過大規模模擬實際用戶的操作行為，測試核心售票系統中注冊、瀏覽、座位選擇、支付等關鍵業務的響應時間和服務器實時處理能力，重點關注CPU、內存、I/O等信息，為操作系統、中間件和數據庫以及服務器的性能優化和調整提供數據依據。
通常情況下，數據中心中用于支撐售票業務的服務器多達幾百臺，通過軟件在測試中進行監控更容易實現，如UC Berkeley的開源集群監視軟件Ganglia。Ganglia的核心包含gmond、gmetad以及一個Web前端，通過自動解析linux操作系統proc目錄下的文件來獲取操作系統的主要性能指標。Ganglia帶來的系統負載非常少，幾乎不會影響被監控系統性能。對于中間件和數據庫等基礎軟件，可采用其自帶的監視器或命令來獲取性能指標。
在測試場景設計中，應考慮準確模擬混合業務的并發操作，以及過載訪問的情況，可借鑒下表中的思路進行測試：
表3后端性能測試場景
通過測試考察運行環境的抗壓能力，在成本和風險可接受范圍內對整個運行環境進行合理優化，提高核心售票系統的處理能力。總的來說，高效的核心售票系統在上線前達到以下要求：
A、核心業務模塊中無明顯效率低下的模塊
B、多個數據中心間實現了良好的負載均衡，整個運行環境中不存在明顯的服務器資源消耗過度的情況
C、整個運行環境的網絡承受負載的能力良好，各銀行支付網點進行了合理的組網規劃，網站與支付系統的流量實現良好分離
D、在正常和過載情況下，系統的定單數量/小時指標在合理范圍內，代理服務器、交易服務器以及數據庫服務器的資源消耗合理
5、總結
通過分析大型票務系統的訪問特點和規律，提出了大型票務系統的性能測試策略和方法，該方法經具備普遍的合理性和較強的操作性，但是該方法還有待在更多大型票務系統性能測試中進行應用和完善