如果经常做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则是仅仅基于业务并发需求对分钟业务交易量的峰值进行估算。

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

对于财务报销系统核心的业务单据即是业务报账单，其中包括了差旅费报销，日常费用报销，采购类报销，借款报销，报销和审批完成的单据再通过接口导入到ERP。除了报销单据管理外，系统还包括了基础数据管理，ERP接口管联，查询统计等几个模块。

报销系统实际最繁忙的时候为每年的12月的月末一周，我们测算在高峰一天会产生差旅费报销5000单，日常费用报销1.5万单，采购报销5000单，借款单5000单。

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

实际上报销系统不仅仅是这四类单据，围绕四类单据的产生还涉及到基础数据管理维护，流程审批，预算管控，发票数据导入ERP管理等。

我们假设四大类业务单据占总体业务量的比例为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字节。

有了以上假设，可以看到如果有一个客户表30个字段，全部是varchar(100)，那么就是一条客户记录2k,如果客户信息为10万条数据，即单表195M数据。考虑3年每年30%的客户数量增长，则需要的总容量为195*1.3*1.3*1.3=428M

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

对于该报销系统前面依据测算实际每年的单据报销量为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冗余，那么容量还需要进一步翻倍。

商业套件官方的Benchmark数据

对于大型的商用套件，往往官方会给出具体的话务模型数据供你在测算的时候进行参考。比如对于Oracle SOA中间件产品，实际官方会给出一个标准的话务模型如下：

对于这个模型经过翻译后如下：

我们对里面的以下关键术语做下解释如下：

对于SOA平台的业务分成2类，即“定期数据同步”和“实时数据访问”：

定期数据同步

是指有规律的各系统间的数据交换，其执行时间可以根据业务需求灵活调整。这种操作对响应时间没有很严格的要求，而且可以安排到业务系统闲置时间完成；

实时数据访问是指根据客户需求的突发访问，比如：采购订单行信息创建、AP发票导入等等，这样操作对响应时间有严格要求，通常发生在业务系统的用户活动高峰期。“实时数据访问”这种操作需要SOA平台对所涉及流程执行“异步”操作，对未执行完的流程实行集中处理。所以在并发环境下，系统调用的整体效率颇低。

通过分析可以得出“异步操作”速度为37req/sec （根据每天执行320万个请求计算得出），而“同步操作”的速度分别是185req/sec和324req/sec（根据每分钟处理19k请求计算得出）。其中运行Linux的硬件平台均是基于Intel处理器。

备注：324是根据每分钟处理19k请求计算的，即 19*1024/60 =324

所以，我们可以假设：

基于在4路Intel处理器，Oracle软件平台的处理能力是异步30次/秒，同步300次/秒！

对于oracle测试基准，其硬件平台采用的是4路Intel至强处理器，主频是3.0GHz，根据TPCC官方网址提供的测试数据，可以得出此测试平台的TPMC值是95163

注：本模型仅作为硬件性能计算的参考

在有了这个参考基准模型后，我们在进行实际的业务性能测算的时候就简单了，即我们只需要将实际的业务集成场景需求转化为具体在峰值阶段有多少次同步请求，多少次异步请求，然后再和该话务模型数据进行对比，就能够得到实际的tpmC服务器资源能力需求。

而实际我在做的过程中，会形成一个tpmC计算模板，具体在该模板里面只需要输入需要对接的接口服务数，高频服务占比即可以计算tpmC指，类似如下：

上面方法实际问题在哪里？

再回来看下，比如我们刚才对于财务报销应用实际每日的峰值单据量已经不小，但是最终得出的tpmC值仅仅为3万。而现在随便一台2C8核以上的x86服务器往往都是标记的是10万以上的tpmC指的能力需求。

也就是说这里面有个关键问题，即对于服务器本身的tpmC标记虚高。或者说我们很难将报账业务本身的业务场景和复杂度和TCC委员会给出的tpmC基准测算场景进行映射。

即这里面有一个换算系数，这个系数究竟是多少，一开始我们并不清楚。

那么实际上你看到基于上面的tpmC计算方法并不可靠。除非是在项目的二期，三期，你已经在项目建设的第一期积累的对应的换算系数。

那么实际应该用什么方法来计算资源需求？

从前面讲解的内容可以看到，实际上TPCC规范给了我们一个很好的计算硬件服务器资源需求的方法，即先进行基准测试，再进行对比推演。

但是基准测试我们不能用TPCC的基准场景，而是应该用自己的场景。

简单来说我们可以找一个主流的x86服务器配置，比如2C8核，128G内存的服务器两台分别。在每台上面都安装数据库和应用服务，数据库进行HA架构冗余，APP Server采用集群冗余。

基础架构搭建完成后，我们就可以将构建好的财务报销应用进行基准性能测试。

在前面我们已经谈到了实际的差旅报销，日常费用报销，采购报销这种业务量的峰值占比，因此我们可以用性能测试工具进行脚本录制，并配置每种业务量的占比。

录制好后进行性能测试，观察实际的单据查询，单据提交两个关键请求的平均响应时长。因为在招标书里面客户已经提出查询不能超过5秒，提交操作不能超过3秒。那么我们就应该基于该要求进行性能测试。

当加压到性能测试极限的时候，来看实际的业务单据和业务交易每分钟的实际产生量。

这个处理量实际上就是报销系统的基准测试数据。

简单来说，如果该基准数据为1万单，而实际我们的业务场景需求TPM峰值为3万单，那么资源配比就应该在2台基础上*3倍。如果考虑非线性增长，那么就还需要冗余一定的资源。

基于以上这种方式，我们更容易得出一个合理的硬件资源配置需求。 而且在项目建议书或应标的时候资源配置建议也更加有说服力。