IT方案硬件资源预估-业务能力测算模型(201111)

如果经常做IT售前解决方案或技术建议书，里面一般都会包括了硬件解决方案和IT基础设施部署架构，而硬件方案里面有个重点就是具体需要多少硬件资源，计算的依据是如何的？而这个就涉及到具体的tpmC业务模型测算。

在我前面文章谈IT基础设施架构和运维架构的时候也经常谈到业务能力测算模型，但是没有对里面的细节进行展开说明，今天这篇文章主要对相关内容进行展开。

整体思路说明

首先我们说下硬件资源测算的整体思路。

即首先你是基于当前的业务需求和场景来估算你需要的tpmC值，其次是我们会拿到对应的标记了tpmC基准值的服务器，然后两者匹配增加一定冗余来确定具体需要多少服务器资源。

所以实际上整体思路并不复杂。

即首先是要搞清楚服务器本身标记的tpmC数据是如何来的，其次再根据我们实际的业务场景和并发需求来计算我们实际需要多大的tpmC能力，通过匹配后最终可以得出服务器资源的需求数。

TPCC规范和计算

在这里首先还是区分下TPC, TPCC和tpmC三者。

• TPC(Transaction Processing Performance Council，事务处理性能委员会)是由数十家会员公司创建的非盈利组织。
• TPC-C是专门针对联机交易处理系统（OLTP系统）的规范。
• tpmC是通过TPCC规范进行基准测试后得出的性能指标的计量单位，即在满足基准测试要求的情况下服务器每分钟能够处理多少订单交易。

TPCC规范和基准测试场景说明

PC-C是专门针对联机交易处理系统（OLTP系统）的，一般情况下我们也把这类系统称为业务处理系统。TPC-C测试规范中模拟了一个比较复杂并具有代表意义的OLTP应用环境:假设有一个大型商品批发商，它拥有若干个分布在不同区域的商品库；每个仓库负责为10个销售点供货；每个销售点为3000个客户提供服务；每个客户平均一个订单有10项产品;所有订单中约1%的产品在其直接所属的仓库中没有存货，需要由其他区域的仓库来供货。

该系统需要处理的交易为以下几种：

• New-Order：客户输入一笔新的订货交易；
• Payment:更新客户账户余额以反映其支付状况;
• Delivery:发货(模拟批处理交易);
• Order-Status:查询客户最近交易的状态；
• Stock-Level:查询仓库库存状况，以便能够及时补货。

对于前四种类型的交易，要求响应时间在5秒以内；对于库存状况查询交易，要求响应时间在20秒以内。注意这个基准测试场景实际是一个混合测试场景，其中包括了CRUD等各类操作，因此在基准响应时间的基础上，还限制了各类操作本身的事务量占比。

五种事务要满足的时间要求，包括键盘操作时间（Keying Time）,思考时间因子(Think Time Distribution)以及 90%的响应时间（90th Percentile Response Time）限制。

简单来说，就是我们要按照要求的比例来设计这个混合性能测试的场景，然后进行加压测试，当加压测试到响应时间要求的极限的时候，则停止加压。然后来看当前实际处理的业务订单数和事务数。该数值即是该服务器资源的tpmC值。

所以对于服务器，更多的是直接将其作为数据库服务器，设计要求的数据库表并填充基础数据，然后再通过压力测试工具进行测试，最终得出结果。常用的开源TPC-C基准测试工具有BenchmarkSQL, dbt2-v0.23等等，这些都可以作为基准测试可以选择的工具。

在整个基准测试中，一个涉及到9个表，具体如下：

其中W 代表仓库数,框中的数字表示该表将存放的记录条数，K代表1000，

仓库数的调整在测试中能够体现数据库所能支持的数据规模的能力。每个 Warehouse 的数据量，其大小约为 76823.04KB，可以有小量的变化，因为测试过程中将会插入或删除现有记录。可以根据每个Warehouse的数据量，计算测试过程中的数据总量。

计算公式为：数据总量（KB）≈ Warehouse个数*76823.04KB

通过以上方法我们基本就能测试出服务器具体的tpmC值，当前对于厂家销售的x86服务器一般都会标记该tpmC值作为参考。我们在网上也可以查询到TPC委员会发布的不同的服务器通过基准测算出来的tpmC值，类似下图：

业务系统TPM计算

简单来说TPM即业务系统峰值的时候每分钟的业务交易量。

我们先看下TPM和tpmC的区别，对于tpmC这个指标注意是指将服务器按TPC要求的基准性能测试场景下进行测试最终得出的业务交易量。而对于TPM则是仅仅基于业务并发需求对分钟业务交易量的峰值进行估算。

我们以一个业务系统的简化场景来进一步举例说明：

总单据量 = 5000+15000+5000+5000 = 40000

实际上业务系统不仅仅是这四类单据， 我们假设四大类业务单据占总体业务量的比例为1/5。

即整体业务交易量 = 40000*5 = 200000

对于每笔业务量的处理，实际上往往涉及到多次的数据库事务处理操作，业务规则的处理才能够完成，可以通过测算看到每一笔单的处理实际上涉及到20次的数据库事务处理。

那么业务处理量 = 20*20 = 400万次。

对于高峰一天产生400万的事务处理量，但是实际80%的交易量都在高峰工作日的4个小时产生的，即240分钟产生了400*0.8 = 320万的交易量。

那么TPM =4000000*0.8/240 = 13333

业务系统最终资源需求确定

基于前面我们测算出了实际的当前的TPM值为13333。

那么我们需要继续考虑如下问题，假设我们的资源需求需要满足业务3年的增长需求，而实际测算业务每年的增长率为20%，那么三年后的业务量为：

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

其次，对于TPM我们不可能将CPU跑到长期类似性能测试下的满负荷状态，我们假设实际生产环境业务运行，CPU负荷只能是极限测算状态下的75%左右。

那么TPM = 23040/0.75 = 30720

也就是说实际我们需要3万tpmC的服务器资源。对于这个TPMC需求我们认为对于数据库和应用服务器都需要这么大的业务交易量处理请求。基于以上数据实际可行配置可以是：

• 2台TPMC为10万以上服务器，同时安装数据库和应用并HA冗余
• 4台TPMC为5万以上的服务器，数据库和应用分开安装并HA或集群

业务系统存储需求测算

数据库容量测算的基础是数据库表，在数据库表的基础上再进行视图，索引和日志等附属信息的存储空间测算。所有的存储需求信息汇总后再考虑3-5年的数据库容量增长情况给出数据库最终容量估算情况。

对于数据库表存储所占的容量，需要首先分析单条记录所占的存储空间大小，而单条记录的存储空间需求和表的字段数和字段类型密切相关。

拿oracle数据库来说：

char类型是多少字节就多少字节，而varchar类型可变长可以按2/3长度折算。number类型可变长度最多占用22字节，平均按10字节估算足够。date类型占用7字节。

以下还是结合上面的业务系统的例子来进行数据库存储容量测算。

对于该业务系统前面依据测算实际每年的单据报销量为20万笔。假设每笔单据本身的数据量为100k左右。

那么总数据量 = 200000*100/1024 = 2G

对于业务单据量占整体数据量的比例为 1/3左右。则整体数据量为 6G

由于每次业务交易操作都涉及到日志处理，日志处理的量约为实际业务单据量的3倍左右，那么考虑操作日志的存储后整体数据量为 = 6+6*3 = 24G

我们按3索引数据量来进行估算：

则总容量需求 = 24 + 24*3 = 96G

对于实际的数据存储，需要满足三年的数据存储需求，同时每年的业务增长率为20%，那么实际的三年的数据库容量需求为：

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

对于数据库的存储需求，我们还是考虑30%左右的冗余：

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

则满足三年数据库总的容量需求为 500G

以上我们就完成了一个基础的数据库容量数据测算，具体的以下基准参考数据还要基于业务系统的实际情况来决定。比如考虑到数据库做RAID冗余，那么容量还需要进一步翻倍。