如果經(jīng)常做IT售前解決方案或技術(shù)建議書，里面一般都會包括了硬件解決方案和IT基礎(chǔ)設(shè)施部署架構(gòu)，而硬件方案里面有個重點(diǎn)就是具體需要多少硬件資源，計算的依據(jù)是如何的？而這個就涉及到具體的tpmC業(yè)務(wù)模型測算。

在我前面文章談IT基礎(chǔ)設(shè)施架構(gòu)和運(yùn)維架構(gòu)的時候也經(jīng)常談到業(yè)務(wù)能力測算模型，但是沒有對里面的細(xì)節(jié)進(jìn)行展開說明，今天這篇文章主要對相關(guān)內(nèi)容進(jìn)行展開。

整體思路說明

首先我們說下硬件資源測算的整體思路。

即首先你是基于當(dāng)前的業(yè)務(wù)需求和場景來估算你需要的tpmC值，其次是我們會拿到對應(yīng)的標(biāo)記了tpmC基準(zhǔn)值的服務(wù)器，然后兩者匹配增加一定冗余來確定具體需要多少服務(wù)器資源。

所以實(shí)際上整體思路并不復(fù)雜。

即首先是要搞清楚服務(wù)器本身標(biāo)記的tpmC數(shù)據(jù)是如何來的，其次再根據(jù)我們實(shí)際的業(yè)務(wù)場景和并發(fā)需求來計算我們實(shí)際需要多大的tpmC能力，通過匹配后最終可以得出服務(wù)器資源的需求數(shù)。

TPCC規(guī)范和計算

在這里首先還是區(qū)分下TPC, TPCC和tpmC三者。

• TPC(Transaction Processing Performance Council，事務(wù)處理性能委員會)是由數(shù)十家會員公司創(chuàng)建的非盈利組織。
• TPC-C是專門針對聯(lián)機(jī)交易處理系統(tǒng)（OLTP系統(tǒng)）的規(guī)范。
• tpmC是通過TPCC規(guī)范進(jìn)行基準(zhǔn)測試后得出的性能指標(biāo)的計量單位，即在滿足基準(zhǔn)測試要求的情況下服務(wù)器每分鐘能夠處理多少訂單交易。

TPCC規(guī)范和基準(zhǔn)測試場景說明

PC-C是專門針對聯(lián)機(jī)交易處理系統(tǒng)（OLTP系統(tǒng)）的，一般情況下我們也把這類系統(tǒng)稱為業(yè)務(wù)處理系統(tǒng)。TPC-C測試規(guī)范中模擬了一個比較復(fù)雜并具有代表意義的OLTP應(yīng)用環(huán)境:假設(shè)有一個大型商品批發(fā)商，它擁有若干個分布在不同區(qū)域的商品庫；每個倉庫負(fù)責(zé)為10個銷售點(diǎn)供貨；每個銷售點(diǎn)為3000個客戶提供服務(wù)；每個客戶平均一個訂單有10項(xiàng)產(chǎn)品;所有訂單中約1%的產(chǎn)品在其直接所屬的倉庫中沒有存貨，需要由其他區(qū)域的倉庫來供貨。

該系統(tǒng)需要處理的交易為以下幾種：

• New-Order：客戶輸入一筆新的訂貨交易；
• Payment:更新客戶賬戶余額以反映其支付狀況;
• Delivery:發(fā)貨(模擬批處理交易);
• Order-Status:查詢客戶最近交易的狀態(tài)；
• Stock-Level:查詢倉庫庫存狀況，以便能夠及時補(bǔ)貨。

對于前四種類型的交易，要求響應(yīng)時間在5秒以內(nèi)；對于庫存狀況查詢交易，要求響應(yīng)時間在20秒以內(nèi)。注意這個基準(zhǔn)測試場景實(shí)際是一個混合測試場景，其中包括了CRUD等各類操作，因此在基準(zhǔn)響應(yīng)時間的基礎(chǔ)上，還限制了各類操作本身的事務(wù)量占比。

五種事務(wù)要滿足的時間要求，包括鍵盤操作時間（Keying Time）,思考時間因子(Think Time Distribution)以及 90%的響應(yīng)時間（90th Percentile Response Time）限制。

簡單來說，就是我們要按照要求的比例來設(shè)計這個混合性能測試的場景，然后進(jìn)行加壓測試，當(dāng)加壓測試到響應(yīng)時間要求的極限的時候，則停止加壓。然后來看當(dāng)前實(shí)際處理的業(yè)務(wù)訂單數(shù)和事務(wù)數(shù)。該數(shù)值即是該服務(wù)器資源的tpmC值。

所以對于服務(wù)器，更多的是直接將其作為數(shù)據(jù)庫服務(wù)器，設(shè)計要求的數(shù)據(jù)庫表并填充基礎(chǔ)數(shù)據(jù)，然后再通過壓力測試工具進(jìn)行測試，最終得出結(jié)果。常用的開源TPC-C基準(zhǔn)測試工具有BenchmarkSQL, dbt2-v0.23等等，這些都可以作為基準(zhǔn)測試可以選擇的工具。

在整個基準(zhǔn)測試中，一個涉及到9個表，具體如下：

其中W 代表倉庫數(shù),框中的數(shù)字表示該表將存放的記錄條數(shù)，K代表1000，

倉庫數(shù)的調(diào)整在測試中能夠體現(xiàn)數(shù)據(jù)庫所能支持的數(shù)據(jù)規(guī)模的能力。每個 Warehouse 的數(shù)據(jù)量，其大小約為 76823.04KB，可以有小量的變化，因?yàn)闇y試過程中將會插入或刪除現(xiàn)有記錄?？梢愿鶕?jù)每個Warehouse的數(shù)據(jù)量，計算測試過程中的數(shù)據(jù)總量。

計算公式為：數(shù)據(jù)總量（KB）≈ Warehouse個數(shù)*76823.04KB

通過以上方法我們基本就能測試出服務(wù)器具體的tpmC值，當(dāng)前對于廠家銷售的x86服務(wù)器一般都會標(biāo)記該tpmC值作為參考。我們在網(wǎng)上也可以查詢到TPC委員會發(fā)布的不同的服務(wù)器通過基準(zhǔn)測算出來的tpmC值，類似下圖：

業(yè)務(wù)系統(tǒng)TPM計算

簡單來說TPM即業(yè)務(wù)系統(tǒng)峰值的時候每分鐘的業(yè)務(wù)交易量。

我們先看下TPM和tpmC的區(qū)別，對于tpmC這個指標(biāo)注意是指將服務(wù)器按TPC要求的基準(zhǔn)性能測試場景下進(jìn)行測試最終得出的業(yè)務(wù)交易量。而對于TPM則是僅僅基于業(yè)務(wù)并發(fā)需求對分鐘業(yè)務(wù)交易量的峰值進(jìn)行估算。

我們以一個財務(wù)報銷系統(tǒng)的簡化場景來進(jìn)一步舉例說明：

對于財務(wù)報銷系統(tǒng)核心的業(yè)務(wù)單據(jù)即是業(yè)務(wù)報賬單，其中包括了差旅費(fèi)報銷，日常費(fèi)用報銷，采購類報銷，借款報銷，報銷和審批完成的單據(jù)再通過接口導(dǎo)入到ERP。除了報銷單據(jù)管理外，系統(tǒng)還包括了基礎(chǔ)數(shù)據(jù)管理，ERP接口管聯(lián)，查詢統(tǒng)計等幾個模塊。

報銷系統(tǒng)實(shí)際最繁忙的時候?yàn)槊磕甑?2月的月末一周，我們測算在高峰一天會產(chǎn)生差旅費(fèi)報銷5000單，日常費(fèi)用報銷1.5萬單，采購報銷5000單，借款單5000單。

總單據(jù)量 = 5000+15000+5000+5000 = 40000

實(shí)際上報銷系統(tǒng)不僅僅是這四類單據(jù)，圍繞四類單據(jù)的產(chǎn)生還涉及到基礎(chǔ)數(shù)據(jù)管理維護(hù)，流程審批，預(yù)算管控，發(fā)票數(shù)據(jù)導(dǎo)入ERP管理等。

我們假設(shè)四大類業(yè)務(wù)單據(jù)占總體業(yè)務(wù)量的比例為1/5。

即整體業(yè)務(wù)交易量 = 40000*5 = 200000

對于每筆業(yè)務(wù)量的處理，實(shí)際上往往涉及到多次的數(shù)據(jù)庫事務(wù)處理操作，業(yè)務(wù)規(guī)則的處理才能夠完成，可以通過測算看到每一筆報賬單的處理實(shí)際上涉及到20次的數(shù)據(jù)庫事務(wù)處理。

那么業(yè)務(wù)處理量 = 20*20 = 400萬次。

對于高峰一天產(chǎn)生400萬的事務(wù)處理量，但是實(shí)際80%的交易量都在高峰工作日的4個小時產(chǎn)生的，即240分鐘產(chǎn)生了400*0.8 = 320萬的交易量。

那么TPM =4000000*0.8/240 = 13333

業(yè)務(wù)系統(tǒng)最終資源需求確定

基于前面我們測算出了實(shí)際的當(dāng)前的TPM值為13333。

那么我們需要繼續(xù)考慮如下問題，假設(shè)我們的資源需求需要滿足業(yè)務(wù)3年的增長需求，而實(shí)際測算業(yè)務(wù)每年的增長率為20%，那么三年后的業(yè)務(wù)量為：

三年后TPM = 13333*1.2*1.2*1.2 = 23040

其次，對于TPM我們不可能將CPU跑到長期類似性能測試下的滿負(fù)荷狀態(tài)，我們假設(shè)實(shí)際生產(chǎn)環(huán)境業(yè)務(wù)運(yùn)行，CPU負(fù)荷只能是極限測算狀態(tài)下的75%左右。

那么TPM = 23040/0.75 = 30720

也就是說實(shí)際我們需要3萬tpmC的服務(wù)器資源。對于這個TPMC需求我們認(rèn)為對于數(shù)據(jù)庫和應(yīng)用服務(wù)器都需要這么大的業(yè)務(wù)交易量處理請求。基于以上數(shù)據(jù)實(shí)際可行配置可以是：

• 2臺TPMC為10萬以上服務(wù)器，同時安裝數(shù)據(jù)庫和應(yīng)用并HA冗余
• 4臺TPMC為5萬以上的服務(wù)器，數(shù)據(jù)庫和應(yīng)用分開安裝并HA或集群

業(yè)務(wù)系統(tǒng)存儲需求測算

數(shù)據(jù)庫容量測算的基礎(chǔ)是數(shù)據(jù)庫表，在數(shù)據(jù)庫表的基礎(chǔ)上再進(jìn)行視圖，索引和日志等附屬信息的存儲空間測算。所有的存儲需求信息匯總后再考慮3-5年的數(shù)據(jù)庫容量增長情況給出數(shù)據(jù)庫最終容量估算情況。

對于數(shù)據(jù)庫表存儲所占的容量，需要首先分析單條記錄所占的存儲空間大小，而單條記錄的存儲空間需求和表的字段數(shù)和字段類型密切相關(guān)。

拿oracle數(shù)據(jù)庫來說：

char類型是多少字節(jié)就多少字節(jié)，而varchar類型可變長可以按2/3長度折算。number類型可變長度最多占用22字節(jié)，平均按10字節(jié)估算足夠。date類型占用7字節(jié)。

有了以上假設(shè)，可以看到如果有一個客戶表30個字段，全部是varchar(100)，那么就是一條客戶記錄2k,如果客戶信息為10萬條數(shù)據(jù)，即單表195M數(shù)據(jù)?？紤]3年每年30%的客戶數(shù)量增長，則需要的總?cè)萘繛?95*1.3*1.3*1.3=428M

以下還是結(jié)合上面的財務(wù)報銷系統(tǒng)的例子來進(jìn)行數(shù)據(jù)庫存儲容量測算。

對于該報銷系統(tǒng)前面依據(jù)測算實(shí)際每年的單據(jù)報銷量為20萬筆。假設(shè)每筆單據(jù)本身的數(shù)據(jù)量為100k左右。

那么總數(shù)據(jù)量 = 200000*100/1024 = 2G

對于業(yè)務(wù)單據(jù)量占整體數(shù)據(jù)量的比例為 1/3左右。則整體數(shù)據(jù)量為 6G

由于每次業(yè)務(wù)交易操作都涉及到日志處理，日志處理的量約為實(shí)際業(yè)務(wù)單據(jù)量的3倍左右，那么考慮操作日志的存儲后整體數(shù)據(jù)量為 = 6+6*3 = 24G

我們按3索引數(shù)據(jù)量來進(jìn)行估算：

則總?cè)萘啃枨?= 24 + 24*3 = 96G

對于實(shí)際的數(shù)據(jù)存儲，需要滿足三年的數(shù)據(jù)存儲需求，同時每年的業(yè)務(wù)增長率為20%，那么實(shí)際的三年的數(shù)據(jù)庫容量需求為：

需求 = 96 + 96*1.2 + 96*1.2*1.2 = 350G

對于數(shù)據(jù)庫的存儲需求，我們還是考慮30%左右的冗余：

需求 = 131/（1-0.3）= 500G

則滿足三年數(shù)據(jù)庫總的容量需求為 500G

以上我們就完成了一個基礎(chǔ)的數(shù)據(jù)庫容量數(shù)據(jù)測算，具體的以下基準(zhǔn)參考數(shù)據(jù)還要基于業(yè)務(wù)系統(tǒng)的實(shí)際情況來決定。比如考慮到數(shù)據(jù)庫做RAID冗余，那么容量還需要進(jìn)一步翻倍。

商業(yè)套件官方的Benchmark數(shù)據(jù)

對于大型的商用套件，往往官方會給出具體的話務(wù)模型數(shù)據(jù)供你在測算的時候進(jìn)行參考。比如對于Oracle SOA中間件產(chǎn)品，實(shí)際官方會給出一個標(biāo)準(zhǔn)的話務(wù)模型如下：

對于這個模型經(jīng)過翻譯后如下：

我們對里面的以下關(guān)鍵術(shù)語做下解釋如下：

對于SOA平臺的業(yè)務(wù)分成2類，即“定期數(shù)據(jù)同步”和“實(shí)時數(shù)據(jù)訪問”：

定期數(shù)據(jù)同步

是指有規(guī)律的各系統(tǒng)間的數(shù)據(jù)交換，其執(zhí)行時間可以根據(jù)業(yè)務(wù)需求靈活調(diào)整。這種操作對響應(yīng)時間沒有很嚴(yán)格的要求，而且可以安排到業(yè)務(wù)系統(tǒng)閑置時間完成；

實(shí)時數(shù)據(jù)訪問是指根據(jù)客戶需求的突發(fā)訪問，比如：采購訂單行信息創(chuàng)建、AP發(fā)票導(dǎo)入等等，這樣操作對響應(yīng)時間有嚴(yán)格要求，通常發(fā)生在業(yè)務(wù)系統(tǒng)的用戶活動高峰期?！皩?shí)時數(shù)據(jù)訪問”這種操作需要SOA平臺對所涉及流程執(zhí)行“異步”操作，對未執(zhí)行完的流程實(shí)行集中處理。所以在并發(fā)環(huán)境下，系統(tǒng)調(diào)用的整體效率頗低。

通過分析可以得出“異步操作”速度為37req/sec （根據(jù)每天執(zhí)行320萬個請求計算得出），而“同步操作”的速度分別是185req/sec和324req/sec（根據(jù)每分鐘處理19k請求計算得出）。其中運(yùn)行Linux的硬件平臺均是基于Intel處理器。

備注：324是根據(jù)每分鐘處理19k請求計算的，即 19*1024/60 =324

所以，我們可以假設(shè)：

基于在4路Intel處理器，Oracle軟件平臺的處理能力是異步30次/秒，同步300次/秒！

對于oracle測試基準(zhǔn)，其硬件平臺采用的是4路Intel至強(qiáng)處理器，主頻是3.0GHz，根據(jù)TPCC官方網(wǎng)址提供的測試數(shù)據(jù)，可以得出此測試平臺的TPMC值是95163

注：本模型僅作為硬件性能計算的參考

在有了這個參考基準(zhǔn)模型后，我們在進(jìn)行實(shí)際的業(yè)務(wù)性能測算的時候就簡單了，即我們只需要將實(shí)際的業(yè)務(wù)集成場景需求轉(zhuǎn)化為具體在峰值階段有多少次同步請求，多少次異步請求，然后再和該話務(wù)模型數(shù)據(jù)進(jìn)行對比，就能夠得到實(shí)際的tpmC服務(wù)器資源能力需求。

而實(shí)際我在做的過程中，會形成一個tpmC計算模板，具體在該模板里面只需要輸入需要對接的接口服務(wù)數(shù)，高頻服務(wù)占比即可以計算tpmC指，類似如下：

上面方法實(shí)際問題在哪里？

再回來看下，比如我們剛才對于財務(wù)報銷應(yīng)用實(shí)際每日的峰值單據(jù)量已經(jīng)不小，但是最終得出的tpmC值僅僅為3萬。而現(xiàn)在隨便一臺2C8核以上的x86服務(wù)器往往都是標(biāo)記的是10萬以上的tpmC指的能力需求。

也就是說這里面有個關(guān)鍵問題，即對于服務(wù)器本身的tpmC標(biāo)記虛高?；蛘哒f我們很難將報賬業(yè)務(wù)本身的業(yè)務(wù)場景和復(fù)雜度和TCC委員會給出的tpmC基準(zhǔn)測算場景進(jìn)行映射。

即這里面有一個換算系數(shù)，這個系數(shù)究竟是多少，一開始我們并不清楚。

那么實(shí)際上你看到基于上面的tpmC計算方法并不可靠。除非是在項(xiàng)目的二期，三期，你已經(jīng)在項(xiàng)目建設(shè)的第一期積累的對應(yīng)的換算系數(shù)。

那么實(shí)際應(yīng)該用什么方法來計算資源需求？

從前面講解的內(nèi)容可以看到，實(shí)際上TPCC規(guī)范給了我們一個很好的計算硬件服務(wù)器資源需求的方法，即先進(jìn)行基準(zhǔn)測試，再進(jìn)行對比推演。

但是基準(zhǔn)測試我們不能用TPCC的基準(zhǔn)場景，而是應(yīng)該用自己的場景。

簡單來說我們可以找一個主流的x86服務(wù)器配置，比如2C8核，128G內(nèi)存的服務(wù)器兩臺分別。在每臺上面都安裝數(shù)據(jù)庫和應(yīng)用服務(wù)，數(shù)據(jù)庫進(jìn)行HA架構(gòu)冗余，APP Server采用集群冗余。

基礎(chǔ)架構(gòu)搭建完成后，我們就可以將構(gòu)建好的財務(wù)報銷應(yīng)用進(jìn)行基準(zhǔn)性能測試。

在前面我們已經(jīng)談到了實(shí)際的差旅報銷，日常費(fèi)用報銷，采購報銷這種業(yè)務(wù)量的峰值占比，因此我們可以用性能測試工具進(jìn)行腳本錄制，并配置每種業(yè)務(wù)量的占比。

錄制好后進(jìn)行性能測試，觀察實(shí)際的單據(jù)查詢，單據(jù)提交兩個關(guān)鍵請求的平均響應(yīng)時長。因?yàn)樵谡袠?biāo)書里面客戶已經(jīng)提出查詢不能超過5秒，提交操作不能超過3秒。那么我們就應(yīng)該基于該要求進(jìn)行性能測試。

當(dāng)加壓到性能測試極限的時候，來看實(shí)際的業(yè)務(wù)單據(jù)和業(yè)務(wù)交易每分鐘的實(shí)際產(chǎn)生量。

這個處理量實(shí)際上就是報銷系統(tǒng)的基準(zhǔn)測試數(shù)據(jù)。

簡單來說，如果該基準(zhǔn)數(shù)據(jù)為1萬單，而實(shí)際我們的業(yè)務(wù)場景需求TPM峰值為3萬單，那么資源配比就應(yīng)該在2臺基礎(chǔ)上*3倍。如果考慮非線性增長，那么就還需要冗余一定的資源。

基于以上這種方式，我們更容易得出一個合理的硬件資源配置需求。 而且在項(xiàng)目建議書或應(yīng)標(biāo)的時候資源配置建議也更加有說服力。