用户总希望有一种简单、高效的度量标准，来量化评价服务器系统，以便作为选型的依据。但实际上，服务器的系统性能很难用一两种指标来衡量。包括 TPC、SPEC、SAP SD、Linpack和HPCC在内的众多服务器评测体系，从处理器性能、服务器系统性能、商业应用性能直到高性能计算机的性能，都给出了一个量化的评价指标。在如此多的标准中，用户该如何选择最适合自身应用环境的评价体系呢?这里，我们选择了应用面较广泛的TPC和SPEC，作一个深入介绍。
■ 走出误区
深入TPC-C指标
TPC体系是影响最大的评测基准之一，尤其近两年，国内媒体对TPC指标的报道可谓海量。但有多少用户真正了解其中的含义呢?本文以TPC-C为例，让用户深入了解这项基准测试。
tpmC值在国内外被广泛用于衡量服务器系统的事务处理能力。但究竟什么是tpmC值呢?笔者曾向一些用户、专业媒体记者乃至某些国外大公司的技术人员问过这个问题，但回答的精确度与tpmC值的流行程度差异甚远。不少人将之误写为TPMC，甚至与TPC组织混为一谈。
TPC(Transactionprocessing Performance Council，事务处理性能委员会)是由数十家会员公司创建的非盈利组织，总部设在美国。TPC的成员主要是计算机软硬件厂家，而非计算机用户，其功能是制定商务应用基准程序的标准规范、性能和价格度量，并管理测试结果的发布。
TPC不给出基准程序的代码，而只给出基准程序的标准规范。任何厂家或其他测试者都可以根据规范，最优地构造出自己的测试系统(测试平台和测试程序)。为保证测试结果的完整性，被测试者(通常是厂家)必须提交给TPC一套完整的报告(Full Disclosure Report)，包括被测系统的详细配置、分类价格和包含5年维护费用在内的总价格。该报告必须由TPC授权的审核员核实(TPC本身并不做审计)。 TPC在全球只有不到10名审核员，全部在美国。
TPC推出过11套基准程序，分别是正在使用的TPC-App、TPC-H、TPC-C、TPC-W，过时的TPC-A、TPC-B、 TPC-D和TPC-R，以及因为不被业界接受而放弃的TPC-S(Server专门测试基准程序)、TPC-E(大型企业信息服务测试基准程序)和 TPC-Client/Server。而目前最为“流行”的TPC-C是在线事务处理(OLTP)的基准程序，于1992年7月完成，后被业界逐渐接受。
TPC-C使用三种性能和价格度量，其中性能由tpmC(transactions per minute，tpm)衡量，C指TPC中的C基准程序。它的定义是每分钟内系统处理的新订单个数。TPC-C还经常以系统性能价格比的方式体现，单位是$/tpmC，即以系统的总价格(单位是美元)/tpmC数值得出。
解读tpmC
从TPC-C的定义不难知道，这套基准程序是用来衡量整个IT系统的性能，而不是评价服务器或某种硬件系统的标准，而且tpmC数值的高低直接受到各个环节的影响，右表大概可以说明系统设置对tpmC测试的影响。此处的“IT系统”包括服务器、外设(如硬盘或 RAID)、服务器端操作系统、数据库软件、客户端及其操作系统、数据库软件和网络连接等。因此，如何解读tpmC数值会因不同的采购需求有非常大的差异。
|
tpmC测试指标与硬件的关联度
|
|||||
|
交易类型
|
复杂程度
|
发生频率
|
访问表的数量（内存、磁盘IO相关）
|
平均逻辑IO数目
|
CPU的负载（%）
|
|
新订单
|
复杂交易
|
45%
|
8
|
46
|
53
|
|
付款
|
复杂交易
|
43%
|
4
|
8
|
11
|
|
交货
|
4%
|
4
|
70
|
8
|
|
|
订单查询
|
简单交易
|
4%
|
3
|
12
|
1
|
|
库存查询
|
复杂交易
|
4%
|
3
|
401
|
27
|
|
上述5种交易中，除付货交易是事后批处理，其余4种皆为联机交易。要注意的是，在处理新订单的同时，系统还要处理其他4类事务请求。通常而言，新订单请求不可能超出全部事务请求的45%，因此，当一个系统的性能为1000tpmC时，它每分钟实际处理的请求数是2000多个。
数据来源：www.tpc.org
|
|||||
以服务器为例。在很多厂家的TPC测试系统中，服务器的价格只是系统总价格的25%或更小，而硬盘的价格有可能占到总价格的30%以上，因为TPC-C要求被测系统必须保存180天的事务记录(这一趋势从一些最新的TPC-C测试结果来看，会愈演愈烈)。如果同样的服务器被用到用户的环境中，厂家报的tpmC值就意义不大，因为用户的实际系统与厂家原来用于TPC测试的系统大不一样。当同样的主机用在不同的系统中时，tpmC值可能有相当大的变化，现在许多用户还没有意识到这一点。
尤其需要服务器采购用户注意的是，tpmC指标更多的是衡量从Client到终端网络的性能区域(如左图所示)，而不是通常误认为的服务器到企业端网络的性能。由此可见，如果用户是建立一套全新的业务系统，那么无妨多借鉴tpmC的性能指标，如果只是采购某种或某些硬件设备，则需要参考更多的指标。
对于tpmC数值着迷的用户而言，一个现实问题是，实现高tpmC指标的代价是否能够承受，毕竟TPC-C都是很复杂的基准程序，做一个严格的测试非常消耗资源，厂商通常不会给TPC报告出全部花费的金钱和时间。
实际上，正因为tpmC(其他评测指标也大都一样)受系统优化影响较大，业界对于是否应该在测试中进行优化向来争议颇多。在1993年, 当时三大IT公司的专家就对OLTP性能测试的优化提出过反对意见——DEC的 Jim Gray (现为TPC-C委员会专家) 与Walt Kohler 、天腾公司(TANDEN)的Charles Levine 和IBM的Steve Kiss共同发表了对OLTP性能测试指标是否应该进行人为优化的看法:
“一个好的性能测试指标是不会依赖于特殊情况下的优化。最理想的情况应该是：一个测试指标在测试过程中所表现出的性质和能力, 以及对测试所做的优化能够确实提供对现实世界中用户实际应用的性能改进。然而，事与愿违，某些厂商迫于标准测试指标所带来的巨大市场压力，他们花费巨大的精力在如何改进测试结果的同时还能降低价格比率，而全然不顾所做的这一切优化究竟是否给用户带来了真实的利益。”
评测组织网站:
http://tpc.org/
http://www.spec.org/
Storage:
http://www.storageperformance.org
