1 【引題】
但凡寫過技術方案的都知道，在技術方案最終落實到工程實施部署時，必須編制出當前解決方案需要部署的IT設備及環境，包括：需要的網絡環境、端口、帶寬、組網方式、網絡安全保障措施；需配置的服務器設備性能、數量；需配置的存儲數據存儲設備、容量、存儲速率；甚至還需考慮整個系統的備份設備容量、備份I/O數、速率、備份策略等。
嚴格說來，無論是系統廠商、集成公司、還是研究院、設計公司，在最終提供方案的硬件配置時，都應該以業務需求為依據、適當考慮客戶業務的發展趨勢和系統冗余，詳細估算：當前業務需求對網絡帶寬、對處理能力、對數據存儲容量的指標。因此，本文以自己的項目案例和經驗為基礎，簡述計算機處理能力如何正確估算，供大家參考。
2 【性能評測標准】
眾所周知，事務處理性能委員會的TPC-C標准，是測算和衡量計算機硬件設備性能的行業標准。隨着B/S技術架構的大行其道，SPEC組織專門推出了針對Web服務器響應客戶端Web訪問請求的性能測算標准，即SPEC web系列。因此，如果是傳統的基於事務處理模式的服務器，仍采用TPC-C的方式進行測算；如果是Web服務器，則需要采用SPEC web系列的標准進行測算。然而，很遺憾的看到，很多人在測算服務器性能時完全忽視這兩種差別。
1.1 TPC-C標准
TPC-C基准是事務處理委員會建立的一個專門演示在線事務處理性能（OLTP）的性能基准，它的測量方法是為了使客戶能夠評估不同的在線事務處理系統的性能，這些事務進程於一個可控制的狀態下在一個標准的數據庫中運行。
TPC-C的事務處理是在一個9個表的數據庫上實現的事務處理過程包括：更新、插入、刪除、終止，以及對主和次級鍵的訪問，每種事務處理95%的響應時間應小於或等於5秒，其中，庫存水平的響應時間可以在60秒以內。TPC-C值表示每分鍾處理的標准事務量，單位是tpmC。
1.2 SPEC web標准
SPEC web99，WEB 服務器可以支持的並發接入數。SPECweb99 檢測程序模擬客戶通過慢Internet 連接，向Web 服務器發送HTTP 工作量請求。
SPEC Web2005，作為SPECweb99的繼承者，SPECweb2005延續了SPEC的傳統測試的原理，通過多台客戶機向服務器發出Http Get請求，請求調用Web服務器上的網頁文件，這些文件從數千字節到數兆字節不等。在相同的時間里，服務器回答的請求越多，就表明服務器對客戶端的處理能力越強，系統的Web性能就越好。
3 【性能估算公式】
3.1 常見的錯誤估算方法
在技術方案評審和招投標評標過程中，我常常看到這樣的評估服務器處理能力的表格：
示例一：
示例二：
不知道這種評估方法是從那里開始的，在技術方案文檔中，曾多次看到這樣的評估模型和表格。即不全是TPC-C的評估方法，又不全是SPEC Web體系的評估方法。
3.2 TPC-C估算公式
TPC-C是用計算機設備在每分鍾內所能處理的標准事務的數量來衡量其處理能力的多少；因此，估算一個應用場景對處理能力的需求，本質上就是估算出每類業務處理事務對應的標准tpc-c事務量，然后在適當考慮冗余量。TPC-C的測算結果是每分鍾的事務數，單位是tpmc。
TPC-C的通用估算公式如下：
TPC-C = ∑(每分鍾業務事務量 * 標准事務量比率)/ (1 — 冗余率)。
例如：某業務系統有2類業務處理事務操作，業務事務1每分鍾30000個，每個業務事務1操作相當於0.5個標准tpc-c事務；務事務2每分鍾20000個，每個業務事務2操作相當於2個標准tpc-c事務；考慮30%的系統冗余。則該業務應用需要的處理能力為：
服務器處理能力(tpmc) = ((30000 X0.5) + (20000 X 2)) / (1 – 30%) = 78581。
3.3 SPEC Web估算公式
SPEC Web2005標准的衡量結果是一台Web服務器能夠有效響應客戶端的Web請求的最大極限個數。因此，測算的結果應該是一個Web請求數字，單位是個。
在評估應用服務器的SPEC Web2005值時，通常的方法是通過系統的在線用戶，結合其在線率估算出並發用戶數，在參照日常業務使用場景中可能發起的http請求來進行估算。
SPEC Web2005的參考估算公式如下：(注意：公式僅供參考，需根據項目的具體情況自行設計估算模型)
Web訪問響應能力(SPEC Web2005) = (在線用戶數 * 在線率 * 在線用戶平均發起http請求數)/ (1 — 冗余率)。
例如：某業務系統的在線用戶數為2000，在線率10%，每在線用戶平均發起的http請求數為3，考慮30%的系統響應能力冗余。則負責該業務請求的Web服務器的響應能力為：
Web訪問響應能力(個) = 2000 * 10% * 3 / (1 – 30%) = 857。
4 【應用實例】
下面以一個實際工程項目的應用服務器(部署Web Service中間件)的性能估算為例進行示范。
應用服務器上運行中間件產品，承擔系統的各類業務邏輯組件運行計算，收斂系統用戶對數據庫服務器的訪問請求，集中對外提供應用服務。通過分析，應用服務器性能需求在於：提供Web應用服務、業務邏輯處理。
Web應用服務方面，根據的業務預測數據，應用服務器平均在線並發用戶按200估算，並發在線率20%，每用戶平均發起3個http鏈接，考慮30%系統響應冗余能力，參照SPECweb99的評測標准，Web應用服務性能需求：Web服務器最大並發連接數=(120×20%×3)/(1 - 30%)= 103。
業務邏輯處理性能方面，主要的應用服務組件性能需求在於：集團數據監測分析、省數據監測分析、業務數據查詢。據調研統計，集團數據為每分鍾3585 條，省數據平均為每分鍾51667條，業務信息查詢請求平均為每分鍾2151次；集團數據監測分析，每次業務操作約需3個標准tpcc事務，省數據監測分析，每次業務操作約需2個tpcc事務，業務信息查詢，每次業務操作約需2個tpcc事務；則系統主機的處理能力需求TPCC值計算如下：
因此，應用服務器的處理能力配置不能低於196731tpmc，其Web2005配置指標不能低於103個。
5 【經驗總結】
針對事務處理型應用場景，需要采用TPC-C的估算方法，估算出具體需要的總tpmc值；而針對Web客戶端請求響應型應用場景，除了估算其業務處理能力之外，還需要評估其對客戶端Web請求的響應能力，實際配置的服務器一般不能低於估算結果。
除了考慮存業務處理需要的處理能力需求外，還需要考慮設備運行環境上其他基礎服務運行開銷：例如操作系統、數據庫服務器、Web服務器、應用中間件等。
由於當期硬件設備發展非常迅速，一般標配的PC服務器的tpcc值也常常是幾十萬，高配的甚至上百萬。因此，還有兩條經驗提醒大家注意：
其一，如果業務需求的tpcc值測算出來其實很低(絕大部分應用都是如此)，配置一台很低端的PC服務器都能夠滿足處理能力需求，不能因為想給客戶提供高配置的設備，而胡亂的編纂tpcc值；而應該從其他方面尋找更加充分有力的理由。
其二、由於PC服務器處理能力的增強，tpcc值往往不再成為必須選擇小型機的一個比較充分的理由；但需要給客戶報配小型機方案時，可以嘗試從穩定性、可靠性、高I/O需求、設備同構需求、外圍設備特殊要求等方面多想辦法，而不能再一味只從tpcc值這個角度去考慮。