计算机性能衡量指标TPC、TPCC、TPMC

1. 什么是TPC和tpmC?

1.1. TPC

TPC(Transaction Processing Performance Council，事务处理性能委员会)是由数10家会员公司创建的非盈利组织，总部设在美国。该组织对全世界开放，但迄今为止，绝大多数会员都是美、日、西欧的大公司。TPC的成员主要是计算机软硬件厂家，而非计算机用户，它的功能是制定商务应用基准程序(Benchmark)的标准规范、性能和价格度量，并管理测试结果的发布。

TPC的出版物是开放的，可以通过网络获取(http://www.tpc.org)。TPC不给出基准程序的代码，而只给出基准程序的标准规范(Standard Specification)。任何厂家或其它测试者都可以根据规范，最优地构造出自己的系统(测试平台和测试程序)。为保证测试结果的客观性，被测试者(通常是厂家)必须提交给TPC一套完整的报告(Full Disclosure Report)，包括被测系统的详细配置、分类价格和包含五年维护费用在内的总价格。该报告必须由TPC授权的审核员核实(TPC本身并不做审计)。现在全球只有几个审核员，全部在美国。

TPC已经推出了四套基准程序，被称为TPC－A、TPC－B、TPC－C和TPC－D。其中A和B已经过时，不再使用了。TPC－C是在线事务处理(OLTP)的基准程序，TPC－D是决策支持(Decision Support) 的基准程序。TPC即将推TPC－E，作为大型企业(Enterprise)信息服务的基准程序。

1.2. tpmC

tpmC值在国内外被广泛用于衡量计算机系统的事务处理能力。但究竟什么是tpmC值呢?作者曾向一些用户、推销人员乃至某些国外大公司的技术人员问过这个问题，但回答的精确度与tpmC值的流行程度远非相称。tpmC这一度量也常被误写为TPM或TPMC。

TPC-C模拟一个批发商的货物管理环境。该批发公司有N个仓库，每个仓库供应10个地区，其中每个地区为3000名顾客服务。在每个仓库中有10个终端，每一个终端用于一个地区。在运行时，10×N个终端操作员向公司的数据库发出5类请求。由于一个仓库中不可能存储公司所有的货物，有一些请求必须发往其它仓库，因此，数据库在逻辑上是分布的。N是一个可变参数，测试者可以随意改变N，以获得最佳测试效果。

TPC-C使用三种性能和价格度量，其中性能由TPC-C吞吐率衡量，单位是tpmC。tpm是transactions per minute的简称；C指TPC中的C基准程序。它的定义是每分钟内系统处理的新订单个数。要注意的是，在处理新订单的同时，系统还要按表1的要求处理其它4类事务请求。从表1可以看出，新订单请求不可能超出全部事务请求的45％，因此，当一个系统的性能为1000tpmC时，它每分钟实际处理的请求数是2000多个。价格是指系统的总价格，单位是美元，而价格性能比则定义为总价格÷性能，单位是＄/tpmC。

tpmC定义: TPC-C的吞吐量，按有效TPC-C配置期间每分钟处理的平均交易次数测量，至少要运行12分钟。

（吞吐量测试结果以比特/秒或字节/秒表示。）

2. TPCC

2.1. 基准测试

TPCC值被广泛用于衡量C/S环境下,由服务器和客户端构筑的整体系统的性能,它由事物处理性能委员会（TPC，Transaction Processing Corp）制定,TPC为非赢利性国际组织。

TPCC值可以反映出系统的性能价格比。TPCC测试系统每分钟处理的任务数,单位为tpm,(transactions per minute)。系统的总体价格(单位为美元)除以TPCC值,就可以衡量出系统的性价比,系统的性价比值越大,系统的性价比越好。

需要注意的是,TPC-C值描述的是C/S整体系统的性能,它与系统的服务器和客户机的性能都有关系,也就是说,同样的服务器配置不同的客户端将会影响TPCC值,任何厂商和测试者都可以根据TPC提供的测试规范构造出自己最优的系统,当然测试的结果要经过TPC审核。

2.2. 性能测试指标介绍

TPC-C

作为一家非盈利性机构，事务处理性能委员会（TPC）负责定义诸如TPC-C、TPC-H和TPC-W基准测试之类的事务处理与数据库性能基准测试，并依据这些基准测试项目发布客观性能数据。TPC基准测试采用极为严格的运行环境，并且必须在独立审计机构监督下进行。委员会成员包括大多数主要数据库产品厂商以及服务器硬件系统供应商。

相关企业参与TPC基准测试以期在规定运行环境中获得客观性能验证，并通过应用测试过程中所使用的技术开发出更加强健且更具伸缩性的软件产品及硬件设备。

TPC-C是一种旨在衡量联机事务处理（OLTP）系统性能与可伸缩性的行业标准基准测试项目。这种基准测试项目将对包括查询、更新及队列式小批量事务在内的广泛数据库功能进行测试。许多IT专业人员将TPC-C视为衡量“真实”OLTP系统性能的有效指示器。

TPC-C基准测试针对一种模拟订单录入与销售环境测量每分钟商业事务（tpmC）吞吐量。特别值得一提的是，它将专门测量系统在同时执行其它四种事务类型（如支付、订单状态更新、交付及证券级变更）时每分钟所生成的新增订单事务数量。独立审计机构将负责对基准测试结果进行公证，同时，TPC将出据一份全面彻底的测试报告。这份测试报告可以从TPC Web站点(http://www.tpc.org)上获得。

2.3. TPC-C规范概要

TPC-C是专门针对联机交易处理系统（OLTP系统）的，一般情况下我们也把这类系统称为业务处理系统。

TPC-C测试规范中模拟了一个比较复杂并具有代表意义的OLTP应用环境:假设有一个大型商品批发商，它拥有若干个分布在不同区域的商品库；每个仓库负责为10个销售点供货；每个销售点为3000个客户提供服务；每个客户平均一个订单有10项产品;所有订单中约1%的产品在其直接所属的仓库中没有存货，需要由其他区域的仓库来供货。

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

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

对于前四种类型的交易，要求响应时间在5秒以内；对于库存状况查询交易，要求响应时间在20秒以内。

2.4. 评测指标

TPC-C测试规范经过两年的研制，于1992年7月发布。几乎所有在OLTP市场提供软硬件平台的厂商都发布了相应的TPC-C测试结果，随着计算机技术的不断发展，这些测试结果也在不断刷新。

TPC-C的测试结果主要有两个指标：

2.4.1. ①流量指标(Throughput，简称tpmC)

按照TPC的定义，流量指标描述了系统在执行Payment、Order-status、Delivery、Stock-Level这四种交易的同时，每分钟可以处理多少个New-Order交易。所有交易的响应时间必须满足TPC-C测试规范的要求。

流量指标值越大越好！

2.4.2. ②性价比(Price/Performance，简称Price/tpmC)

即测试系统价格（指在美国的报价）与流量指标的比值。

性价比越大越好！

3. （TPCC）如何衡量计算机系统的性能和价格

在系统选型时，我们一定不要忘记我们是为特定用户环境中的特定应用选择系统。切忌为了“与国际接轨”而盲目套用“国际通用”的东西。在性能评价领域，越是通用的度量常常越是不准确的。据我所知，美国的一些大用户从不相信任何“国际通用”的度量，而是花相当精力，比如预算的5％，使用自己的应用来测试系统，决定选型。在使用任何一种性能和价格度量时，一定要弄明白该度量的定义，以及它是在什么系统配置和运行环境下得到的，如何解释它的意义等。下面我们由好到差讨论三种方式。

3.1. 在真实环境中运行实际应用

最理想的方式是搞一个试点，要求制造商或系统集成商配合将系统(含平台、软件和操作流程)在一个实际用户点真正试运行一段时间。这样，用户不仅能看到实际性能，也能观察到系统是否稳定可靠、使用是否方便、服务是否周到、配置是否足够、全部价格是否合理。如果一个部门需要购买一批同类的系统，这种方式应列为首选，因为它不仅最精确、稳妥，也常常最有效率，用户还可先租一套系统作为试点。用这种方式得到的度量值常常具有很明确和实际的含义。

3.2. 使用用户定义的基准程序

如果由于某种原因第一种方式不可行，用户可以定义一组含有自己实际应用环境特征的应用基准程序。我举两个例子：近年来，由于R/3软件是应用层软件，SAP公司的基准程序获得了越来越多国外企业的认可；中国税务总局最近也开发了自己的基准程序，以帮助税务系统进行计算机选型。这种方式在中国尤其重要，因为中国的信息系统有其特殊性。

3.3. 使用通用基准程序

如果第1种和第2种方式都不行，则使用如TPC-C之类的通用基准程序，这是不得已的一种近似方法。因此，tpmC值只能用作参考。我们应当注意以下几点：

3.3.1. ①实际应用是否与基准程序相符

绝大多数基准程序都是在美国制订的，而中国的企事业单位与美国的运作方式常常不一样(恐怕也不应该或不可能一样)。在使用TPC－C时，我们应该清楚地知道：我的应用是否符合批发商模式?事务请求是否与表1近似?对响应时间的要求是否满足表1?如果都不是，则tpmC值的参考价值就不太大了。

3.3.2. ②TPC度量的解释

TPC基准程序是用来测系统而不是测主机的，厂家肯定要充分优化他们的被测系统。此处的“系统”包括主机、外设(如硬盘或RAID)、主机端操作系统、数据库软件、客户端计算机及其操作系统、数据库软件和网络连接等。在很多厂家的TPC测试系统中，主机的价格只是系统总价格的1/4或更小，而硬盘的价格有可能占到总价格的1/3以上，因为TPC－C要求被测系统必须保存180天的事务记录。如果同样的主机被用到用户的环境中，厂家报的tpmC值就意义不大，因为用户的实际系统与厂家原来用于TPC测试的系统大不一样。当同样的主机用在不同的系统中时，tpmC值可能有相当大的变化，现在很多用户还没有意识到这一点。

我举一个例子。假设用户希望购买一批同类系统，每一系统至少需要1GB的内存和50GB的硬盘。厂家A、B、C 各报了三个价格相当的系统，tpmC值分别为3000、2800、2600。用户是否应该选厂家A的产品呢?答案是：不一定。厂家用于测试tpmC值的系统与实际提供给用户的系统配置大不一样。tpmC最低的厂家C提供给用户的系统反而有可能性能最好，不论是以实际系统的tpmC值还是以用户的实际应用性能来衡量。

3.3.3. ③TPC测试的成本

TPC－C和TPC－D都是很复杂的基准程序，做一个严格的测试是很消耗资源的，厂家当然不会说出他们花费了多少钱和时间。但据国外知情人士透露，一个厂家做第一个TPC－C测试需要几十万到上百万美元的资金和半年左右的时间投入。因此，很多TPC的度量值都是估计的。由于计算机系统换代频繁，如果用户一定要用通过审核的度量值，就必须多等待半年时间，因此而不能用最先进的系统。中国的厂家通过审核的时间则更长。

综上所述，我们对中国用户(尤其是大用户)在计算机系统的选型方面有如下建议：

最好建立一个真实的试点，因为实际应用环境是检验计算机系统的最好标准。

中国的行业应该建立符合自己实际应用的基准程序和测试标准。中国税务总局的做法值得提倡。国家有关部门应该建立独立的测试中心，制定跨行业、符合中国企事业运作模式的性能测试标准。

“国际通用”的度量可以作为参考值，而不应作为必要条件。尤其是一定要弄清这些流行度量有什么含义，是在什么样的系统环境中测得的，以及基准程序是否符合企业真实的业务流程和运作模式。

4. TPCC计算原则

4.1. 建议

不管是TPC-C还是SPECjbb2000，计算结果都只能作为一个横向比较的参考。在实际应用中，决定系统性能的因素除了硬件、系统软件外，与应用软件的设计也是有很大关系的，此外，基于系统可扩展性的考虑，更多时候也倾向于一次性的采购。

从长远考虑，以政府信息化主管部门的角度考虑，建立一套评估机制是非常有用的，这其中包括：

1、通过对各单位业务系统运行情况的调查，进行历史数据的收集分析，按分类建立基准指标库。收集的信息包括：服务器的配置、并发用户数（每天业务量）、CPU负荷等；

2、由厂商定期提供基准值，更新基准指标库；

有了基准指标库的信息参照，不仅可以用于评估项目建设方案中服务器选型，也可以对各部门进行系统架构设计的优化提供指导。如以下是一些指导原则：

1、数据库服务器选型：采购两台相同配置的小型机，进行虚拟分区和并行处理，以提高系统资源的利用率；日后扩容时采取垂直扩展的方式进行升级；

2、应用服务器：采用负载均衡的方式提高并发处理能力，一般可配置2台以上，每台的硬件配置完全可以不同，应首先考虑使用旧的数据库服务器（利旧），如需采购新的服务器，应采用水平扩展的方式逐步升级；

3、 WEB服务器，可以考虑采用刀片服务器，提高扩展性和可管理性。

5. 参考：某项目计算实例

5.1. 参考1

为了方便计算数据库服务器的造型，我们约定：" 系统同时在线用户数为1500人（U1）；" 平均每个用户每分钟发出2次业务请求（N1）；" 系统发出的业务请求中，更新、查询、统计各占1/3；" 平均每次更新业务产生3个事务（T1）；" 平均每次查询业务产生8个事务（T2）；" 平均每次统计业务产生13个事务（T3）；" 一天内忙时的处理量为平均值的5倍；“经验系数为1.6；(实际工程经验) " 考虑服务器保留30％的冗余；

服务器需要的处理能力为：

**TPC-C=U1N1（T1+T2+T3）/33经验系数/冗余系数 **

则应用服务器的处理性能估算为：

TPC-C= 15002（3+8+13）/351.6/0.7= 274,285 tpmC

数据库服务器关系到整个系统的稳定运行，考虑到高可靠性和高可用性，并注重设备的可扩展性和性价比，系统将配置两台TPC-C值不小于28万的高性能数据库服务器。

5.2. 参考2

以单台服务器性能进行计算，即确保单台服务器工作的时候可以满足系统正常运行的需要；

假设每天有1万人次来窗口办理业务，每人次办理一项业务。即以每日1万笔前台交易为例进行综合系数的推导：

1. 假设每月前台交易数（未来5年内的设计指标）为220,000 （有些业务在月初、月末的处理量比较高，按月统计可以平衡此项差异）;

2. 每日前台交易数=220000/22=10,000 ，即每日 1万笔；3. 忙时处理能力：每日交易的80%在4个小时内完成，即1000080%/4=2000（笔/小时）4. 峰值处理能力：20002=4000（笔/小时），即峰值处理能力为每小时4000笔，或 67笔/分，假设业务人员同时在线为100人，即每人每分钟处理0.7笔）5. 假设每笔交易对应数据库事务数=20，基准TPC指标值对应的比例=8，cpu保留30%的处理能力冗余，计算值与公布值（最优值）的偏差经验值为4 （这几个参数估算的依据不足，更多的是经验值）

则 tpmC值为：

tpmC= 672084/(1-30%)= 61257[颠峰处理能力时（笔/分）每笔交易对应数据库事务数基准TPC指标值对应的比例计算值与公布值（最优值）的偏差经验值/（1- cpu保留30%的处理能力冗余）

倒算出综合系数 = 61257/10000=6.1即数据库服务器tpmC= 每日前台交易数 * 6.1 （实际计算值应不高于该值）

应用服务器的 tpmC = 数据库服务器 tpmC *50% （一般）

应用服务器的 tpmC = 数据库服务器 tpmC *70% （涉及大量计算的，如社保、税务）

5.3. 参考3

当前电信业已进入群雄并起、竞争极端激烈的战国时代,在话音、数据和各种增值服务等领域国内各电信运营商，在高端和低端的不同层次上，展开了大规模的中原逐鹿。在如此复杂的局面下，在众多繁复的业务种类竞争中，如何保证一个电信企业的良好运作，建立一个顺畅的收入现金流至为重要。这也就是为什么电信企业在计费系统上进行了不遗余力的投资。但是，正是业务种类层出不穷的推出、通信模式和接入技术快速进步，使电信计费系统存在着难以满足需要的局面，往往制约了电信的运营和业务的开展。如何建立一套能够满足当前乃至今后一定时间的业务开展，又能够保证安全稳定易管理的电信综合计费系统，是各电信运营商和电信科研单位极为重视的一个课题。下面结合中国网通的计费系统建设经验，为即将建设的计费系统的服务器选型方面提供一些建议和参考。

电信计费系统通常有如下种类的服务器:

接口服务器
认证服务器
计费服务器
采集服务器
数据库服务器
管理工作站等

其中，核心服务器为计费服务器、认证服务器和数据库服务器。在一些小型的计费系统中，接口服务器可以与采集服务器合一，计费服务器可以与认证服务器，甚至与数据库服务器合一,管理工作站也可以不设置专用工作站，而用 WEB 管理方式。

对于这些服务器，用途不同，在不同规模的计费系统方案中的组合也不同，业务规模也对服务器的处理性能、存储性能、开放等性能需求不同。选择适当的服务器，不仅能够充分满足业务开展所雲，而且能够提供为未来业务发展所需的系统扩展能力，这样既保障了运营，又能够节省投资。下面对计费系统的服务器选型、处理性能换算方法提出一些参考建议。

服务器处理性能计算方法

按照电信计费系统的统计经验值，一般每1万用户配置5个终端，通常同时访问数据库的终端数目概率为 20%，每次访问请求需处理1秒，其中平均要完成5个交易，由此需要的服务器处理性能为:

用户数x5x206x5x60/(10000x1)(TpmC)

5.3.1. 选型参考建议

标准化原则

符合 ISO 和 ANSI 标准，符合 SVRV4 标准，符合中国的有关计算机技术标准，选择当今业界较为流行的主要产品

高性能原则

保证所选购的服务器,不仅能够满足运营系统的运行和业务处理的需要,而且能够满足一定时期的业务量增长的需要。采用上面公式，计算出所需的服务器 TpmC 值，比较 IDC 公布的权威测算的厂商服务器 TpmC 值，选择相应的机型。同时，用服务器的市场价/报价除上计算出来的TpmC 值得出单位 TpmC 值的价格，从而选择高性能价格比的服务器。

可靠性原则

可靠性原则是所有选择设备和系统中要考虑的，尤其是在大型的、有大量处理要求的、需要长期运行的系统。

考虑服务器系统的可靠性，不仅要考虑服务器单个节点的可靠性或稳定性，而且要考虑服务器与相关辅助系统之间连接的整体可靠性，如:网络系统、安全系统、远程打印系统等。在必要时，还应考虑对关键服务器采用集群技术，如:双机热备份或集群并行访问的N+n技术，甚至采用可能的完全容错机。

保证系统(硬件和操作系统)在 99.98%的时间内都能够正常运作(包括维修时间),则故障停机时间六个月不得超过 0.5 个小时。服务器需 7x24 小时连续运行，因而要求其具有很高的安全可靠性。系统整机平均无故障时间(MTBF)不低于 80000 小时。

服务器如出现 CPU 损坏或其它机械故障,都能在 20 分钟内由备用的 CPU 和机器自动代替工作，无须人员操作，保证数据完整。

可扩展性原则

保证所选购的服务器具有优秀的可扩展性原则。因为服务器是所有系统处理的核心，要求具有大数据吞吐速率，包括:I/0 速率和网络通讯速率，而且服务器需要能够处理一定时期的业务发展所带来的数据量，需要服务器能够在相应时间对其自身根据业务发展的需要进行相应的升级，如:CPU 型号升级、内存扩大、硬盘扩大、更换网卡、增加终端数目、挂接磁盘阵列或与其他服务器组成对集中数据的并发访问的集群系统等。这都需要所选购的服务器在整体上具有一个良好的可扩充余地。

一般数据库和计费应用服务器在大型计费系统的设计中就会采用集群方式来增加可靠性,其中挂接的磁盘存储系统，根据数据量和投资考虑，可以采用 DAS、NAS 或 SAN 等实现技术。对于 Redius Server 可以依靠 Redius 协议采用双机互备，但不需要专门购买的集群软件。

安全性原则

服务器处理的大都是相关系统的核心数据,其上存放和运行着关键的交易和重要的数据。这些交易和数据对于拥有者来说是一笔重要的资产，他们的安全性就非常敏感服务器的安全性与系统的整体安全性密不可分，如:网络系统的安全、数据加密、密码体制等。服务器需要在其自身，包括软硬件，都应该从安全的角度上设计考虑，在借助于外界的安全设施保障下，更要保证本身的高安全性。

如图中所示的认证服务器(Redius Server)和 AAA Server，保障用户访问的合法性，防火墙和服务器的口令甚至一次性口令系统等则保障着系统和数据的安全,有的系统还采用了数据加密和线路加密等手段。

可管理性原则

服务器既是核心又是系统整体中的一个节点部分,就像网络系统需要进行管理维护一样，也需要对服务器进行有效的管理。这需要服务器的软硬件对标准的管理系统支持,尤其是其上的操作系统，也包括一些重要的系统部件。如 Management Station，它既可以是基于 B/S 结构的专用管理软件系统，也可以是基于SNMP 或 WEB 的通用管理方式的软件系统。

5.3.2. 如何规划和选择数据库服务器?

举例说明，使用 TPC-C进行数据库服务器评估

下面针对 XYZ 行的网上银行业务的需求，我们进行数据库服务器的选型分析。

由于目前 XYZ 行只有 17 个分行开通了网上银行业务，据我们估计，按照目前的客户数量全部分行都开通网上银行业务后，总的客户数量可以达到10万。考虑INTERNET 在我国的迅猛发展,客户数量的年增长率按照 50%计算,那么,3年后的客户数量将达到 10万x(1+50%)3≈34万。

这些客户当中，至少有一半是个人客户，另一半是企业客户。企业客户的交易频率比较高我们按平均每个企业客户每天做 1.5 笔交易计算:个人客户常用的交易是査询、取款、存款，并且每个月还要交电话费，因此我们假定个人客户平均每个月做4次交易;那么，每天的交易量就是:

34万x50%x1.5+34万x50%x(4+30) ≈28万笔

假设网上银行的交易复杂度达到 15，那么，每天的数据库操作数达到:

28 万x15=420 万次

5.3.2.1. 高法诉讼费缴费:

由于诉讼费的增长量不大，我们按年递增率 5%计算。根据 XYZ 总行的统计，全国共 37 家分行，缴费量比较大的分行可以达到 25000 笔每月，占分行总数的 20%:缴费量中等的省可达到15000 笔每月，占分行总数的 30%;缴费量小的省可达到 7000 笔每月，占分行总数的 50%;按个月 20 个工作日计算。这样，三年后每天的交易数量可以达到:

(25000x20%+15000x30%+7000x50%)x37-20x(1+5%)3≈28740笔

我们假设高法诉讼缴费的交易复杂度达到13，那么每天的数据库操作达到:

28740*13=373620 次

5.3.2.2. 整体性能要求:

总的数据库操作次数是:4200000+373620=4573620

假设每天的交易的 80%集中在4小时内发生，那么高峰交易时间内每分钟的数据库联机交易次数为:4573620x80%÷(4x60)≈15250

要为将来陆续加入的应用预留 40%的处理能力;另外,考虑到 CPU 的繁忙时间低于 70%时,系统的性能较好，我们把这个比例定在 65%。所以系统的 TPC-C 值应达到:15250-(1-40%)-65%≈39000

5.3.2.3. 内存容量需求分析

首先根据数据库容量算出所需的数据库缓存大小,再估计出操作系统、系统软件等所需内存,合计即是所需的内存容量

5.3.2.4. 网银数据量分析:

XYZ 总行网上银行系统的数据库由 CIF 信息，交易日志、交易流水三部分组成。

其中:CIF 信息包括企业客户和个人客户信息，企业客户信息平均大小为 20K 左右，个人客户信息平均大小为 5K 左右;每一笔交易都要记交易日志,日志的平均大小为 4K 左右;每一笔转帐交易都要记交易流水，交易流水的大小为2K左右。

这些客户当中，至少有一半是个人客户，另一半是企业客户。企业客户的交易频率比较高，我们按平均每个企业客户每天做 1.5 笔交易计算:个人客户常用的交易是查询、取款、存款，并且每个月还要交电话费，因此我们假定个人客户平均每个月做4次交易;那么，每天的交易量就是:

所有的交易日志和交易流水都要保留三个月。由于个人客户的转帐交易非常少，可以忽略不计;假定企业客户的转帐交易占总交易量的 70%。我们就可以计算网上银行对存储系统容量的要求:

CIF 信息容量=20Kx(34万x50%)+5Kx(34万x50%)=3.25GB+421MB≈4GB

交易日志容量=[34万x50%x1.5+34万x50%x(4÷30)]x4Kx30x3 =277667x4Kx30x3~95GB

交易流水容量=(34万x50%x1.5)x70%x2Kx30x3 ≈30GB

XYZ 网上银行总体数据容量要求:=4GB+95GB+30GB=129GB

5.3.2.5. 高法诉讼费数据量分析:

高法的交易数据按要求要保留三年，每笔交易记录的大小为512字节，总体容量为:(25000x20%+15000x30%+7000x50%)x37x12x3x0.5K≈8.2GB

因此，数据库的总数据量为:129GB+8.2GB=137.2GB

数据库系统在缓存容量达到数据库总容量的5%时性能较好，因此，数据库缓存大小为:6.86GB。

5.3.2.6. 从而计算出系统内存需求为:

AIX操作系统所占的内存 128MB
数据库管理系统所占的内存 256MB
双机热备等系统软件所占的内存 128MB
应用程序所占的内存 256MB
数据库缓存 6.86GB
合理的内存利用率 75% 总计 10GB

5.3.2.7. 存储容量需求分析

除了上述的 XYZ 网上银行系统和高法诉讼费缴费系统的存储容量要求之外，还有异步查询下载服务的存储要求。

异步查询下载服务每隔1小时生成一个下载数据包，每个数据包的大小为 3MB，需要下载的数据包是上午十点生成的数据包，这个数据包需要保存2年，其它数据包只要保存3个月。因此，存储容量为:

23x3Mx30x3+1x3Mx365*2=6GB+2GB=8GB

为避免存储系统成为系统性能的瓶颈，系统存储系统的使用率应小于40%，建议采用镜像方式存储数据，因此总的存储容量为: (137.2GB+8GB)+40%x2=766GB HP 银行参考 TPC-C 测算参考以下吧!!

日峰值交易量，即每天业务高峰时的交易量，根据经验以在2小时内完成日均交易量的 80%为计算依据。

日峰值交易量=日均交易量x80%/2=104000(笔/小时)

月峰值日集中系数，即在每月的最忙日最忙时，其峰值交易量要高于根据上式计算出的平均日峰值交易量,为了使主机能够从容处理每月中的最高峰值交易量,在平均日峰值交易量的基础上考虑一个月峰值日集中系数，根据业务繁忙程度取值 1.5~3，根据###的具体情况，在这里取值1.5 。则:

104000x1.5÷3600 =43(笔/秒)

根据软件的测试结果，软件软件交易处理能力与计算机厂商公布的TPmC值之间的比例关系为1:4。由此，可得出###需主机系统的 TPmC 值:主机系统的处理能力为:43 x4x60=10320TPmC综合以上数值，####系统所需最大处理能力约为 10320TPmC

nightcat 兄，谢了?我也得到一个数据如下:跟据 xx银行提供的数据，目前的业务量为:日均5万笔日均交易量为5万笔。设 M 为每日实际交易量，则M=50,000

设T为每日实际交易时间或实际统计值，我们假设高峰期每日交易量在每天的2小时即 120 分钟内完成:T=120 标准交易指标值TPC-C对应于实际交易值比例为:MO=15:1应保证 50%(M1)的主机 CPU 处理余量，用于系统、数据库、工具软件、监控软件或其它应用系统的使用因此，对应计算得标准 TPC-C 估计值为:

TPC=M x MO/(T xM1)=50000x15/(120x50%)=12500

还应考虑系统业务未来三年的发展，每年增长率按 30%计算，得出的 TPC 值为:

TPC=12500x 1.3 x1.3x1.3=27462.5

5.4. 参考4

服务器系统作为劳动和社会保障各级数据中心的核心设备，提供计算处理服务、网络应用服务、劳动保障业务应用服务和其他服务。根据部省市局域网的逻辑构成，劳动保障信息系统的服务器设备包括数据库服务器、应用服务器、WEB 服务器、DNS 服务器等。服务器的配置应根据各级各类应用的不同规模和特点，并结合处理速度、存储容量、可靠性、系统开放性、性能价格比等因素来进行选择。

数据层服务器作为业务系统的核心，具有业务量大、存储量大等特点。它承担着业务数据的存储和处理任务,因此关键数据库服务器的选择就显得尤为重要。服务器的可靠性和可用性是首要的需求，其次是数据处理能力和安全性，然后是可扩展性和可管理性。为保证劳动保障信息系统持续稳定高效地运行，须保证服务器数据存储系统较高的可靠性、扩展性和灾难恢复能力。

基于RISC 系统的高中端服务器系统是适用于数据库服务器的选择，可根据具体业务需求和投资情况选择双机集群和单服务器系统，应用层服务器承担着业务系统的各类应用服务，主要强调其强大的计算能力，能够处理大量的并发连接处理，并能在用户数增加的情况下保持良好的性能平衡。

除此之外，能够提供连续可用的可靠性，能够适应各种网络环境的扩展能力也是需要考虑的因素。基于 RISC 系统的中低端服务器系统或高中端 PC服务器系统是适合于应用层服务器的选择,可根据具体业务需求和投资情况选择双机集群和单服务器方案。

其他服务器，如WEB 服务器、DNS 服务器等，要根据具体应用和投资要求在可靠性和处理能力等方面综合考虑。可采用中低端PC服务器系统。

下面以省级数据中心交换区数据层服务器为例，详细阐述服务器选型的方法。

省级数据中心交换区数据层服务器中作为社会保险关系异地转移、离退休人员异地数据交换和异地就医数据交换的数据库服务器，支持在职人员社会保险关系跨市转移的信息交换，以及异地领取养老金相关信息(如人员的基本状况、支付标准、生存状况等)的交换，同时保存死亡信息和公共服务信息、临时缓存宏观决策上报数据和基金监管信息。

考虑其作为中央、省、市三级数据中心信息交换的枢纽，所支撑应用的关键性，应采用基于 RISC 系统的高端服务器系统，具体配置要求如下:

5.4.1. 服务器处理能力

为支持本省的异地转移、异地就医和异地领取养老金等业务，需要较高的交易数据处理能力。

TPC 计算如下:

设: 全省参保总人数 C=980 万

交易日平均交易人数比例 a1=1%

每笔交易对应数据库事务数 a2=5

则:每日实际交易量 M= Cxa1xa2

交易日集中交易时间 T=120 分钟

交易日集中期内交易量比例 Ct=80%基准 TPC 指标值对应实际交易值的比例 MO=6:1CPU 处理能力余量 M1=30%-45%，取 35%

3年内每年处理能力增长率 P=30%

根据经验公式TPC=(MxM0xCt/(Tx(1-M1))x(1+30%)3=89,435

服务器选型考虑采用 TPC 值不低于 100,000 的高端服务器系统配置。

内存容量根据经验和类似业务量和环境，内存容量应为 1G/CPUxCPU数，从目前主流硬件厂商的指标来看，TPC 值要达到 100，000，一般需要配置8个CPU，因此内存建议配置 8GB.
总线带宽在高 CPU、大容量内存的配置下，必须要求主机系统总线带宽、/0 总线带宽都达到很高,否则,系统性能将形成瓶颈。
存储容量交换区平均数据量为 164.8GB，峰值数据量为 164.8GBx1.5，考虑 0.2倍的数据库索引和系统占用空间;作 RAID 保护后 60%存储利用率;以后数据增长，需提供 30%的数据扩充能力等因素，总存储容量约为:164.8x1.5x1.2160%170%=706GB，采用 SAN 中的光纤通道阵列作为数据存储.
可靠性、扩展性等

由于作为生产型数据库服务器，支持异地经办业务，属于实时性服务，该服务器系统在可靠性方面要求较高，可靠性必须达到 99.99%以上，提供全年 7x24 的可用性，配置为双机集群方式。系统采用多部件的冗余结构设计，具有高速差错校验和纠错的存储器，并有监控和诊断功能..

综上所述，对于在金保工程建设中服务器的选型，首先需对其业务系统的业务类型、业务复杂度等方面做系统的需求分析，其后根据需求在数据容量、数据处理的强度等方面进行估算，并兼顾服务器的可靠性、扩展性、安全性、可管理性等方面综合考虑，完成最终的产品选型。

5.5. 参考5

本工程合肥节点新建的处理能力以及用户容量规模如表1-1所示:

表1-1 本期工程 MMSC 处理规模

节点名称	用户容量	软件许可要求(MM/s)	软件许可要求(MM/s)	备注备注
合肥	200万	30	80	备注

5.5.1. 主要服务器处理能力

5.5.1.1. MMSC、数据库服务器和计费服务器

通常采用TPC-C指标衡量服务器的在线事务处理能力。TPC-C包括五种不同类型的即时处理或队列处理的并行交易混合，以分钟为单位计算。TPC-C的性能取决于计算机硬件、操作系统、数据库等多种因素。

目前MMS业务允许的消息大小为100KBytes，比短消息大3个数量级，其磁盘I/O，数据库访问所需要的服务器在线事务处理能力需求较高,华为公司经过测试得出不同的基本消息业务流程所需要的处理能力，如下表1-2所示:

单位:tpcC

表1-2 不同消息所需要的处理能力(单位:tpcC)

消息类型	MO	MT	EO	ET	AO	AT	FO	FT	系统保留(tpmC)
MMSC	6.3	7.8	8.6	9.8	8.5	8.2	8.2	8.3	1600
计费服务器	0.5	0.5	0.5	0.5	0.5	0.5	0.5	0.5	400
数据库服务器	0.5	0.5	0.5	0.5	0.5	0.5	0.5	0.5	400

考虑到基本格式转换需求，在EO/MT和MO/MT流程中进行字符集转换，进行字符集转换时相对于基本处理流程系统增加5%的处理能力开销。按本期工程要求，按照所有业务量的25%需要进行字符集转换配置系统。

在应用相关流程中，MMSC将业务请求传送给DSMP进行用户状态/订购信息的鉴权、认证以及批价操作，MMSC业务节点和计费服务器相对于基本业务流程需要增加相应的处理能力开销。

根据华为在广州进行DSMP功能测试的情况，与DSMP互联时增加的开销在13%左右，考虑到在现网业务情况相对复杂，与DSMP互联时业务节点和计费服务器相对于基本业务流程所需增加相应的处理能力开销取为15%。

根据本期工程需求，MMSC与DSMP进行互联时,接口处理能力按照不低于系统标称处理能力的15%业务量作为梦网业务进行考虑。

本期工程新增彩信计数器需求，根据华为公司相关产品的经验进行估计，进行计数器实时采集时，整个系统相对于基本业务流程需要增加5%的处理开销。

综合上述因素，消耗系统处理资源最大的业务流程为AO/FT业务流程，其处理能力要求为:(8.5+8.3)x(1+15%x15%)x(1+5%)=18.04 tpcC，华为MMSC设备选型即以此流程作为配置选型依据:

MMSC服务器

TPMC=每秒消息处理能力x60xTMs=80x60x18.04=86592(tpmC)

计费服务器

TPMC=每秒消息处理能力x60 xTi費x(1+DSMP增加的处理能力)-80x60x1x(1+15%x15%)=4908(tpmC)

Oracle数据库服务器

TPMC=每秒消息处理能力x60-80x60x1=4800(tpmC)

所需要的MMSC业务主机数=TPMC:(单机处理能力一系统保留处理能力)由上面的计算公式可得不同设备的处理能力如表1-3所示。

表1-3 不同设备的处理能力要求(单位:tpmC)

设备	处理能力	考虑 70%的系统利用率
MMSC	85592	122274
计费服务器	4908	7011
数据库服务器	4800	6857
合计	95300	136143
合计(计费和数据库，考虑 30%的冗余)	9708	13869

5.5.2. 配置建议

5.5.2.1. MMSC 业务主机

综合考虑MMSC业务特点，本工程建议选用V440和V490作为MMSC服务节点需要V440(4*1.28GHz)的单机数量计算如下:

86592÷(54612x0.7-1600)=2.36(台)

考虑冗余节点，及MMSC相互之间互备，实际配置4台V440(4*1.28GHz)的小型机，组成2套双机，相互之间互备每台主机所需要的内存为:

9.16÷4-2(系统保留)=4.29(G)

综上，本工程需要选用4CPU、8G的V440四台(2套双机，其中1台单机冗余)，作为4个MMSC业务集群节点，相互之间两两互备。