服務器能力計算

1、知識就昱力量系統(tǒng)處理能力TPC估算方法1 TPC標準介紹在對系統(tǒng)進行方案設計時，通常會遇到下列問題：a）配置什么樣的服務器設備?b）系統(tǒng)性能如何？c）系統(tǒng)能夠滿足多長時間的應用 ？單憑歷史經驗給出一個經驗值來評估整套系統(tǒng)顯然是不夠的，必須拿出足夠的理論證據(jù)來證明設計中已考慮到了上述問題。通常 ，采用TPC的基準測試來衡量硬件服 務器的處理能力，同時，采用通用計算公式估算軟件所需的處理能力。1.1 TPCTPC是由數(shù)10家會員公司創(chuàng)建的非盈利組織，總部設在美國。該組織對全世界開 放，但迄今為止，絕大多數(shù)會員都是美、日和西歐的大公司。TPC的成員主要是計算機軟硬件廠家，而非計算機用戶，它的功能是制

2、定商務應用基準程序的標準規(guī)范、性能和 價格度量，并管理測試結果的發(fā)布。TPC的測試結果和出版物是開放的,可以通過網站（http: /） 獲取詳 細信息。IBM、NCR、HP、SUN等國際著名服務器供應商均是 TPC會員，這些公司旗 下的產品均會在網站上公布 TPC的測試結果。目前，國內的工程項目中大量采用了上 述公司制造的服務器類產品，因而這些數(shù)據(jù)對于設計階段的性能估算很有參考價值。至 今,TPC 已經推出了 4套基準程序（TPC- A、TPC- B、TPC- C 和TPC- D）。其中TPC- A和TPC- B已經過時,不再使用。TPC- C是在線事務處理（OLTP）的

3、基準程序,TPC- D是決策支持的基準程序。目前，工程設計中常見的系統(tǒng)均為在線事務處理型（包括BSS、OSS和OA）,因此TPC- C 基準測試是本文關注的重點。1.2 TPC- C 基準測試TPC- C是一種旨在衡量OLTP系統(tǒng)性能與可伸縮性的行業(yè)標準基準測試項目。這種基準測試項目將對包括查詢、 更新及隊列式小批量事務在內的廣泛數(shù)據(jù)庫功能進行測 試。許多數(shù)據(jù)專業(yè)設計人員將 TPC- C視為衡量“真實”O(jiān)LTP系統(tǒng)性能的有效指示器。 TPC- C基準測試是對硬件處理能力的考核標準。TPC- C通過模擬一個批發(fā)商的貨物管理系統(tǒng)，衡量硬件服務器的性能指標（查詢、統(tǒng)計功能的執(zhí)行效率）。TPC對具體的

4、 測試環(huán)境，也做了詳細的規(guī)定。1.2.1測試環(huán)境批發(fā)公司有W個倉庫，每個倉庫供應10個地區(qū)，其中每個地區(qū)為3 000名顧客服 務。每個倉庫中有10個終端，每個終端用于一個地區(qū)。在運行時 ,10 XW個終端操作員 向公司的數(shù)據(jù)庫發(fā)出5類請求。1.2.2邏輯和流程該系統(tǒng)需要處理的交易有以下幾種知識就星力量a) New- Order:客戶輸入一筆新的訂貨交易。b) Payment:更新客戶賬戶余額,以反映其支付狀況。c) Delivery:發(fā)貨(模擬批處理交易)。d) Order- Status: 查詢客戶最近交易的狀態(tài)。e) Stock- Level:查詢倉庫庫存狀況,以便能夠及時補貨。從上述定義

5、可見，數(shù)據(jù)庫在邏輯上是分布的。而 W是一個可變參數(shù)，測試者可以隨 意改變W,以獲得最佳測試效果。圖1示出的是TPC- C測試邏輯結構圖；圖2示出的 是TPC- C測試流程圖。曲-1(】:地區(qū)-1】/ Z JF30kV圖1 TPC-C測試邏輯結切圖客戶W*30k"-丄/圖2 TPC-C測試流程圖123評測指標TPC- C基準測試針對一種模擬訂單錄入與銷售環(huán)境測量每分鐘商業(yè)事務吞吐量。按照TPC 的定義,流量指標tpmC描述了系統(tǒng)在執(zhí)行 Payment、Delivery、Order- status、 Stock- Level這4種交易的同時，每分鐘可以處理多少個 New- Order交易

6、。所有交易的 響應時間必須滿足TPC- C測試規(guī)范的要求。最終的測試結果會在TPC的網站上公布,可以免費查詢到絕大部分的系統(tǒng)測試結果。測試信息包括tpmC得分、系統(tǒng)配置清單、測試環(huán)境以及日期等，內容非常詳盡。2服務器處理性能估算2.1估算方案在方案設計之前，必須詳細了解用戶需求，特別關注以下幾點。a）系統(tǒng)的設計使用年限。b）系統(tǒng)平均用戶在線人數(shù)（訪問量）。c）系統(tǒng)忙時，用戶的主要操作行為統(tǒng)計（估值）。d）軟件開發(fā)商應提供的功能架構，并能提供每個功能所引發(fā)的事務處理量。e）系統(tǒng)采用的操作系統(tǒng)和數(shù)據(jù)庫平臺。在充分采集系統(tǒng)信息后，可對系統(tǒng)所需服務器性能進行 3個方面的估算。a）數(shù)據(jù)服務器處理能力估算

7、。b）應用服務器處理能力估算。c）存儲容量估算。值得指出的是，應用服務器和數(shù)據(jù)服務器是 2個不同的概念。應用服務器提供訪問 商業(yè)邏輯的途徑以供客戶端應用程序使用。數(shù)據(jù)服務器主要負責計算和數(shù)據(jù)存儲。在大型系統(tǒng)中應用和數(shù)據(jù)會獨立使用各自的服務器，降低服務器壓力并盡可能保障數(shù)據(jù)安 全和獨立。2.1.1數(shù)據(jù)服務器性能估算測算服務器在忙時的數(shù)據(jù)庫訪問峰值 （X）,代表主機處理峰值應能達到每秒 X個連 接；每個連接平均需要訪問Y個數(shù)據(jù)表。每個數(shù)據(jù)庫訪問相當于服務器 Z的處理能力。 數(shù)據(jù)服務器處理性能（Ls）的估算公式為Ls=XYZ/（ 1-3） / Y （ 1）式中：X用戶連接數(shù)（連接/s）Y 數(shù)據(jù)表連接

8、數(shù)Z數(shù)據(jù)訪問值（tpm）3系統(tǒng)自身消耗值，取值范圍為25%35%Y 系統(tǒng)忙時比例因子,取值范圍為60%80%2.1.2應用服務器性能估算知識就昱力量1）方法一：估值計算應用服務器處理性能（Ly）的估算公式為Ly=Ls a 2）式中：a綜合系數(shù)（見表1）表1項目小型系統(tǒng)中型系統(tǒng)大型系統(tǒng)程序指令行數(shù)<10萬10萬-30萬>30萬a2）方法二：TPC公式計算TPC建議使用式（3）估算所需處理能力。假定在系統(tǒng)發(fā)出的業(yè)務請求中，位列前三項的功能（如查詢、更新、統(tǒng)計功能等）分別命名為A、B、C,則應用服務器需要的 處理能力為Ly=U1N1（ T1+T2+T3） /3XY/Z

9、（ 3）式中：U1系統(tǒng)同時在線用戶數(shù)（人）N1平均每個用戶每分鐘發(fā)出業(yè)務請求次數(shù)（次/人）T1平均每次A業(yè)務產生的事務數(shù)（次）T2平均每次 B業(yè)務產生的事務數(shù)（次）T3平均每次C業(yè)務產生的事務數(shù)（次）X一天內忙時的處理量和平均數(shù)的比值Y經驗系數(shù)（實際量和估算量的比值）Z服務器冗余值方法一和方法二均為常用的處理能力估算方法。方法一更為簡便，但相對方法二缺乏說服力和準確性。因此，建議盡量使用方法二進行估算。2.1.3存儲容量估算系統(tǒng)的存儲空間主要包含4大內容數(shù)據(jù)。a）軟件系統(tǒng)自身所需安裝空間。b）系統(tǒng)運行環(huán)境所需安裝空間（操作系統(tǒng)、數(shù)據(jù)庫軟件、其他第三方軟件等）。c）系統(tǒng)運行產生的數(shù)據(jù)。d）系統(tǒng)日

10、志所需空間。 實際存儲容量（G）計算公式為G= （AB+F） X365C/1 000 000 ） +D+E （ 4）設計存儲容量（Gs）計算公式為Gs=G（ 1+Z） （ 5）式中：每條記錄占用存儲空間（Byte/條）B每天產生的記錄條數(shù) （條）F每天系統(tǒng)日志占用空間（Byte）C設計使用年限（年）D軟件系統(tǒng)自身安裝空間（GByte）E運行環(huán)境所占安裝空間（GByte）Z存儲冗余通常情況下，為了確保數(shù)據(jù)安全性，系統(tǒng)備份時會將數(shù)據(jù)存放在其他獨立的備份設 備中。因此，在存儲容量估算中暫不考慮系統(tǒng)備份所需的容量需求。通過前面3個步驟的計算，就能大致掌握系統(tǒng)數(shù)據(jù)服務器、應用服務器以及存儲容 量上需求值

11、。結合TPC網站上公布的測試數(shù)據(jù)和廠商提供的相關設備的tpmC數(shù)據(jù)，就能做出比較明確的判斷。同時，計算數(shù)據(jù)也是設備選型和設備配置的重要設計依據(jù)。2.2案例分析某建設單位委托設計一套基于 B/S技術的傳輸資源管理系統(tǒng)。 通過采集用戶需求并 咨詢相關軟件開發(fā)商和硬件廠商，獲取了以下信息。a）系統(tǒng)設計使用年限5年。b）項目實施后，用戶之間可以通過系統(tǒng)查詢現(xiàn)網的傳輸架構和資源使用情況。同時，用戶可以定期統(tǒng)計傳輸資源使用情況并及時更新系統(tǒng)信息。C）估算系統(tǒng)平均用戶在線人數(shù)100人。d）軟件開發(fā)商提供的系統(tǒng)參數(shù),包括主要功能操作所產生的事務處理個數(shù)、每條記錄占用的存儲空間等信息。e）軟件指令行數(shù)估計20萬

12、行左右。f）數(shù)據(jù)庫系統(tǒng)為Oracle 9i,并采用RAC方式。特別說明，該項目采用Oracle 9i數(shù)據(jù)庫平臺，并使用真正應用集群（RAC）方式。RAC是Oracle 9i數(shù)據(jù)庫中采用的一項新技術,也是Oracle數(shù)據(jù)庫支持網格計算環(huán)境 的核心技術。使用該技術能大大提高數(shù)據(jù)處理效率并降低安全風險，是目前最為流行的數(shù)據(jù)庫平臺之一。RAC技術能使多個服務器上的多個 Oracle實例同時管理一個數(shù)據(jù)庫 因此必須配置2臺以上數(shù)據(jù)服務器組成數(shù)據(jù)集群。綜合用戶需求、廠商建議和機房勘察結果，擬選用1臺服務器作為應用服務器，2臺數(shù)據(jù)服務器組成數(shù)據(jù)集群，以滿足 Oracle 9i RAC 的需要。圖3示出的是系

13、統(tǒng)邏輯拓撲圖圖3系統(tǒng)邏輯拓撲圖在掌握基礎數(shù)據(jù)后,根據(jù)上一章介紹的估算方案對數(shù)據(jù)服務器、應用服務器和存儲 容量進行需求量計算。221數(shù)據(jù)服務器TPC- C計算每秒峰值為6 000連接Is,即主機處理峰值應能達到 6 000連接/S；每個連接平均 需要10個數(shù)據(jù)表訪問，按照經驗，每個數(shù)據(jù)庫訪問相當于服務器34tpm的處理能力。系統(tǒng)本身要消耗30%的系統(tǒng)資源（廠商提供參考值）；系統(tǒng)忙時比例因子為70%（廠商 提供參考值）。將上述值代入式（1）有丄s=6 000 X10 M/（ 1- 30%） /70%=489 796 因此， 數(shù)據(jù)庫雙機系統(tǒng)TPC- C 要求大于或等于500 000 tpm,考慮實現(xiàn)

14、Oracle 9i RAC 后,雙 機性能約是單機的1.8倍，因此，單機TPC- C 值不能小于500 000/1.8 P78 000 tpm。 2.2.2應用服務器TPC- C計算1）方法一：估值計算本系統(tǒng)程序指令行數(shù)約為20萬行，屬于中型系統(tǒng)。根據(jù)式（2），可得到應用服務器 所需處理能力。Ly=500 000 >0.5=250 000 tpmC2）方法二：TPC公式計算系統(tǒng)最大同時在線用戶數(shù)為300人；估算平均每個用戶每分鐘發(fā)出3次業(yè)務請求；系統(tǒng)發(fā)出的業(yè)務請求中，更新、查詢、統(tǒng)計各占1/3;平均每次更新業(yè)務 觸發(fā)10個事務；平均每次查詢業(yè)務觸發(fā)15個事務；平均每次統(tǒng)計業(yè)務觸發(fā)30個事

15、務;一天內表2建議配置表忙時的處理量為平均值的8倍；約定經驗系數(shù)為1.6（實際工程經驗）；服務器冗余值為30%。根據(jù)式（3）,可得到應用服務器所需處理能力。Ly=300 X3 X 10+15+30） /3 X X.6/0.7電64 000 tpm 方法一和方法二計算的結果比較接近,建議采用較大的值作為最終估算結果。2.2.3存儲容量計算傳輸資源管理系統(tǒng)中主要存統(tǒng)計報表數(shù)據(jù)以及日志管理信息。在已經考慮了數(shù)據(jù)冗余的前提下，約定：每天每個功能模塊生成20個統(tǒng)計報表；目前系統(tǒng)共有10個功能模 塊；每條報表記錄平均占用存儲空間300 B;每年的預算數(shù)據(jù)存儲容量需求為21.9GB;每月的日志數(shù)據(jù)存儲容量需求為0.1 GB;設計使用年限為5年；軟件系統(tǒng)自身安裝空間為1 GB;運行環(huán)境所占安裝空間為5 GB （包含操作系統(tǒng)和數(shù)據(jù)庫）；存儲冗余為30%;全年總共所需存儲容量為：21.9+12 >0.1+1+5=29.1 GB5 年存儲容量為：5 X29.1 X 1+0.3） =189.15 GB2.2.4配置說明完成數(shù)值估算后，建議把計算結果以表格的形式進行歸納總結（見表2）,方便用戶查閱。表2項目設計值建議配置備注數(shù)據(jù)服務器278 000 tpmIBMSystemx3850( 2CPU)Oracle 9i RAC應用服務器264 000 tpmIBMSystemx3500( 2CPU