原文：https://blog.csdn.net/duheaven/article/details/17252401
應用服務器配置測算及計算公式
1 術語和定義
1.1 信息系統
由計算機、通信設備、處理設備、控制設備及其相關的配套設施構成，按照一定的應用目的和規則，對信息進行採集、加工、存儲、傳輸、檢索等處理的人機系統。
1.2 軟硬件平臺
指信息系統運行的環境，主要包括硬件（服務器、存儲）和軟件（操作系統、數據庫和中間件）部分。
1.3 非安全區
即Internet，此區域允許外網用戶隨意訪問。
1.4 安全區
內網，此區域通常不對外提供服務。
1.5 DMZ區（Demilitarized Zone）
又稱非軍事區，介於非安全區與安全區之間，此區域按需對外網用戶提供部分服務。
1.6 FC SAN（Fiber ChannelStorage Area Network）
指採用光纖通道的存儲區域網絡，是一種將存儲設備、連接設備和服務器集成在一個高速網絡中的技術，SAN作爲存儲網絡，與LAN網絡隔離，主要承擔數據存儲任務。
1.7 FC Switch（Fibre Channel Switch）
指光纖通道交換機，是一種高速的網絡傳輸中繼設備，以光纖作爲傳輸介質，是組成FC SAN光纖存儲網絡的光纖交換機。
1.8 HBA（Host Bus Adapter）
指主機總線適配器，是一個使計算機和存儲設備間提供輸入/輸出處理和物理連接的電路板和/或集成電路適配器。
1.9 磁盤陣列（Redundant Arrays of Inexpensive Disks，簡稱Raid）
由多個容量較小、速度較慢的磁盤組合成一個磁盤組，以提升整體性能和存儲空間。
1.10 虛擬機
指使用系統虛擬化技術，運行在一個隔離環境中、具有完整硬件功能的邏輯計算機系統。
1.11 負載均衡
分爲硬件和軟件負載均衡，軟件負載均衡指通過將負載均衡軟件安裝在一臺或多臺服務器相應的操作系統上來實現負載均衡，硬件負載均衡是直接將負載均衡設備部署在服務器和外部網絡之間，專門完成負載均衡任務。
1.12 關鍵應用系統
指對業務開展起核心的支撐作用的,對可靠性（Reliability）、可用性（Availability）和可服務性(Serviceability)等具有非常高要求的應用系統，如資產管理系統、營銷管理系統、財務管理系統、人力資源系統、協同辦公系統和綜合管理系統。
1.13 非關鍵應用系統
指除關鍵應用系統外的應用系統。
1.14 TPC-C測試
指模擬一個批發商的訂單管理系統進行數據庫事務處理測試,主要衡量服務器及數據庫軟件處理在線查詢交易處理（OLTP）的性能表現，正規 TPC-C 測試結果發佈必須提供 tpmC值, 即每分鐘完成多少筆 TPC-C (TPC-C Transaction Per Minute)數據庫交易。
1.15 SPECweb2005
SPEC Web2005延續了SPEC傳統測試的原理，通過多臺客戶機向服務器發出Http Get請求，請求調用Web服務器上的網頁文件，這些文件從數千字節到數兆字節不等。在相同的時間裏，服務器回答的請求越多，就表明服務器對客戶端的處理能力越強，系統的Web性能就越好。
1.16 業務交易
在TPC-C估算法中，業務交易指的是用戶的業務請求，用戶每次查詢、修改和刪除操作均各算一次業務交易。
1.17 數據分級存儲
數據分級存儲是指將數據存放在不同級別的存儲設備（磁盤、磁盤陣列、光盤庫、磁帶庫）中，通過數據分級存儲管理軟件實現數據在存儲設備之間的自動遷移。
2 基本原則
架構一致性原則。
安全性原則。
可靠性原則。
可擴展性原則。
綠色低碳原則。
3 軟硬件平臺架構
網絡從安全角度上分，一般分爲DMZ區和安全區（內網），根據應用的用途、架構、功能，選擇適合的網絡環境。
DMZ區和安全區（內網）內各信息系統應按照相關信息安全等級保護的要求，依據分區、分級、分域的的原則，進行安全域的劃分，實現各安全域差異化的信息安全防護。
軟件架構方面，對維護簡單、不需要更新客戶端的應用系統，建議採用Browser/Server（B/S）架構，對響應時間要求快、客戶端操作界面複雜和有較多個性化要求的應用系統，可採用Client/Server（C/S）架構。
對性能要求不高的B/S架構應用系統，可採用Web客戶端/應用服務器/數據庫服務器三層架構；對性能要求高的B/S架構應用系統，應採用Web客戶端/Web服務器/應用服務器/數據庫服務器四層架構，Web服務器用於專門處理HTTP請求(request)，應用服務器通過多種協議爲應用系統提供處理商業邏輯(business logic)。
4 存儲設備
存儲設備包括本地物理服務器（或者虛擬機）的存儲設備和共享存儲設備。對於共享存儲設備，結構化數據建議採用支持FC SAN 或高帶寬、低延遲的InfiniBand 網絡的磁盤陣列，非結構化數據可以採用高性價比的NAS 作爲存儲設備。
存儲網絡交換機可選擇FC SAN 交換機或InfiniBand 交換機，交換機應實現2N方式的冗餘；存儲網絡交換機應支持Trunk級聯，以便實現多套存儲設備的共享。
存儲設備的選擇主要考慮性能、管理複雜程度與可擴展性，應支持存儲虛擬化技術，以提高存儲資源的利用率，降低管理複雜度和成本，支持開放結構，可方便的被其他廠商的系統管理軟件使用，支持動態可擴展，無須終止應用程序即可擴展存儲空間。
建議在DMZ區和安全區（內網）各配置一套共享存儲設備，以滿足不同信息系統對存儲設備的需求。
對可用性要求高、數據讀取速度快、存儲空間需求大、在線可擴展等應用系統，原則上應使用共享存儲設備；數據庫服務器及虛擬化的物理服務器應通過存儲網絡和共享存儲設備相連。
對於關鍵應用系統，建議採用數據分級存儲，根據數據的訪問頻率、保留時間、容量、性能要求等因素設置數據遷移規則，將訪問頻率較低的數據存儲在磁帶庫等成本較低、速度較慢的存儲設備中，將訪問頻率較高的數據存儲在磁盤或者磁盤陣列等成本較高、速度較快的存儲設備中。
5 數據庫服務器
關鍵應用系統的Oracle數據庫集羣建議採用多臺小型機，可通過合理密度的虛擬化分區技術將一臺小型機分爲不同分區，建議將不同關鍵應用系統集羣數據庫的節點應安裝在物理服務器的不同分區上，同一應用系統集羣數據庫的不同節點應安裝在不同物理服務器分區上，節點的分佈要結合系統的特點進行錯峯安排。
Oracle數據庫集羣建議採用Real Application Cluster（RAC）的方式構建，可以充分利用RAC提供的負載均衡和實時災難恢復的功能。RAC方式搭建Oracle數據庫集羣對應用系統架構有一定要求，應當注意：
1）通過程序控制各個RAC節點承擔系統中相對獨立的業務邏輯的後臺數據處理，應儘量避免在多個不同節點上存放相同表的數據，以減少各個節點間內存數據通訊。
2）應用程序訪問後臺數據源的鏈接配置設置爲Service方式，將多個數據源指向的數據庫節點配置爲不同的優先順序，例如：3臺數據庫服務器機器爲A、B、C，配置3個數據源，其中數據源1指向的數據庫優先順序爲ABC，數據源2指向的數據庫優先順序爲BCA，數據源3指向的數據庫優先順序爲CAB。
爲滿足某些高負載、大用戶量、數據庫讀寫訪問非常頻繁的應用系統需求，可以考慮通過主從複製、垂直分區、水平分區等技術將數據庫進行結構分解。
1）主從複製：進行讀寫分離，寫操作作用在主數據庫節點上，通過數據庫複製軟件，結合業務數據更新週期利用業務低谷期進行數據同步。
2）垂直分區：將不同類型的數據存儲在不同的數據庫節點中，方便上層業務模塊在部署上的分離。
3）水平分區：將同一個表的數據通過某種算法分佈到不同的數據庫節點上。
6 應用服務器/Web服務器
建議採用微機服務器或刀片服務器作爲應用服務器/Web服務器的物理服務器，通過服務器虛擬化技術，在物理服務器 上創建虛擬機，將不同應用系統的應用服務器/Web服務器安裝在同一臺物理服務器的不同虛擬機上；在部署多節點應用系統時，不同節點應儘量均衡分佈在不同物理服務器上，以保證應用的高可用性。
針對服務器硬件配置要求較低、無特殊硬件（圖像顯示卡、音頻卡、加密卡等）要求和I/O需求不高（IO吞吐率不超過50MB/s）的信息系統建議運行在虛擬機上，以提高資源利用率。
運行虛擬機的服務器應提供主要配件（如電源、硬盤、風扇、內存、網卡）的熱插拔技術。
虛擬機數據應存放在共享存儲設備上，以提高整體系統的可用性和性能。
關鍵應用系統的應用服務器/Web服務器前端應部署硬件負載均衡設備，根據預設的負載均衡策略，將用戶訪問導向負載壓力較小的虛擬機/物理服務器。
使用Weblogic應用服務器組建集羣時，應用系統軟件設計中不能包含文件共享的文件服務和時間服務，可以在集羣中的單個節點使用此類服務，但是不能提供平衡負載或故障轉移功能。
針對Java應用服務器軟件，應當根據應用系統實際情況和硬件服務器配置，調整Java的運行參數，最大程度優化系統的性能，如Java虛擬機堆的大小缺省是256M，建議根據虛擬機/物理服務器的內存大小將Java虛擬機堆進行調整，範圍從512M（當內存大於2GB時）至1024M（內存大於4GB時）之間。
Java應用服務器 Weblogic和Websphere 集羣必須滿足以下條件：集羣中的主機必須使用永久的靜態IP地址，動態IP地址不能用於集羣環境；集羣中的所有服務器必須位於同一個局域網，並且必須是IP廣播可到達的；集羣中的所有服務器必須使用相同的版本，其中Websphere要求所有服務器都採用WSA ND版本；對於使用了JDBC連接的EJB，所有部署了某EJB的服務器必須具有相同的部署與持久化配置，即所有服務器均應有相同的JDBC配置；所有部署了servlet的主機必須維護一組具有相同ACL的servlet。
對於使用Weblogic的應用服務器系統，應避免將管理服務器(admin server)設置在集羣的服務器中。
對web服務器，可採用各種緩存技術提升性能：將訪問頻率高的頁面放到緩存服務器中進行緩存。
7 負載均衡
負載均衡設備主要應用於應用服務器和WEB服務器，關鍵應用系統因對性能要求較高，建議以共享的方式使用硬件負載均衡設備。
使用硬件負載均衡有兩種部署方式：直聯和旁路方式，建議採用旁路方式，將多臺負載均衡設備分別連接到多臺核心交換機，多臺負載均衡設備間互爲備份，不同應用系統的應用服務器/Web服務器集羣共用多臺負載均衡設備。
判斷負載均衡是否採用主要和物理服務器/虛擬機的性能、應用系統所執行事務的複雜性等有關。Weblogic建議每個服務器併發線程數爲（25-50）*CPU核數最優，如果應用系統所需最多的併發數超過（25-50）*CPU核數，建議配置多個服務器組成集羣，使用負載均衡技術，將負載分佈在不同的服務器上
建議將Weblogic或者Websphere的server部署在不同的物理服務器的虛擬機上，組成集羣，以提高系統的可用性、穩定性。
8 資源分配方法
對存儲資源採用分解法估計，對數據庫服務器資源採用TPC-C值估算法，對Web服務器資源採用SPECweb2005估算法，對應用服務器採用SPECjbb2005估算法。
資源分配的基本方法是首先了解信息系統的非功能性需求，初步估計各類型服務器（數據庫服務器、應用服務器、Web服務器、接口服務器和其他服務器）總體資源需求，再根據需求冗餘、安全等方面要求，確定各類型服務器所需物理服務器數量，基本原則如下：
1）單臺服務器能提供足夠處理能力的不再分解爲多臺物理服務器。
2）數據庫服務器採用雙節點冗餘（如Oracle RAC）時，處理容量一般按增長50%計算。
3）應用服務器採用多個邏輯(物理)節點組成集羣時，4個節點以下（含4個）的集羣，總體處理能力一般按各節點處理能力總和的60%計算，4個節點以上的集羣，總體處理能力一般按各節點處理能力總和的50%計算。
4）web服務器採用多個邏輯(物理)節點組成集羣時， 4個節點以下（含4個）的集羣，總體處理能力一般按各節點處理能力總和的70%計算，4個節點以上的集羣，總體處理能力一般按各節點處理能力總和的60%計算。
4.3 本指導意見的資源主要介紹存儲設備、數據庫服務器、應用服務器、Web服務器的資源估算方法，其他類型服務器的資源可參考進行估算。
4.4 在進行實際分配資源時，可根據資源需求的估算進行一定程度上的調整。
9 服務器資源估算方法
9.1.1 方法一：數據庫服務器TPC-C估算法
適用範圍：適用於對數據庫服務器（應用服務器、Web服務器可參考）所需服務器的CPU能力進行估算。根據估算出的TPC-C值選擇合適的服務器和服務器配置。
原理介紹：該估算法是通過計算應用系統峯值每分鐘需要處理的業務交易數，再綜合考慮業務交易的複雜程度、未來業務交易數量的增長和CPU處理餘量等因素，通過公式計算得出一個估算值，以此來評估需要服務器必須達到的TPC-C值。
計算公式：TPC-C值 = ((TASK x 80%) /T) x S x F/C
參數解釋：
TASK：典型工作日平均業務交易總量，指的是應用系統需要處理的用戶業務請求的總和。
TASK x 80%：假設典型工作日80%的業務交易集中在高峯時段。
TASK x 80% / T： 即應用系統峯值每分鐘處理的業務交易數。
T：應用系統典型工作日業務交易峯值（完成80%交易）持續時間，以分鐘爲單位。
S：實際業務交易操作相對於標準TPC-C測試基準環境交易的複雜程度比例。
F：系統未來的業務交易量發展冗餘預留，需要根據應用系統情況估算。
C：服務器CPU利用率估算值。實際應用經驗表明，服務器的CPU利用率高於80%則表明CPU的利用率過高會產生系統瓶頸，而利用率處於75%時，是處於利用率最佳狀態。此值一般設定爲C=75%。
計算步驟：
步驟一：估計應用系統平均典型工作日處理的業務交易總量
可以通過以下方法估算：
1、估算典型工作日平均登錄系統的用戶數。
2、估算平均典型工作日每個用戶執行的業務交易數。例如，如果平均每個用戶執行五次查詢、五次修改和五次保存操作，那麼平均每個用戶執行的事務數爲15次。
3、根據1和2估算出應用系統平均每典型工作日處理的業務交易總量。
步驟二：估算應用系統每日峯值持續時間（單位爲分鐘）
估算應用系統典型工作日峯值持續的時間，指的是應用系統典型工作日每天繁忙的時間。例如，股票交易系統每天的繁忙時間爲上午9：30至 11:30和下午13:00至15:00，那麼它的峯值持續時間爲3+2 = 5 小時=300分鐘。
步驟三：估算應用系統峯值每分鐘需要處理業務交易數
計算應用系統峯值每分鐘需要處理業務交易數時，需要估算典型工作日高峯時間處理的業務交易數佔每天平均處理的業務交易總數的比例。通常按照20-80的原則進行估算，即80%的業務交易在高峯時間進行，20%的在非高峯時間進行。
根據上述步驟，可以算出應用系統峯值每分鐘需要處理業務交易數。
步驟四：估算應用系統事務複雜度
由於實際業務交易的複雜程度與TPC-C標準測試中的業務交易存在較大的差異，應設定一個合理的對應值，根據經驗，簡單事務的S值爲2-5，一般複雜事務爲6-12，較複雜事務爲13-16，高度複雜事務爲17-20。針對數據庫服務器，S值建議設置爲15。
步驟五：估算應用系統未來一段時間後預留量。
如果預計未來用戶數翻番，預留量即爲200%。
步驟六：將以上各參數值代入公式，計算出TPC-C值。
步驟七：根據計算出TPC-C值，選擇等於或者大於TPC-C值的目標服務器。
9.1.2 方法二：未公佈服務器TPC-C值估算法
適用範圍：本方法適用於通過廠商已公佈型號服務器的TPC-C值估算未公佈服務器的TPC-C值。
原理介紹：廠家通常會在www.tpc.org上公佈滿配置的某一型號服務器的TPC-C值，對於非滿配置的服務器需要進行估算，而TPC-C性能指標反映的是服務器的整體性能指標，包括：系統結構、處理器、緩存、內存、I/O等，因此不能簡單從TPC-C值推算出CPU、內存的數值，需要綜合考察設備的整體性能。爲了簡化計算，假設服務器的TPC-C值和CPU數和頻率呈線性關係，因此可以根據滿配置的服務器大概估算出非滿配置的相同型號或同檔次服務器的TPC-C值。
計算公式：
目標配置服務器的TPC-C值 ≈（同型號服務器滿配置的服務器的TPC-C值÷CPU個數÷CPU主頻頻率）* 估算服務器的CPU個數*CPU主頻頻率
計算步驟：
步驟一：獲取滿配置同類型服務器的TPC-C值，可以在www.tpc.org查到最新的某些類型的服務器TPC-C值或者通過廠商獲取該值。
步驟二：將滿配置服務器型號的CPU個數和主頻、目標配置的服務器的CPU個數和主頻等代入公式。
步驟三：通過公式計算目標配置的服務器的TPC-C值。
9.1.3 方法三：Web服務器SPECweb2005估算法
適用範圍：適用於爲支持滿足特定吞吐量和客戶請求響應速率要求的WEB服務器的性能進行估算。
原理介紹：Web服務器通常需要衡量它可以支持滿足特定吞吐量和客戶請求響應速率要求的WEB服務器的最大併發連接數量，而SPECweb2005是由標準性能評估組織（SPEC）專門開發的的Web服務器基準測試。服務器廠商通常會提供每種型號服務器的SPECweb2005值。使用本方法估算不考慮網絡因素，假設客戶端和服務器位於同一局域網中，網絡傳輸時間可以忽略。
計算公式：SPEC Web2005值= (總用戶數 * 在線率 * 在線用戶平均發起http請求數)/ (1 — 冗餘率)
參數解釋：
總用戶數：應用系統總的用戶數。
在線率：應用系統使用高峯時用戶的在線率。
在線用戶平均發起http請求數：平均每個在線用戶發起的http請求數量。
冗餘率：需要預留的冗餘率。
計算步驟：
步驟一：估算系統總的用戶數。
步驟二：估算應用系統使用高峯時用戶的在線率。
步驟三：估算平均每個用戶發起的http請求數量。
步驟四：設置預留的冗餘率。
步驟五：將步驟一、二、三、四的估算值代入公式，計算出SPECweb2005值。
步驟六：根據計算出SPECweb2005值，選擇等於或者大於SPECweb2005值的目標服務器。
9.1.4 方法四：應用服務器SPECjbb2005估算法
使用範圍：適用於估算Java類應用服務器所需達到的服務器性能。
原理解釋：SPECjbb2005是評估服務器端Java性能的SPEC測試工具。SPECjbb2005通過模擬三層C/S系統(主要是中間層)來評估服務器端Java的性能。該測試軟件運行JVM(Java虛擬機)、JIT (Just-In-Time)編譯器、碎片收集、線程以及操作系統的其他任務，它同時也測量CPU、Cache、內存和 SMP的性能。
服務器上運行基於J2EE的中間應用軟件平臺，可以將其應用處理能力量化爲Java處理能力性能值SPECjbb2005，同時充分考慮系統的冗餘處理能力以及系統資源分配情況，即可估算出服務器的處理能力性能值。
公式：SPECjbb2005 =A×B/（1-C-D）
參數解釋：
A：每秒最多需要同時處理的業務交易量。
B：每筆業務交易需消耗的SPECjbb2005峯值，根據經驗，每筆業務交易消耗一般爲200個bops，或根據該筆業務交易的java語句數量進行計算，B=該筆業務交易的java語句數/5。
C：系統的冗餘處理能力。
D：非Java應用所佔用的系統資源百分比。
例如某系統業務交易峯值爲1000筆/秒，系統冗餘處理能力預留30% ，非Java應用所佔用的系統資源百分比爲20%，根據計算公式，服務器SPECjbb2005性能值爲：1000*200/(1-30%-20%)=400,000。
9.1.5 方法五：數據庫服務器內存估算法
適用範圍：適用於估算數據庫服務器（應用服務器、Web服務器可參考）所需的內存。
原理介紹：數據庫服務器相對其他服務器來說，因爲涉及大量的數據處理，需要把數據載入內存，以加快處理速度，所以需要更多的內存。對於內存的估算一般有下述兩種方法，建議採用下述兩種方法分別估算出所需的內存，取其中最大的數值。
計算方法：
方法一：
根據標準化設計，將數據庫內存容量（單位爲G）和CPU的核心的數量的比例按照4:1配置，一個CPU的核心對應4G內存。例如服務器配置兩個4核CPU則建議配置32G內存。
方法二：
原理介紹：數據庫服務器的內存主要包括：操作系統佔用內存、數據庫系統佔用內存、數據庫併發網絡連接佔用內存等。按照經驗，Windows平臺內存佔用率不超過55%、Unix（或Linux）平臺內存佔用率不超過80%時，不會影響系統的性能。
計算公式：
數據庫服務器（Windows平臺）內存 = （操作系統佔用內存+數據庫佔用內存+數據庫併發網絡連接佔用內存+其他軟件佔用內存）/ 55%
數據庫服務器（Unix或Linux平臺）內存 = （操作系統佔用內存+數據庫佔用內存+數據庫併發網絡連接佔用內存+其他軟件佔用內存）/ 60%（前置條件：操作系統佔用內存+數據庫佔用內存+數據庫併發網絡連接佔用內存+其他軟件佔用內存≤4G）
數據庫服務器（Unix或Linux平臺）內存 = （操作系統佔用內存+數據庫佔用內存+數據庫併發網絡連接佔用內存+其他軟件佔用內存）/ 80%（前置條件：操作系統佔用內存+數據庫佔用內存+數據庫併發網絡連接佔用內存+其他軟件佔用內存>4G）
參數解釋：
操作系統佔用內存：操作系統運行需要佔用的內存。
數據庫佔用內存：數據庫服務器運行需要佔用的內存。
數據庫併發網絡連接佔用內存：數據庫客戶端和數據庫服務器之間連接時，數據庫服務器需要花費的內存。
其他軟件佔用內存：數據庫服務器中其他軟件運行需要佔用的內存。
計算步驟：
步驟一：估算操作系統所佔用內存
操作系統所佔用內存具體和操作系統類型和版本相關，一般爲600M內存。
步驟二：估算數據庫系統佔用內存
數據庫系統佔用內存主要包括：數據庫服務器軟件佔用的內存和數據庫緩存。其中數據庫緩存和數據庫大小相關，根據經驗，數據庫服務器在緩存容量達到數據庫經常訪問數據總量（注：數據庫總量不包括系統數據）的5%時性能較好。數據庫總量可以根據5.2 節中數據庫數據估算的方法計算。因此，數據庫系統緩存=數據庫經常訪問數據總量5%。
數據庫服務器軟件佔用內存和所用的數據庫管理軟件及版本相關，按照經驗，一般爲200M內存。
步驟三：估算數據庫併發網絡連接佔用內存
數據庫併發網絡連接數每個佔用5M。假設有200個連接，即併發連接佔用內存爲200 * 5M = 1000M。
步驟四：估算其他軟件佔用內存
先估算需要安裝的軟件，再估算每種軟件佔用內存的總和。爲了簡化計算，可以先估計每種軟件佔用內存大小Mi，再估計安裝的軟件數Ni，即其他軟件佔用內存= 。
步驟五：估算所需內存
根據上述公式，估算所需內存。
10 存儲資源估算方法
申請存儲資源時應根據下述方法估算所需存儲資源的需求，存儲需求主要包括數據庫存儲需求、普通文件存儲需求和系統運行存儲需求三類。
項目 數據庫存儲估算 普通文件存儲估算 系統運行存儲估算
所需參數 1、系統需存儲的實體表數據清單（用E表示）
2、實體數據的索引表數據清單（用I表示）
3、評估每個實體表每條記錄存儲數據容量需求（用S表示） 1、日誌文件（用L表示）
2、其他文件（用E表示） 1、操作系統（用OS表示）
2、應用軟件（如Weblogic）（用App表示）
3、其他軟件需求（超過100M以上）（用E表示）
初始估算 1、應用系統實體表數據容量估算：
E1：實體E1本期記錄M1個，每個容量S1 MB，該視圖表的索引每個容量I1MB。
2、其他類推。 1、日誌文件大小估算L
2、其他文件大小估算
E 1、操作系統大小估算OS
2、應用軟件大小估算 App
3、其他軟件大小估算 E
初始容量需求彙總 容量= (S1+I1) * M1 +…+(Si+Ii) * Mi 容量=L + E 容量= OS + App +E
容量冗餘比率
（建議按照未來2年的存儲需求估算） 容量 （1+容量冗餘比率）
=((S1+I1) * M1 +…+(Si+Ii) * Mi
）（1+冗餘比率） 容量（1+容量冗餘比率）=（L + E）（1+冗餘比率） 容量（1+容量冗餘比率）=（OS + App +E）（1+冗餘比率）
磁盤Raid冗餘比率
（Raid1：增加100%
Raid10:增加100%
Raid5：增加50%） 容量（1+容量冗餘比率）(1+磁盤Raid冗餘比率)
=((S1+I1) * M1 +…+(Si+Ii) * Mi
）（1+容量冗餘比率）(1+磁盤Raid冗餘比率) 容量（1+容量冗餘比率）(1+磁盤Raid冗餘比率)=
（L + E）（1+容量冗餘比率）(1+磁盤Raid冗餘比率) 容量（1+容量冗餘比率）(1+磁盤Raid冗餘比率)=
（OS + App +E）（1+容量冗餘比率）(1+磁盤Raid冗餘比率)
彙總 （(S1+I1) * M1 +…+(Si+Ii) * Mi
）（1+容量冗餘比率）(1+磁盤Raid冗餘比率) （L + E）（1+容量冗餘比率）(1+磁盤Raid冗餘比率) （OS + App +E）（1+容量冗餘比率）(1+磁盤Raid冗餘比率)
1、TPC-C估算法實例
1）情景描述：
a. 某應用系統平均每天20，000個用戶次登錄系統；
b. 平均每個用戶執行五個查詢事務和五個更新事務；
c. 每天最忙時間從上午9：15到上午10：15時間段；
d. 未來一年，用戶數估計要增加一倍。
2）計算步驟：
步驟一：估算應用系統峯值每分鐘需要處理事務數
高峯時間段每分鐘需要處理事務數 = 20，000 x （5+5）x 80% / 60 = 2666.67
步驟二：估算應用系統事務複雜度：本實例事務複雜度爲15。
步驟三：估算應用系統未來一段時間後預留量：預留量爲200%。
步驟四：將以上各參數值代入公式，計算出TPC-C值。
TPC-C值=2666.67 15 * 200% / 75% = 106,666
2、未公佈服務器TPC-C估算法實例
1）情景描述：
TPC組織的網站上發佈了最新的IBM的p5-595的TPC-C值測試結果，如下表所示：
型號 處理器類型 處理器主頻 處理器數量 TPC-C值
p5-595 POWER5+處理器 2.3GHz 64路 4,033,378 tpmC
假設需要估算32路CPU的TPC-C值。
2）計算步驟：
步驟一：獲取滿配置的同類型服務器的TPC-C值：4，033，378。
步驟二：將滿配置服務器型號的CPU個數和主頻、目標配置的服務器的CPU個數和主頻等代入公式。
步驟三：通過公式計算目標配置的服務器的TPC-C值。
估算服務器的TPC-C值=（4033378 ÷2.3÷64）*2.3 * 32 = 2，016，689。
3、Web服務器SPECweb2005估算法實例
1）情景描述：
a. 某個應用系統的總用戶數：100,000。
b. 用戶在典型工作日的在線率爲：25%。
c. 在線用戶平均發起http請求數爲：4。
d. 系統的預留冗餘率爲：20%。
2）計算步驟：
SPECweb2005值=（100，000 * 25% * 4 ）/（1 - 20%）= 125，000。
4、存儲資源估算實例
1）數據庫存儲
情景假設：
a. 某個應用系統，主要包括客戶、產品、訂購關係等三個實體表，建立了3個索引；
b. 預計一年內客戶數爲10000個，每個客戶數據3MB；
c. 產品數爲200個，每個產品數據5MB；
d. 訂購關係數爲50000個，每個數據1MB；
e. 三種索引，每個索引的大小爲1MB；
f. 假設考慮30%的容量冗餘比率；
g. 磁盤採用Raid10冗餘。
計算步驟：
a. 分別估算每個實體表的數量和大小
客戶數據大小： 10000 * 3MB
產品數據大小： 200 * 5MB
訂購關係數據大小： 50000 * 1MB
索引數據大小： 10000 * 1MB + 200 * 1MB + 50000 * 1MB
b. 初步容量需求彙總
初步容量需求彙總= 10000 * (3MB + 1MB) + 200 * (5MB + 1MB) + 50000 * (1MB + 1MB)
= 40000MB + 1200MB + 100000MB = 141,200MB
c. 考慮容量冗餘的容量需求
考慮容量冗餘的容量需求= 141，200MB ÷ (1-30%) = 141,200MB ÷0.7 = 201,714MB
d. 考慮磁盤raid冗餘的容量需求
考慮磁盤raid冗餘的容量需求=201，714MB * 200% = 403,428MB
2）普通文件存儲
情景假設：
a. 某個應用系統存在三種容量較大的文件：日誌文件、交易數據記錄、收費文件；
b. 預計一定時期內，日誌文件的大小可能達到3G, 交易數據記錄文件的大小可能達到2.5G，收費文件的大小可能達到2G；
c. 假設考慮30%的容量冗餘比率；
d. 磁盤採用Raid10冗餘。
計算步驟：
a. 初步容量需求彙總
初步容量需求彙總= 3G + 2.5G + 2G = 7.5G
e. 考慮容量冗餘的容量需求
考慮容量冗餘的容量需求 = 7.5G ÷ (1- 30%) = 10.7G
b. 考慮磁盤raid冗餘的容量需求
考慮磁盤raid冗餘的容量需求= 10.7G * 200% = 21.4G
3）系統運行存儲
情景假設：
a. 服務器上安裝windows 2003server操作系統、WebLogic8.0中間件和防病毒軟件。
b. 假設考慮30%的容量冗餘比率；
c. 磁盤採用Raid10冗餘。
估算步驟：
d. 估算操作系統需要的存儲容量大小
Windows 2003 server操作系統需佔用4.5G空間。
e. 估算應用軟件需要的存儲容量大小
WebLogic 8.0軟件需佔用1.5G空間。
f. 估算其他軟件需要的存儲容量大小
安裝一套防病毒軟件需佔用1G空間。
g. 初步容量需求彙總
初步容量需求彙總 = 4.5G + 1.5G + 1G = 7G
h. 考慮容量冗餘的容量需求：
考慮容量冗餘的容量需求= 7G÷ (1 –30%) = 10G
i. 考慮磁盤raid冗餘的容量需求：
