服務器性能計算

1、 1 概述xxxxx 項目采用集中式部署（即所有的數(shù)據(jù)集中部署在總部服務器中），對于完成各功能服務器的性能，我們建議采用主流的tpc值進行性能估算。tpc-c是一種旨在衡量聯(lián)機事務處理（oltp，又稱業(yè)務處理系統(tǒng)）系統(tǒng)性能與可伸縮性的行業(yè)標準基準測試項目。tpmc（(transaction per minute）: tpc-c每分鐘的吞吐量，按有效 tpc-c配置期間每分鐘處理的平均交易次數(shù)測量，至少要運行 12分鐘。服務器從處理能力上來講，最重要的指標是業(yè)務處理過程中所需要的并行處理能力，這一指標通常都是通過衡量主機的 tpmc值取得；其它對主機硬件性能上的需求還包括內(nèi)存大小，以及對外連接的

2、數(shù)據(jù)線路帶寬。在計算主機所需要的tpmc、硬盤及帶寬時，直接影響這些計算結果的因素包括：用戶的業(yè)務模型（也可以用一定收斂比來表示）、所開展的業(yè)務種類、所開展業(yè)務的并行應用需求。這種基準測試項目將對包括查詢、更新及隊列式小批量事務在內(nèi)的廣泛數(shù)據(jù)庫功能進行測試，因此對于數(shù)據(jù)庫密集型應用來說，tpc-c被許多it部門視為衡量真實oltp系統(tǒng)性能的有效指示器。2 接口服務器性能計算接口服務器在 xxxxx系統(tǒng)中起到承上啟下的作用，與 oa、門戶等其他業(yè)務系統(tǒng)的數(shù)據(jù)交互都需要通過標準接口完成，因此接口服務器的性能及穩(wěn)定性也是至關重要的。xxxxx系統(tǒng)的接口服務器使用 tomcat搭建，根據(jù)經(jīng)驗單服務器上

3、的 tomcat 的整體理論處理能力 1000-2000個用戶并發(fā)連接。考慮到系統(tǒng)操作系統(tǒng) cpu使用率為 10%，因此系統(tǒng)整體負載不能高于 70%。根據(jù) tpmc標準是根據(jù)標準模型中 new-order事物的處理數(shù)目來計算的，一個new-order事物由平均 4-5個 sql語句處理完成，整個測試執(zhí)行過程中 new-order 處理占45%。為了方便計算接口服務器的性能，我們約定：1) 系統(tǒng)注冊用戶數(shù)為 200000 人（u1）； 2) 忙時集中并發(fā)系數(shù)為 10%（b1）；3) 接口服務對應的操作數(shù)為 14.8 （t1）；4) 考慮服務器保留 30的冗余（r）；5) 本次測試 new-ord

4、er事物占全部的 35%（ty）；6) 本次測試 new-order事物執(zhí)行 4個 sql（ts）；7) 一天內(nèi)忙時的處理量為平均值的 8 倍（b2）。8) 每個交易折算標準交易系數(shù)，根據(jù)之前的項目經(jīng)驗系數(shù)為 1.6；接口服務器處理能力為：tpc-c(u1*b1*(t1*ty/ts)/(1-r)*b2*經(jīng)驗系數(shù)200000*0.1*(14.8*0.45/4)*8*1.6/(1-30%)608,914.28tpmc根據(jù)業(yè)務規(guī)模和計算結果，建議接口服務器部署 2臺互為備份，單臺配置 4核 cpu及16g內(nèi)存。3 xxx業(yè)務服務器性能計算xxx業(yè)務服務器作為 xxxxx項目最基本的處理單元，同時部署

5、業(yè)務層、服務層和部分第三方軟件，為保證系統(tǒng)的穩(wěn)定和高效，因此 xxx業(yè)務服務器必須進行負載均衡。xxxxx系統(tǒng)的 xxx業(yè)務服務器，是使用 apache http搭建的 web服務，負責承載所有用戶請求，性能的高低直接決定整個系統(tǒng)的效率。為了方便計算 xxx業(yè)務服務器的性能，我們約定：1) 系統(tǒng)注冊用戶數(shù)為 200000 人（u1）；2) 忙時集中并發(fā)系數(shù)為 10%（b1）；3) 最常用業(yè)務每次業(yè)務請求對應的操作數(shù)為 10.7（t1）；4) 一天內(nèi)忙時的處理量為平均值的 8 倍（b2）；5) 考慮服務器保留 30的冗余（r）；xxx業(yè)務服務器處理能力為：tpc-c(u1*b1*t1*b2)/(

6、1-r)(200000*0.1*10.7*8)/(1-30%)2,445,714.29tpmc根據(jù)業(yè)務規(guī)模和計算結果，建議 xxx業(yè)務服務器部署 4臺，通過負載均衡設備進行訪問，單臺配置 8核 cpu及 32g內(nèi)存。 4 xxx業(yè)務檢索服務器性能計算xxx業(yè)務檢索服務器使用 solr搜索引擎為 xxxxx系統(tǒng)提供索引存儲和檢索的服務，一般情況下檔案查詢量要遠大于瀏覽和下載電子文件數(shù)量，因此壓力相對較大。solr搜索引擎是一個高性能，采用 java5開發(fā)，基于 lucene的全文搜索服務器。同時對其進行了擴展，提供了比 lucene更為豐富的查詢語言，同時實現(xiàn)了可配置、可擴展并對查詢性能進行了優(yōu)

7、化，并且提供了一個完善的功能管理界面，是一款非常優(yōu)秀的全文搜索引擎。為了方便計算檢索服務器的性能，我們約定：1) 系統(tǒng)注冊用戶數(shù)為 200000 人（u1）；2) 忙時集中并發(fā)系數(shù)為 10%（b1）；3) 對應的 solr事物操作數(shù) 6.8（t1）；4) 一天內(nèi)忙時的處理量為平均值的 8 倍（b2）；5) 考慮服務器保留 30的冗余（r）；檢索服務器處理能力為：tpc-c(u1*b1*t1*b2)/(1-r)(200000*0.1*6.8*8)/(1-30%)1,554,285.71tpmc根據(jù)業(yè)務規(guī)模和計算結果，建議檢索服務器部署 5臺通過集群軟件實現(xiàn)負載，單臺配置 4核 cpu及 32g內(nèi)

8、存。5 xxx業(yè)務緩存服務器性能計算xxx業(yè)務緩存服務器為整個 xxxxx系統(tǒng)提供數(shù)據(jù)庫端的數(shù)據(jù)緩存服務，從而減輕數(shù)據(jù)庫的壓力，提高訪問速度。為了方便計算緩存服務器的性能，我們約定：1) 系統(tǒng)注冊用戶數(shù)為 200000 人（u1）；2) 忙時集中并發(fā)系數(shù)為 10%（b1）；3) 一天內(nèi)忙時的處理量為平均值的 8 倍（b2）；4) 對應的事物操作數(shù) 3（t1）； 5) 考慮服務器保留 30的冗余（r）；xxx業(yè)務緩存服務器處理能力為：tpc-c(u1*b1*t1*b2)/(1-r)(200000*0.1*3*8)/(1-30%)685,714.29tpmc根據(jù)業(yè)務規(guī)模和計算結果，建議緩存服務器部

9、署 2臺互為備份，單臺配置 4核 cpu及16g內(nèi)存。6 數(shù)據(jù)庫服務器性能計算xxxxx項目注冊用戶數(shù)約為 200000人，絕大多數(shù)應用屬于聯(lián)機事務處理（oltp）性質。xxxxx項目數(shù)據(jù)使用 mysql作為數(shù)據(jù)庫，通過 mysql的主從復制，從而實現(xiàn)讀寫分離和高可用性功能。為了方便計算數(shù)據(jù)庫服務器的性能，我們約定：1) 系統(tǒng)并發(fā)用戶數(shù)為注冊用戶數(shù)的 10%即2000人（u1）；2) 一天內(nèi)忙時的處理量為平均值的 8 倍（b1）；3) 每個交易折算標準交易系數(shù)，根據(jù)之前的項目經(jīng)驗系數(shù)為 1.6；4) 考慮服務器保留 50的冗余。5) 平均每個用戶每分鐘發(fā)出 4 次業(yè)務請求（n1）；6) 系統(tǒng)發(fā)出的業(yè)務請求中，業(yè)務受理占 20%、信息查詢占 60%、信息瀏覽占 20%（b2）；7) 平均每次業(yè)務受理類業(yè)務產(chǎn)生 5個事務（t1）；8) 平均每次信息查詢類業(yè)務產(chǎn)生 8個事務（t2）；9) 平均每次信息瀏覽類其它業(yè)務產(chǎn)生 3個事務（t3）；數(shù)據(jù)庫服務器處理能力為：tpc-c=u1*b1*(t1*20%+t2*60%+t3*20%)/b1*經(jīng)驗系數(shù)/冗余系數(shù)2000*4*(5*20%+8*60%+3*20%)*8*1.6/0.51,310,720tpmc根據(jù)業(yè)務規(guī)模和計算結果，建議數(shù)據(jù)庫服務器部署兩臺一個作