摘 要 对相关TPC估算方法进行了探讨，并结合工程实际总结出了一套计算服务器处理能力的通用估算方法。
关键词 TPC基准值 数据处理能力 计算公式
０ 前言
近年来，随着计算机技术的不断普及，不同种类的应用系统在各个行业发挥着举足轻重的作用。同样，在高速发展的通信领域，大量的应用系统被开发和使用，例如业务支撑系统（BSS）、运营支撑系统（OSS）、办公自动化（OA）等。但是，如果期望应用系统能够达到建设之初的预想效果，除加强对软件功能和设计质量控制外，对硬件设备的合理配置也是重要的环节之一。
通常而言，一套完整的应用系统都是由硬件和软件部分构成的，只不过具体配置和实现功能存在差异。合理的硬件配置必须满足软件对于CPU处理能力、内存容量以及存储容量的需求，并能满足系统未来一段时期内的变化，富余一定冗余量。涉及这类项目设计，采用合理的方案估算系统所需处理能力是正确选择硬件配置的前提。系统处理能力的估算有以下难点。
a） 软件系统所需的数据处理能力涉及到很多暂时无法确定的方面（如软件自身的功能设计、编码水平、数据结构等因素），较难用数据方法精确计算。
b） 软件和硬件系统之间应有统一的单位换算方法。
因此，希望有一种国际标准，能够量化系统的性能，以此作为设备选型的依据。
本文以事务处理性能委员会（TPC）提供的基准估算理论为核心，结合案例探讨使用tpmC值计算系统所需的硬件系统处理能力。
1 TPC标准介绍
在对系统进行方案设计时，通常会遇到下列问题。
a） 配置什么样的服务器设备？
b） 系统性能如何？
c） 系统能够满足多长时间的应用？
单凭历史经验给出一个经验值来评估整套系统显然是不够的，必须拿出足够的理论证据来证明设计中已考虑到了上述问题。通常，采用TPC的基准测试来衡量硬件服务器的处理能力，同时，采用通用计算公式估算软件所需的处理能力。
1.1 TPC
TPC是由数10家会员公司创建的非盈利组织，总部设在美国。该组织对全世界开放，但迄今为止，绝大多数会员都是美、日和西欧的大公司。TPC的成员主要是计算机软硬件厂家，而非计算机用户，它的功能是制定商务应用基准程序的标准规范、性能和价格度量，并管理测试结果的发布。
TPC的测试结果和出版物是开放的，可以通过网站（http：//www.tpc.org）获取详细信息。IBM、NCR、HP、SUN等国际著名服务器供应商均是TPC会员，这些公司旗下的产品均会在网站上公布TPC的测试结果。目前，国内的工程项目中大量采用了上述公司制造的服务器类产品，因而这些数据对于设计阶段的性能估算很有参考价值。
至今，TPC已经推出了4套基准程序（TPC-A、TPC-B、TPC-C和TPC-D）。其中TPC-A和TPC-B已经过时，不再使用。TPC-C是在线事务处理（OLTP）的基准程序，TPC-D是决策支持的基准程序。目前，工程设计中常见的系统均为在线事务处理型（包括BSS、OSS和OA），因此TPC-C基准测试是本文关注的重点。
1.2 TPC-C基准测试
TPC-C是一种旨在衡量OLTP系统性能与可伸缩性的行业标准基准测试项目。这种基准测试项目将对包括查询、更新及队列式小批量事务在内的广泛数据库功能进行测试。许多数据专业设计人员将TPC-C视为衡量“真实”OLTP系统性能的有效指示器。
TPC-C基准测试是对硬件处理能力的考核标准。TPC-C通过模拟一个批发商的货物管理系统，衡量硬件服务器的性能指标（查询、统计功能的执行效率）。TPC对具体的测试环境，也做了详细的规定。
1.2.1 测试环境
批发公司有N个仓库，每个仓库供应10个地区，其中每个地区为3 000名顾客服务。每个仓库中有10个终端，每个终端用于一个地区。在运行时，10×N个终端操作员向公司的数据库发出5类请求。
1.2.2 逻辑和流程
该系统需要处理的交易有以下几种。
a） New-Order：客户输入一笔新的订货交易。
b） Payment：更新客户账户余额，以反映其支付状况。
c） Delivery：发货（模拟批处理交易）。
d） Order-Status：查询客户最近交易的状态。
e） Stock-Level：查询仓库库存状况，以便能够及时补货。
从上述定义可见，数据库在逻辑上是分布的。而N是一个可变参数，测试者可以随意改变N，以获得最佳测试效果。图1示出的是TPC-C测试逻辑结构图；图2示出的是TPC-C测试流程图。
1.2.3 评测指标
TPC-C基准测试针对一种模拟订单录入与销售环境测量每分钟商业事务吞吐量。按照TPC的定义，流量指标tpmC描述了系统在执行Payment、Delivery、Order-status、Stock-Level这4种交易的同时，每分钟可以处理多少个New-Order交易。所有交易的响应时间必须满足TPC-C测试规范的要求。
最终的测试结果会在TPC的网站上公布，可以免费查询到绝大部分的系统测试结果。测试信息包括tpmC得分、系统配置清单、测试环境以及日期等，内容非常详尽。
2 服务器处理性能估算
2.1 估算方案
在方案设计之前，必须详细了解用户需求，特别关注以下几点。
a） 系统的设计使用年限。
b） 系统平均用户在线人数（访问量）。
c） 系统忙时，用户的主要操作行为统计（估值）。
d） 软件开发商应提供的功能架构，并能提供每个功能所引发的事务处理量。
e） 系统采用的操作系统和数据库平台。
在充分采集系统信息后，可对系统所需服务器性能进行3个方面的估算。
a） 数据服务器处理能力估算。
b） 应用服务器处理能力估算。
c） 存储容量估算。
值得指出的是，应用服务器和数据服务器是2个不同的概念。应用服务器提供访问商业逻辑的途径以供客户端应用程序使用。数据服务器主要负责计算和数据存储。在大型系统中应用和数据会独立使用各自的服务器，降低服务器压力并尽可能保障数据安全和独立。
2.1.1 数据服务器性能估算
测算服务器在忙时的数据库访问峰值（X），代表主机处理峰值应能达到每秒X个连接；每个连接平均需要访问Y个数据表。每个数据库访问相当于服务器Z的处理能力。数据服务器处理性能（Ls）的估算公式为
Ls=XYZ/（1-β）/γ （1）
式中：
X——用户连接数（连接/s）
Y——数据表连接数
Z——数据访问值（tpm）
β——系统自身消耗值，取值范围为25%~35%
γ——系统忙时比例因子，取值范围为60%~80%
2.1.2 应用服务器性能估算
1） 方法一：估值计算
应用服务器处理性能（Ly）的估算公式为
Ly=Lsα （2）
式中：
α——综合系数（见表1）
2） 方法二：TPC公式计算
TPC建议使用式（3）估算所需处理能力。假定在系统发出的业务请求中，位列前三项的功能（如查询、更新、统计功能等）分别命名为A、B、C，则应用服务器需要的处理能力为
Ly=U1N1（T1+T2+T3）/3XY/Z （3）
式中：
U1——系统同时在线用户数（人）
N1——平均每个用户每分钟发出业务请求次数（次/人）
T1——平均每次A业务产生的事务数（次）
T2——平均每次B业务产生的事务数（次）
T3——平均每次C业务产生的事务数（次）
X——一天内忙时的处理量和平均数的比值
Y——经验系数（实际量和估算量的比值）
Z——服务器冗余值
方法一和方法二均为常用的处理能力估算方法。方法一更为简便，但相对方法二缺乏说服力和准确性。因此，建议尽量使用方法二进行估算。
2.1.3 存储容量估算
系统的存储空间主要包含4大内容数据。
a） 软件系统自身所需安装空间。
b） 系统运行环境所需安装空间（操作系统、数据库软件、其他第三方软件等）。
c） 系统运行产生的数据。
d） 系统日志所需空间。
实际存储容量（G）计算公式为
设计存储容量（Gs）计算公式为
Gs=G（1+Z） （5）
式中：
A——每条记录占用存储空间（Byte/条）
B——每天产生的记录条数（条）
F——每天系统日志占用空间（Byte）
C——设计使用年限（年）
D——软件系统自身安装空间（GByte）
E——运行环境所占安装空间（GByte）
Z——存储冗余
通常情况下，为了确保数据安全性，系统备份时会将数据存放在其他独立的备份设备中。因此，在存储容量估算中暂不考虑系统备份所需的容量需求。
通过前面3个步骤的计算，就能大致掌握系统数据服务器、应用服务器以及存储容量上需求值。结合TPC网站上公布的测试数据和厂商提供的相关设备的tpmC数据，就能做出比较明确的判断。同时，计算数据也是设备选型和设备配置的重要设计依据。
2.2 案例分析
某建设单位委托设计一套基于B/S技术的传输资源管理系统。通过采集用户需求并咨询相关软件开发商和硬件厂商，获取了以下信息。
a） 系统设计使用年限5年。
b） 项目实施后，用户之间可以通过系统查询现网的传输架构和资源使用情况。同时，用户可以定期统计传输资源使用情况并及时更新系统信息。
c） 估算系统平均用户在线人数100人。
d） 软件开发商提供的系统参数，包括主要功能操作所产生的事务处理个数、每条记录占用的存储空间等信息。
e） 软件指令行数估计20万行左右。
f） 数据库系统为Oracle 9i，并采用RAC方式。
特别说明，该项目采用Oracle 9i数据库平台，并使用真正应用集群（RAC）方式。RAC是Oracle 9i数据库中采用的一项新技术，也是Oracle数据库支持网格计算环境的核心技术。使用该技术能大大提高数据处理效率并降低安全风险，是目前最为流行的数据库平台之一。RAC技术能使多个服务器上的多个Oracle实例同时管理一个数据库，因此必须配置2台以上数据服务器组成数据集群。综合用户需求、厂商建议和机房勘察结果，拟选用1台服务器作为应用服务器，2台数据服务器组成数据集群，以满足Oracle 9i RAC的需要。图3示出的是系统逻辑拓扑图。
在掌握基础数据后，根据上一章介绍的估算方案对数据服务器、应用服务器和存储容量进行需求量计算。
2.2.1 数据服务器TPC-C计算
每秒峰值为6 000连接/s，即主机处理峰值应能达到6 000连接/s；每个连接平均需要10个数据表访问，按照经验，每个数据库访问相当于服务器3~4 tpm的处理能力。系统本身要消耗30%的系统资源（厂商提供参考值）；系统忙时比例因子为70%（厂商提供参考值）。将上述值代入式（1）有：
Ls=6 000×10×4/（1-30%）/70%=489 796
因此，数据库双机系统TPC-C要求大于或等于500 000 tpm，考虑实现Oracle 9i RAC后，双机性能约是单机的1.8倍，因此，单机TPC-C值不能小于500 000/1.8≈278 000 tpm。
2.2.2 应用服务器TPC-C计算
1） 方法一：估值计算
本系统程序指令行数约为20万行，属于中型系统。根据式（2），可得到应用服务器所需处理能力。
Ly=500 000×0.5=250 000 tpmC
2） 方法二：TPC公式计算
系统最大同时在线用户数为300人； 估算平均每个用户每分钟发出3次业务请求；系统发出的业务请求中，更新、查询、统计各占1/3；平均每次更新业务触发10个事务；平均每次查询业务触发15个事务；平均每次统计业务触发30个事务；一天内忙时的处理量为平均值的8倍；约定经验系数为1.6（实际工程经验）；服务器冗余值为30%。根据式（3），可得到应用服务器所需处理能力。
Ly=300×3×（10+15+30）/3×7×1.6/0.7≈264 000 tpm
方法一和方法二计算的结果比较接近，建议采用较大的值作为最终估算结果。
2.2.3 存储容量计算
传输资源管理系统中主要存统计报表数据以及日志管理信息。在已经考虑了数据冗余的前提下，约定：每天每个功能模块生成20个统计报表；目前系统共有10个功能模块；每条报表记录平均占用存储空间300 B；每年的预算数据存储容量需求为21.9 GB；每月的日志数据存储容量需求为0.1 GB；设计使用年限为5年；软件系统自身安装空间为1 GB；运行环境所占安装空间为5 GB （包含操作系统和数据库） ；存储冗余为30%；全年总共所需存储容量为：21.9+12×0.1+1+5=29.1 GB
5年存储容量为：5×29.1×（1+0.3）=189.15 GB
2.2.4 配置说明
完成数值估算后，建议把计算结果以表格的形式进行归纳总结（见表2），方便用户查阅。
3 建议
基于TPC-C标准的服务器性能估算方法，其中很多参数也是平均估值和经验估值，计算结果只能作为参考。在实际应用中，决定系统性能的因素除了硬件、系统软件外，应用软件的设计质量也非常重要。正是由于存在这些不确定的因素，估算值往往和实际值有一定的偏差。为了尽量减少偏差值，建议设计人员务必做好以下几点。
a） 工程前期，详细了解用户需求，准确把握用户最关心的热点问题。例如：系统用户群、建设的主要目的和建设目标、要实现的功能描述等等。
b） 了解整个系统架构、实现方法和功能设计也非常重要。在TPC估算中，很多参数和系统的架构设计有关，准确掌握系统的设计特点和数据参数对计算的准确性很有帮助。
c） 如果某些参数确实无法获取，建议把参数适当估得大些，确保未来系统能正常运行。
放眼长远，在系统实施前可以加强对项目的监控，并建立项目评估机制。项目实施后记录系统实际运行情况，掌握项目估算值和实际值的偏离度，作为其他项目的经验参考数据。
a） 通过对各业务系统运行情况的调查，进行历史数据的收集分析，按分类建立基准指标库。收集的信息包括服务器的配置、并发用户数（每天业务量）、CPU/存储负荷等。
b） 工程实施后，由厂商配合对系统性能进行评估，提供性能测试数据。通过实际测试，可以掌握系统在真实环境下的TPC值，有助于积累经验，修正计算参数。
c） 硬件厂商提供的TPC-C得分是在实验室环境下获取的，和实际值往往有出入。因此，对硬件服务器进行现场测试，并将测试数据建立档案库很有必要。这些数据不仅可以用于评估项目建设方案中的服务器选型，也可以对已实施项目提供升级优化指导。
4 结束语
系统处理能力TPC估算方法是一种工程参数结合经验参数的通用计算方法。但是，由于计算公式涉及的参数较多而且一些参数为经验值，计算的结果仅能作为系统配置和选型的参考。尽管有这些不足，基于TPC-C标准的系统处理能力估算仍不失为一套简单有效的系统性能计算方法。
参 考 文 献
1 （美）TPC-C and TPC-D V.1.X Overview Presentations，http：//www.
tpc.org，2005
2 （美）James Johnson. 数据库[M]. 北京：电子工业出版社，2004
（来源：邮电设计技术 2008年03期 作者：周承诚）
关键词 TPC基准值 数据处理能力 计算公式
０ 前言
近年来，随着计算机技术的不断普及，不同种类的应用系统在各个行业发挥着举足轻重的作用。同样，在高速发展的通信领域，大量的应用系统被开发和使用，例如业务支撑系统（BSS）、运营支撑系统（OSS）、办公自动化（OA）等。但是，如果期望应用系统能够达到建设之初的预想效果，除加强对软件功能和设计质量控制外，对硬件设备的合理配置也是重要的环节之一。
通常而言，一套完整的应用系统都是由硬件和软件部分构成的，只不过具体配置和实现功能存在差异。合理的硬件配置必须满足软件对于CPU处理能力、内存容量以及存储容量的需求，并能满足系统未来一段时期内的变化，富余一定冗余量。涉及这类项目设计，采用合理的方案估算系统所需处理能力是正确选择硬件配置的前提。系统处理能力的估算有以下难点。
a） 软件系统所需的数据处理能力涉及到很多暂时无法确定的方面（如软件自身的功能设计、编码水平、数据结构等因素），较难用数据方法精确计算。
b） 软件和硬件系统之间应有统一的单位换算方法。
因此，希望有一种国际标准，能够量化系统的性能，以此作为设备选型的依据。
本文以事务处理性能委员会（TPC）提供的基准估算理论为核心，结合案例探讨使用tpmC值计算系统所需的硬件系统处理能力。
1 TPC标准介绍
在对系统进行方案设计时，通常会遇到下列问题。
a） 配置什么样的服务器设备？
b） 系统性能如何？
c） 系统能够满足多长时间的应用？
单凭历史经验给出一个经验值来评估整套系统显然是不够的，必须拿出足够的理论证据来证明设计中已考虑到了上述问题。通常，采用TPC的基准测试来衡量硬件服务器的处理能力，同时，采用通用计算公式估算软件所需的处理能力。
1.1 TPC
TPC是由数10家会员公司创建的非盈利组织，总部设在美国。该组织对全世界开放，但迄今为止，绝大多数会员都是美、日和西欧的大公司。TPC的成员主要是计算机软硬件厂家，而非计算机用户，它的功能是制定商务应用基准程序的标准规范、性能和价格度量，并管理测试结果的发布。
TPC的测试结果和出版物是开放的，可以通过网站（http：//www.tpc.org）获取详细信息。IBM、NCR、HP、SUN等国际著名服务器供应商均是TPC会员，这些公司旗下的产品均会在网站上公布TPC的测试结果。目前，国内的工程项目中大量采用了上述公司制造的服务器类产品，因而这些数据对于设计阶段的性能估算很有参考价值。
至今，TPC已经推出了4套基准程序（TPC-A、TPC-B、TPC-C和TPC-D）。其中TPC-A和TPC-B已经过时，不再使用。TPC-C是在线事务处理（OLTP）的基准程序，TPC-D是决策支持的基准程序。目前，工程设计中常见的系统均为在线事务处理型（包括BSS、OSS和OA），因此TPC-C基准测试是本文关注的重点。
1.2 TPC-C基准测试
TPC-C是一种旨在衡量OLTP系统性能与可伸缩性的行业标准基准测试项目。这种基准测试项目将对包括查询、更新及队列式小批量事务在内的广泛数据库功能进行测试。许多数据专业设计人员将TPC-C视为衡量“真实”OLTP系统性能的有效指示器。
TPC-C基准测试是对硬件处理能力的考核标准。TPC-C通过模拟一个批发商的货物管理系统，衡量硬件服务器的性能指标（查询、统计功能的执行效率）。TPC对具体的测试环境，也做了详细的规定。
1.2.1 测试环境
批发公司有N个仓库，每个仓库供应10个地区，其中每个地区为3 000名顾客服务。每个仓库中有10个终端，每个终端用于一个地区。在运行时，10×N个终端操作员向公司的数据库发出5类请求。
1.2.2 逻辑和流程
该系统需要处理的交易有以下几种。
a） New-Order：客户输入一笔新的订货交易。
b） Payment：更新客户账户余额，以反映其支付状况。
c） Delivery：发货（模拟批处理交易）。
d） Order-Status：查询客户最近交易的状态。
e） Stock-Level：查询仓库库存状况，以便能够及时补货。
从上述定义可见，数据库在逻辑上是分布的。而N是一个可变参数，测试者可以随意改变N，以获得最佳测试效果。图1示出的是TPC-C测试逻辑结构图；图2示出的是TPC-C测试流程图。
1.2.3 评测指标
TPC-C基准测试针对一种模拟订单录入与销售环境测量每分钟商业事务吞吐量。按照TPC的定义，流量指标tpmC描述了系统在执行Payment、Delivery、Order-status、Stock-Level这4种交易的同时，每分钟可以处理多少个New-Order交易。所有交易的响应时间必须满足TPC-C测试规范的要求。
最终的测试结果会在TPC的网站上公布，可以免费查询到绝大部分的系统测试结果。测试信息包括tpmC得分、系统配置清单、测试环境以及日期等，内容非常详尽。
2 服务器处理性能估算
2.1 估算方案
在方案设计之前，必须详细了解用户需求，特别关注以下几点。
a） 系统的设计使用年限。
b） 系统平均用户在线人数（访问量）。
c） 系统忙时，用户的主要操作行为统计（估值）。
d） 软件开发商应提供的功能架构，并能提供每个功能所引发的事务处理量。
e） 系统采用的操作系统和数据库平台。
在充分采集系统信息后，可对系统所需服务器性能进行3个方面的估算。
a） 数据服务器处理能力估算。
b） 应用服务器处理能力估算。
c） 存储容量估算。
值得指出的是，应用服务器和数据服务器是2个不同的概念。应用服务器提供访问商业逻辑的途径以供客户端应用程序使用。数据服务器主要负责计算和数据存储。在大型系统中应用和数据会独立使用各自的服务器，降低服务器压力并尽可能保障数据安全和独立。
2.1.1 数据服务器性能估算
测算服务器在忙时的数据库访问峰值（X），代表主机处理峰值应能达到每秒X个连接；每个连接平均需要访问Y个数据表。每个数据库访问相当于服务器Z的处理能力。数据服务器处理性能（Ls）的估算公式为
Ls=XYZ/（1-β）/γ （1）
式中：
X——用户连接数（连接/s）
Y——数据表连接数
Z——数据访问值（tpm）
β——系统自身消耗值，取值范围为25%~35%
γ——系统忙时比例因子，取值范围为60%~80%
2.1.2 应用服务器性能估算
1） 方法一：估值计算
应用服务器处理性能（Ly）的估算公式为
Ly=Lsα （2）
式中：
α——综合系数（见表1）
2） 方法二：TPC公式计算
TPC建议使用式（3）估算所需处理能力。假定在系统发出的业务请求中，位列前三项的功能（如查询、更新、统计功能等）分别命名为A、B、C，则应用服务器需要的处理能力为
Ly=U1N1（T1+T2+T3）/3XY/Z （3）
式中：
U1——系统同时在线用户数（人）
N1——平均每个用户每分钟发出业务请求次数（次/人）
T1——平均每次A业务产生的事务数（次）
T2——平均每次B业务产生的事务数（次）
T3——平均每次C业务产生的事务数（次）
X——一天内忙时的处理量和平均数的比值
Y——经验系数（实际量和估算量的比值）
Z——服务器冗余值
方法一和方法二均为常用的处理能力估算方法。方法一更为简便，但相对方法二缺乏说服力和准确性。因此，建议尽量使用方法二进行估算。
2.1.3 存储容量估算
系统的存储空间主要包含4大内容数据。
a） 软件系统自身所需安装空间。
b） 系统运行环境所需安装空间（操作系统、数据库软件、其他第三方软件等）。
c） 系统运行产生的数据。
d） 系统日志所需空间。
实际存储容量（G）计算公式为
设计存储容量（Gs）计算公式为
Gs=G（1+Z） （5）
式中：
A——每条记录占用存储空间（Byte/条）
B——每天产生的记录条数（条）
F——每天系统日志占用空间（Byte）
C——设计使用年限（年）
D——软件系统自身安装空间（GByte）
E——运行环境所占安装空间（GByte）
Z——存储冗余
通常情况下，为了确保数据安全性，系统备份时会将数据存放在其他独立的备份设备中。因此，在存储容量估算中暂不考虑系统备份所需的容量需求。
通过前面3个步骤的计算，就能大致掌握系统数据服务器、应用服务器以及存储容量上需求值。结合TPC网站上公布的测试数据和厂商提供的相关设备的tpmC数据，就能做出比较明确的判断。同时，计算数据也是设备选型和设备配置的重要设计依据。
2.2 案例分析
某建设单位委托设计一套基于B/S技术的传输资源管理系统。通过采集用户需求并咨询相关软件开发商和硬件厂商，获取了以下信息。
a） 系统设计使用年限5年。
b） 项目实施后，用户之间可以通过系统查询现网的传输架构和资源使用情况。同时，用户可以定期统计传输资源使用情况并及时更新系统信息。
c） 估算系统平均用户在线人数100人。
d） 软件开发商提供的系统参数，包括主要功能操作所产生的事务处理个数、每条记录占用的存储空间等信息。
e） 软件指令行数估计20万行左右。
f） 数据库系统为Oracle 9i，并采用RAC方式。
特别说明，该项目采用Oracle 9i数据库平台，并使用真正应用集群（RAC）方式。RAC是Oracle 9i数据库中采用的一项新技术，也是Oracle数据库支持网格计算环境的核心技术。使用该技术能大大提高数据处理效率并降低安全风险，是目前最为流行的数据库平台之一。RAC技术能使多个服务器上的多个Oracle实例同时管理一个数据库，因此必须配置2台以上数据服务器组成数据集群。综合用户需求、厂商建议和机房勘察结果，拟选用1台服务器作为应用服务器，2台数据服务器组成数据集群，以满足Oracle 9i RAC的需要。图3示出的是系统逻辑拓扑图。
在掌握基础数据后，根据上一章介绍的估算方案对数据服务器、应用服务器和存储容量进行需求量计算。
2.2.1 数据服务器TPC-C计算
每秒峰值为6 000连接/s，即主机处理峰值应能达到6 000连接/s；每个连接平均需要10个数据表访问，按照经验，每个数据库访问相当于服务器3~4 tpm的处理能力。系统本身要消耗30%的系统资源（厂商提供参考值）；系统忙时比例因子为70%（厂商提供参考值）。将上述值代入式（1）有：
Ls=6 000×10×4/（1-30%）/70%=489 796
因此，数据库双机系统TPC-C要求大于或等于500 000 tpm，考虑实现Oracle 9i RAC后，双机性能约是单机的1.8倍，因此，单机TPC-C值不能小于500 000/1.8≈278 000 tpm。
2.2.2 应用服务器TPC-C计算
1） 方法一：估值计算
本系统程序指令行数约为20万行，属于中型系统。根据式（2），可得到应用服务器所需处理能力。
Ly=500 000×0.5=250 000 tpmC
2） 方法二：TPC公式计算
系统最大同时在线用户数为300人； 估算平均每个用户每分钟发出3次业务请求；系统发出的业务请求中，更新、查询、统计各占1/3；平均每次更新业务触发10个事务；平均每次查询业务触发15个事务；平均每次统计业务触发30个事务；一天内忙时的处理量为平均值的8倍；约定经验系数为1.6（实际工程经验）；服务器冗余值为30%。根据式（3），可得到应用服务器所需处理能力。
Ly=300×3×（10+15+30）/3×7×1.6/0.7≈264 000 tpm
方法一和方法二计算的结果比较接近，建议采用较大的值作为最终估算结果。
2.2.3 存储容量计算
传输资源管理系统中主要存统计报表数据以及日志管理信息。在已经考虑了数据冗余的前提下，约定：每天每个功能模块生成20个统计报表；目前系统共有10个功能模块；每条报表记录平均占用存储空间300 B；每年的预算数据存储容量需求为21.9 GB；每月的日志数据存储容量需求为0.1 GB；设计使用年限为5年；软件系统自身安装空间为1 GB；运行环境所占安装空间为5 GB （包含操作系统和数据库） ；存储冗余为30%；全年总共所需存储容量为：21.9+12×0.1+1+5=29.1 GB
5年存储容量为：5×29.1×（1+0.3）=189.15 GB
2.2.4 配置说明
完成数值估算后，建议把计算结果以表格的形式进行归纳总结（见表2），方便用户查阅。
3 建议
基于TPC-C标准的服务器性能估算方法，其中很多参数也是平均估值和经验估值，计算结果只能作为参考。在实际应用中，决定系统性能的因素除了硬件、系统软件外，应用软件的设计质量也非常重要。正是由于存在这些不确定的因素，估算值往往和实际值有一定的偏差。为了尽量减少偏差值，建议设计人员务必做好以下几点。
a） 工程前期，详细了解用户需求，准确把握用户最关心的热点问题。例如：系统用户群、建设的主要目的和建设目标、要实现的功能描述等等。
b） 了解整个系统架构、实现方法和功能设计也非常重要。在TPC估算中，很多参数和系统的架构设计有关，准确掌握系统的设计特点和数据参数对计算的准确性很有帮助。
c） 如果某些参数确实无法获取，建议把参数适当估得大些，确保未来系统能正常运行。
放眼长远，在系统实施前可以加强对项目的监控，并建立项目评估机制。项目实施后记录系统实际运行情况，掌握项目估算值和实际值的偏离度，作为其他项目的经验参考数据。
a） 通过对各业务系统运行情况的调查，进行历史数据的收集分析，按分类建立基准指标库。收集的信息包括服务器的配置、并发用户数（每天业务量）、CPU/存储负荷等。
b） 工程实施后，由厂商配合对系统性能进行评估，提供性能测试数据。通过实际测试，可以掌握系统在真实环境下的TPC值，有助于积累经验，修正计算参数。
c） 硬件厂商提供的TPC-C得分是在实验室环境下获取的，和实际值往往有出入。因此，对硬件服务器进行现场测试，并将测试数据建立档案库很有必要。这些数据不仅可以用于评估项目建设方案中的服务器选型，也可以对已实施项目提供升级优化指导。
4 结束语
系统处理能力TPC估算方法是一种工程参数结合经验参数的通用计算方法。但是，由于计算公式涉及的参数较多而且一些参数为经验值，计算的结果仅能作为系统配置和选型的参考。尽管有这些不足，基于TPC-C标准的系统处理能力估算仍不失为一套简单有效的系统性能计算方法。
参 考 文 献
1 （美）TPC-C and TPC-D V.1.X Overview Presentations，http：//www.
tpc.org，2005
2 （美）James Johnson. 数据库[M]. 北京：电子工业出版社，2004
（来源：邮电设计技术 2008年03期 作者：周承诚）
编辑回复