摘  要： 闡述了一種基于應用性能表現的通用基礎軟件選型的方法。介紹了基于應用系統性能為基準，對數據庫和應用中間件進行選型比對。
關鍵詞： 應用系統；數據庫；應用中間件；選型

　傳統的數據庫選型和應用中間件選型測試通常是基于Benchmark的一些基準測試工具。這些測試工具集通常都是第三方非盈利組織提供的，目前常用的基準測試工具集有TPC[1]、SPEC[2]、LINKPACK、EISPACK、LAPACK、NPB、HPCC、IOzone、LMbench等。
　TPC和SPEC是數據庫和應用中間件最常用的測試基準工具，而其中的TPC-C[3]和SPECjserver2004[4]通常被選擇用于數據庫和Java應用服務器的性能基準測試工具，這兩個基準測試結果在國際上也有很好的認同。這些結果能客觀反映數據庫和應用中間件本身的性能情況。
　但是上述基準測試都是基于仿真業務，對于某個特定的應用系統，基準結果往往和在特定應用系統中的表現有很大差異。所以本文探求一種基于真實業務應用系統的業務模型作為基準，對不同數據庫和應用中間件進行選型測試，通過其在真實業務應用系統的表現更客觀地反映針對該特定應用系統、數據庫和應用中間件達到的最佳能效比。
1 傳統Benchmark測試的問題
　傳統的基于第三方非盈利機構的Benchmark測試工具集測試是基于一個模擬的業務模型進行測試。以最常見的TPC-C測試為例，關于TPC-C的基準規范業務模式，此規范描述的是一個大型的商品批發銷售公司，它擁有若干個分布在不同區域的商品倉庫。當業務擴展的時候，公司將添加新的倉庫。每個倉庫負責為10個銷售點供貨，其中每個銷售點為3 000個客戶提供服務。每個客戶提交的訂單中，平均每個訂單有10項產品，所有訂單中約1%的產品在其直接所屬的倉庫中沒有存貨，必須由其他區域的倉庫來供貨。同時，每個倉庫都要維護公司銷售的100 000種商品的庫存記錄。但是對于這個基準，TPC不給出基準程序的代碼，只給出基準程序的標準規范。即允許任何廠家或其他測試者構造出符合自己硬件或者軟件環境的被測應用，這個被測試的應用只要符合這個規范就可以。
　TPC-C測試的結果主要有兩個指標，即流量指標（Throughput，簡稱tpmC）和性價比（Price/Performance，簡稱Price/tpmC）。流量指標值越大，說明系統的聯機事務處理能力越高。性價比測試系統的整體價格與流量指標的比值，在獲得相同的tpmC值的情況下，價格越低越好。
　TPC-C的指標僅表明當前被測試環境作為一個有機整體，處理符合TPC-C規范、模擬OLTP的商品批發銷售公司應用的性能情況。不能離開這個整體去判讀TPC-C數據。這個有機整體包含硬件系統，如主機設備、網絡設備、存儲設備；軟件系統如數據庫、應用軟件、廠商自己開發的TPC-C模型；以及技術支持服務，如架構設計優化、程序優化、參數優化等。
　用戶實際的應用系統通常與軟件廠商測試時的TPCC模型有差異（如業務邏輯、使用習慣、數據量等等方面）。所以客戶應用系統的性能即使部署在廠商當時測試TPCC應用的環境上，TPPC值也會有差異的。
因此僅靠TPCC值進行軟件選型是不充分、不全面的。
2 基于真實應用系統的選型測試
　傳統基于Benchmark測試結果的選型測試，由于測試模型和真實業務有區別，選型測試的結果往往不能保證所選數據庫或者中間件的表現與測試結果相符。業務模型的差異因子是結果偏差的主要影響因子。區別于傳統的Benchmark測試，基于真實應用系統的選型測試模型是真實的業務模型，從業務模型的真實性上避免了業務模型差異產生的比對選型誤差。該方法的思想是在相同的測試基準下，針對相同的業務應用模型，進行相同測試的性能測試，通過時間特性和資源利用性兩個方面進行選型評價。
3 選型測試案例說明
　通過一個實際的業務系統選型測試，介紹了基于應用性能表現進行通用基礎軟件選型的實踐。選型委托方是某機構的核心業務軟件，該系統完全基于J2EE規范開發的B/S架構的應用系統，數據庫符合美國國家標準學會（ANSI）SQL 2003的關系型數據庫。根據上述基本要求，本次選型測試涉及5個中間件和4種數據庫。選型組合矩陣關系如表1所示。

　根據上述組合，分別采用相同的性能測試腳本進行相同場景設置的綜合場景測試，測試點包含了系統的4個典型操作功能點，場景持續運行時間為2 h。為嚴格保證測試的基準一致性，確保測試相對公平公正，基準一致性應包含5個部分內容要求：
　（1）操作系統基準一致性要求：數據庫服務器操作系統為AIX 5.3.0.8，應用數據庫服務器操作系統為Redhat AS 5.4 64 bit kernel2.6.1.8_164.el5，負載均衡服務器操作系統為Redhat AS 5.4 64 bit kernel2.6.1.8_164.el5；
　（2）其他相關軟件版本一致；
　（3）硬件環境一致；
　（4）測試策略與測試壓力的一致性：測試中執行相同的測試策略，對腳本和場景運行的設置保持一致；
　（5）數據一致性要求：測試環境的數據容量保持一致，數據庫的數據記錄數量和數據內容保持一致。
3.1 效率評價模型說明
　以貼近系統實際使用情況為選擇依據，本次測試的綜合場景測試最貼近用戶的真實使用情況。所以本評價模型的數據基礎來源于綜合場景測試的測試結果數據。評價模型包括時間特性和資源利用性，具體計算權值可以根據業務需要進行相應調整，本次評價權值僅供參考。評價模型說明如圖1所示，評分說明如表2所示。

　（1）效率評價總得分＝時間特性總得分×0.6＋資料利用性得分×0.4
　（2）時間特性總體得分計算說明：
時間特性得分＝（功能點1×0.125＋功能點2×0.125＋功能點3×0.125＋功能點4×0.125）＋總體吞吐量得分×0.5
　（3）資源利用性得分計算說明：
　資源利用性得分＝（數據庫CPU占用得分＋應用服務器CPU占用得分）/2
3.2 選型評價結果
　根據8個環境測試的詳細結果，依據上述評價模型和評分說明進行總體的選型評價，得分如圖2所示。

　依據上述評價結果，編號4、5、6、7的得分高于95分，可以結合采購成本綜合考慮最終的軟件選型。
本文介紹了一種基于應用性能表現的通用基礎軟件選型方法，此方法基于真實的業務應用模型，采用相同的測試約束和統一的評價模型，相對于傳統基于基準測試工具進行選型更具有針對性，是對選型測試的一種方法補充。
參考文獻
[1] TPC Benchmark Testing[EB/OL]. [2012-12-10]. http：//www.tpc.org/information/benchmarks.asp.
[2] SPEC Standard Performance Evaluation[EB/OL]. [2012-12-10]. http：//www.spec.org.
[3] TPC-C Benchmark Testing[EB/OL]. [2012-12-20].http：//www.tpc.org/tpcc.
[4] SPECjAppServer2004[EB/OL]. [2012-12-20].http：//www.spec.org/jAppServer2004.