TPC系列性能指标

摘要: 本文重点介绍当前常用的TPC系列性能指标，供广大用户参考。

1:关于TPC-C TPC(Transactionprocessing Performance Council，事务处理性能委员会)是由数十家会员公司创建的非盈利组织，总部设在美国。TPC的成员主要是计算机软硬件厂家，而非计算机用户，其功能是制定商务应用基准程序的标准规范、性能和价格度量，并管理测试结果的发布。       图1:TPC组织成员构成     　　TPC不给出基准程序的代码，而只给出基准程序的标准规范。任何厂家或其他测试者都可以根据规范，最优地构造出自己的测试系统(测试平台和测试程序)。为保证测试结果的完整性，被测试者(通常是厂家)必须提交给TPC一套完整的报告(Full Disclosure Report)，包括被测系统的详细配置、分类价格和包含5年维护费用在内的总价格。该报告必须由TPC授权的审核员核实(TPC本身并不做审计)。 TPC在全球只有不到10名审核员，全部在美国。 作为一家非盈利性机构，事务处理性能委员会（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)上获得。   tpmC定义: TPC-C的吞吐量，按有效TPC-C配置期间每分钟处理的平均交易次数测量，至少要运行12分钟。   1.1:TPC-C规范概要   TPC-C使用三种性能和价格度量，其中性能由tpmC（transactions per minute，tpm）衡量，C指TPC中的C基准程序。它的定义是每分钟内系统处理的新订单个数。TPC-C还经常以系统性能价格比的方式体现，单位是＄/tpmC，即以系统的总价格（单位是美元）/tpmC数值得出。 TPC-C是专门针对联机交易处理系统（OLTP系统）的，一般情况下我们也把这类系统称为业务处理系统。 TPC-C测试规范中模拟了一个比较复杂并具有代表意义的OLTP应用环境:假设有一个大型商品批发商，它拥有若干个分布在不同区域的商品库；每个仓库负责为10个销售点供货；每个销售点为3000个客户提供服务；每个客户平均一个订单有10项产品;所有订单中约1%的产品在其直接所属的仓库中没有存货，需要由其他区域的仓库来供货。   该系统需要处理的交易为以下几种：   New-Order：客户输入一笔新的订货交易；   Payment:更新客户账户余额以反映其支付状况;   Delivery:发货(模拟批处理交易);   Order-Status:查询客户最近交易的状态；   Stock-Level:查询仓库库存状况，以便能够及时补货。   对于前四种类型的交易，要求响应时间在5秒以内；对于库存状况查询交易，要求响应时间在20秒以内。   逻辑结构图：     图2：逻辑结构图 流程图： 图3：应用流程图   1.2: 解读tpmC 　　从TPC-C的定义不难知道，这套基准程序是用来衡量整个IT系统的性能，而不是评价服务器或某种硬件系统的标准，而且tpmC 数值的高低直接受到各个环节的影响，右表大概可以说明系统设置对tpmC测试的影响。此处的“IT系统”包括服务器、外设(如硬盘或RAID)、服务器端操作系统、数据库软件、客户端及其操作系统、数据库软件和网络连接等。因此，如何解读tpmC数值会因不同的采购需求有非常大的差异。 　　图4：TPC-C检测环境示意图     图5：tpmC测试指标与硬件的关联度   　　上述5种交易中，除付货交易是事后批处理，其余4种皆为联机交易。要注意的是，在处理新订单的同时，系统还要处理其他4类事务请求。通常而言，新订单请求不可能超出全部事务请求的45%，因此，当一个系统的性能为1000tpmC时，它每分钟实际处理的请求数是2000多个。数据来源： www.tpc.org 　　以服务器为例。在很多厂家的TPC测试系统中，服务器的价格只是系统总价格的25％或更小，而硬盘的价格有可能占到总价格的30％以上，因为TPC-C要求被测系统必须保存180天的事务记录（这一趋势从一些最新的TPC-C测试结果来看，会愈演愈烈）。如果同样的服务器被用到用户的环境中，厂家报的tpmC值就意义不大，因为用户的实际系统与厂家原来用于TPC测试的系统大不一样。当同样的主机用在不同的系统中时，tpmC值可能有相当大的变化，现在许多用户还没有意识到这一点。 尤其需要服务器采购用户注意的是，tpmC指标更多的是衡量从Client到终端网络的性能区域（如左图所示），而不是通常误认为的服务器到企业端网络的性能。由此可见，如果用户是建立一套全新的业务系统，那么无妨多借鉴tpmC的性能指标，如果只是采购某种或某些硬件设备，则需要参考更多的指标。   1.3: 评测指标   TPC-C测试规范经过两年的研制，于1992年7月发布。几乎所有在OLTP市场提供软硬件平台的厂商都发布了相应的TPC-C测试结果，随着计算机技术的不断发展，这些测试结果也在不断刷新。   TPC-C的测试结果主要有两个指标：   ● 流量指标(Throughput，简称tpmC)   按照TPC的定义，流量指标描述了系统在执行Payment、Order-status、Delivery、Stock-Level这四种交易的同时，每分钟可以处理多少个New-Order交易。所有交易的响应时间必须满足TPC-C测试规范的要求。 流量指标值越大越好！   ● 性价比(Price/Performance，简称Price/tpmC) 即测试系统价格（指在美国的报价）与流量指标的比值。 性价比越小越好！   1.4: 结果发布 各厂商的TPC-C测试结果都按TPC组织规定的两种形式发布：测试结果概要(Executive Summary)和详细测试报告(Full Disclosure Report)。 测试结果概要中描述了主要的测试指标、测试环境示意图以及完整的系统配置与报价，而详细测试报告中除了包含上述内容外，还详细说明了整个测试环境的设置与测试过程。 P690 tpmC测试值：76,389,839.00 l          $/tpmC：831.00 l          美国美金报价：6,349,223.0 l          CPU数：32 l          数据库：IBM DB2 UDB 8.1 l          操作系统：AIX 5L V5.2 l          中间件：TUXEDO 8.0 l          测试日期：2003.6.30 P690 TPC-C测试的配置： (1)．  后台：1 x eServer pSeries 690 with 32 x 1.7GHz POWER4+ processors with 128MB L3 cache per MCM (total of four MCMs), 512GB memory (2)．  前端：30 x eServer pSeries 630 Model 6E4 each with 4 x 1.0GHz POWER4 CPUs with 32MB L3 cache, 16GB memory   2: TPC-W   TPC Benchmark™ W (TPC-W) is a transactional web benchmark. The workload is performed in a controlled internet commerce environment that simulates the activities of a business oriented transactional web server. The workload exercises a breadth of system components associated with such environments, which are characterized by: Multiple on-line browser sessions  Dynamic page generation with database access and update Consistent web objects The simultaneous execution of multiple transaction types that span a breadth of complexity On-line transaction execution modes Databases consisting of many tables with a wide variety of sizes, attributes, and relationships Transaction integrity (ACID properties) Contention on data access and update The performance metric reported by TPC-W is the number of web interactions processed per second. Multiple web interactions are used to simulate the activity of a retail store, and each interaction is subject to a response time constraint.  TPC-W simulates three different profiles by varying the ratio of browse to buy: primarily shopping (WIPS), browsing (WIPSb) and web-based ordering (WIPSo). The primary metrics are the WIPS rate, the associated price per WIPS ($/WIPS), and the availability date of the priced configuration.   TPC-W Related Documents TPC-W, the Industry Standard eBusiness Benchmark Technical White Paper More Information about Pricing TPC-W模拟面向商务的事务型Web服务器活动。工作负载将在受控Internet商务环境中执行，并且将对与此种环境相关的广泛系统组件进行测试。 通过TPC-W得到的性能指标为每秒处理的Web交互次数。多种Web交互方式被用于模拟零售商店业务活动，其中每种交互方式均有一定的响应时间限制。商店规模可以通过一套事先指定的比例因子加以选择，这种比例因子为库存货物件数，其取值被控制在1,000件至10,000,000件之间。 例子： 基准测试详细信息:     操作系统 Windows Server 2003企业版 性能 每秒钟处理21,139次Web交互（WIPS） 性价比 每WIPS 32.62美元 硬件设备 IBM eServer xSeries 440 总体系统成本 689,477美元 系统可用日期 2003年3月31日 测试起始日期 2003年1月14日     3：TPC-H TPC-H所报告的性能计量单位被称为“TPC-H复合式每小时查询性能单位（QphH）”，反映出了系统处理查询的多方面能力。 The TPC-H benchmark is widely used in the database community as a yardstick to assess the performance of database management systems against large scale decision support applications. The benchmark is designed and maintained by the Transaction Processing Counsel . In Sep 2008 we ran this benchmark on our Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz with 8GB RAM and ample disk space (2x 500 GB SATA disk @ 7200 RPM as SW-RAID-0), running Fedora 8 (Linux kernel 2.6.24). The systems considered were PostgreSQL 8.2.9, MySQL 5.0.45, Ingres 2006 version 4 and MonetDB/SQL 2.25 on top of MonetDB/Server 5.7 (development version from CVS, dated Sat Jul 19 11AM). All systems were installed with their default settings, i.e. it mimics an out-of-the-box situation that end-users will experience. For PostgreSQL we called the statistics utility directly after loading. The query sequences were run one after the other in a single client session. The timings for MonetDB concern two runs: '2nd' [1st]. The other systems concern a single run. The same experiment was previously ran in October 2006 . July 2008 . TPCH scale factor 2, timing in seconds     MonetDB/SQL     PostgreSQL MySQL   stable current recycler     Q1 6.2 [6.3] 2.2 [2.2] 0.8 [2.2] 76 41 Q2 0.14 [0.2] 0.07 [0.08] 0.08 [0.16] 1 26 Q3 2.6 [2.6] 1.1 [1.0] 0.01 [1.2] 20 16 Q4 2.2 [2.2] 0.9 [0.9] 0.002 [0.9] 1.2 2.6 Q5 1.3 [1.2] 0.7 [0.8] 0.002 [0.8] 0.8 27 Q6 0.5 [0.5] 0.2 [0.3] 0.003 [0.3] 5.2 7 Q7 1.8 [1.8] 0.7 [0.8] 0.2 [0.5] 8.7 8 Q8 0.7 [0.7] 0.4 [0.4] 0.003 [0.2] 6.9 1.5 Q9 1.7 [1.8] 0.6 [0.6] 0.04 [0.9] 53 11 Q10 1.7 [1.7] 0.7 [0.7] 0.02 [0.8] 0.9 18 Q11 0.2 [0.2] 0.06 [0.06] 0.06 [0.06] 1.1 0.5 Q12 1.3 [1.3] 0.6 [0.6] 0.3 [0.7] 7 6.9 Q13 8.1 [8.0] 3.3 [3.3] 1.0 [3.3] 19.2 9.9 Q14 0.4 [0.3] 0.2 [0.2] 0.008 [0.2] 5 38 Q15 0.3 [0.3] 0.1 [0.2] 0.03 [0.2] 5 13 Q16 1.1 [1.1] 0.5 [0.5] 0.4 [0.5] 12.9 11 Q17 1.3 [1.3] 0.6 [0.6] 0.006 [0.6]   1.2 Q18 1.7 [1.7] 0.9 [0.9] 0.004 [0.9] 52   Q19 3.6 [3.7] 1.4 [1.4] 1.3 [1.5] 8 0.327 Q20 1.2 [1.2] 0.4 [0.4] 0.4 [0.4]   0.4 Q21 7.6 [7.6] 2.2 [2.2] 2.0 [0.4] 49 7.3 Q22 0.7 [0.7] 0.3 [0.4] 0.4 [0.4] 119m 0.5 load 3m30 1m42 1m42 6m57 3m10 - MonetDB is somewhat slower     MonetDB is >10x faster     Takes >1hr to run     Error, empty result     Although set out as a small-scale experiment to assess our SQL implementation functionality, we were pleasantly surprised by the performance and scalability. Some observations on the results shown: Confirmation The results obtained align with our experience in more detailed sciences studies (see our science library). Some additional results are available at the MySQL performance blog and the Postgresql performance blog. Scalability MonetDB was designed from a main-memory perspective, but its performance shows it is capable to grow well beyond the main memory capacity. Scale-factor 10 and 20 makes the database size larger than the available main memory. All systems experience dramatic increase in IO behavior. Tuning The performance figures of PostgreSQL and MySQL can be improved by throwing database expertise at the problem. Buffer spaces may be tuned, configuration files tweaked, additional indices may be introduced, etc.. However, such expertise does not belong to the average user. He will experience a fast system provided the database remains small and the queries are not too complex. Bulk loading The loading time is largely determined by the amount of data read/written. Turning the transaction logger off improves the performance significantly. Furthermore, PostgreSQL and MonetDB ensure database consistency by checking all referential constraints as well. This is ignored by MySQL. Validation The results produced by PostgreSQL for queries 4,5,6,10,12,14,15,20 do not conform. to the requirements of TPC-H. They produce erroneous or empty results. The MonetDB system was built from CVS sources, using the same setup as for the binary release, i.e., configured with "--disable-debug --enable-optimize --disable-assert" and compiled with gcc 4.1.2. The SQL optimizer included the novel dataflow optimizer, but not the recycler. Each MonetDB series was run twice consecutively. The timings where obtained using mclient -lsql -t. For PostgreSQL and MySQL we ran the series once. TPCH scale factor 0.01, timing in msec   MonetDB/SQL PostgreSQL MySQL Q1 19 [135] 385 207 Q2 4 [27] 10 17 Q3 6 [73] 29 78 Q4 7 [44] 16 23 Q5 5 [14] 19 133 Q6 2 [4] 40 42 Q7 6 [13] 26 33 Q8 4 [14] 31 11 Q9 8 [55] 82 48 Q10 6 [21] 18 76 Q11 3 [5] 18 9 Q12 6 [17] 44 40 Q13 32 [59] 35 52 Q14 2 [5] 35 15 Q15 3 [7] 52 75 Q16 5 [9] 38 48 Q17 2 [28] 11 6 Q18 6 [11] 66   Q19 11 [23] 47 9 Q20 8 [12] 879 8 Q21 13 15] 136 17 Q22 5 [8] 659 9 load 0m0.5 0m0.8 0m0.7 - MonetDB is somewhat slower MonetDB is >10x faster Takes >1hr to run Error, empty result   TPCH scale factor 1, timing in seconds   MonetDB/SQL PostgreSQL MySQL Q1 1.2 [1.2] 38.2 20.4 Q2 0.05 [1.4] 0.5 0.7 Q3 0.5 [1.8] 11.8 7.9 Q4 0.4 [1.6] 0.6 1.3 Q5 0.3 [0.7] 0.4 12.9 Q6 0.1 [0.1] 2.7 3.6 Q7 0.2 [0.3] 5.4 3.8 Q8 0.2 [0.8] 3.2 0.8 Q9 0.5 [3.3] 21.1 5.2 Q10 0.3 [1.8] 0.5 7.7 Q11 0.03 [0.8] 0.59 0.26 Q12 0.3 [0.8] 3.7 3.4 Q13 3.1 [3.2] 4.7 5.6 Q14 0.1 [0.1] 2.7 18 Q15 0.1 [0.4] 2.6 6.9 Q16 0.3 [0.6] 5.1 5.3 Q17 0.2 [0.5] 164m 0.6 Q18 0.5 [0.7] 27   Q19 0.7 [1.3] 4.4 0.18 Q20 0.3 [0.3] 255m 0.2 Q21 0.9 [1.1] 24 3.5 Q22 0.1 [0.3]0.9 29m 0.27 load 0m47 4m29 1m25 - MonetDB is somewhat slower MonetDB is >10x faster Takes >1hr to run Error, empty result   TPCH scale factor 2, timing in seconds     MonetDB/SQL     PostgreSQL MySQL   stable current recycler     Q1 6.2 [6.3] 2.2 [2.2] 0.8 [2.2] 76 41 Q2 0.14 [0.2] 0.07 [0.08] 0.08 [0.16] 1 26 Q3 2.6 [2.6] 1.1 [1.0] 0.01 [1.2] 20 16 Q4 2.2 [2.2] 0.9 [0.9] 0.002 [0.9] 1.2 2.6 Q5 1.3 [1.2] 0.7 [0.8] 0.002 [0.8] 0.8 27 Q6 0.5 [0.5] 0.2 [0.3] 0.003 [0.3] 5.2 7 Q7 1.8 [1.8] 0.7 [0.8] 0.2 [0.5] 8.7 8 Q8 0.7 [0.7] 0.4 [0.4] 0.003 [0.2] 6.9 1.5 Q9 1.7 [1.8] 0.6 [0.6] 0.04 [0.9] 53 11 Q10 1.7 [1.7] 0.7 [0.7] 0.02 [0.8] 0.9 18 Q11 0.2 [0.2] 0.06 [0.06] 0.06 [0.06] 1.1 0.5 Q12 1.3 [1.3] 0.6 [0.6] 0.3 [0.7] 7 6.9 Q13 8.1 [8.0] 3.3 [3.3] 1.0 [3.3] 19.2 9.9 Q14 0.4 [0.3] 0.2 [0.2] 0.008 [0.2] 5 38 Q15 0.3 [0.3] 0.1 [0.2] 0.03 [0.2] 5 13 Q16 1.1 [1.1] 0.5 [0.5] 0.4 [0.5] 12.9 11 Q17 1.3 [1.3] 0.6 [0.6] 0.006 [0.6]   1.2 Q18 1.7 [1.7] 0.9 [0.9] 0.004 [0.9] 52   Q19 3.6 [3.7] 1.4 [1.4] 1.3 [1.5] 8 0.327 Q20 1.2 [1.2] 0.4 [0.4] 0.4 [0.4]   0.4 Q21 7.6 [7.6] 2.2 [2.2] 2.0 [0.4] 49 7.3 Q22 0.7 [0.7] 0.3 [0.4] 0.4 [0.4] 119m 0.5 load 3m30 1m42 1m42 6m57 3m10 - MonetDB is somewhat slower     MonetDB is >10x faster     Takes >1hr to run     Error, empty result       TPCH scale factor 5, timing in seconds   MonetDB/SQL PostgreSQL MySQL Q1 8.3 [9.6] 192 102 Q2 0.2 [2.4] 23 629 Q3 4.3 [11] 157 156 Q4 2.3 [6.8] 16.6 13 Q5 2.1 [5.0] 2.9 73 Q6 0.6 [0.6] 62 18 Q7 3.2 [3.2] 125 21 Q8 1.1 [3.8] 93 4.2 Q9 3.0 [6.8] 765 29 Q10 1.9 [15] 3.3 135 Q11 0.2 [0.3] 11.6 1.3 Q12 1.5 [3.8] 78 17 Q13 17 [18] 43 25 Q14 0.6 [0.6] 73 93 Q15 0.4 [1.9] 29 34 Q16 1.4 [1.7] 56 28 Q17 1.5 [2.7]   3 Q18 2.5 [3.3] 351   Q19 3.9 [6.7] 45 0.8 Q20 1.3 [1.4]   1.4 Q21 5.6 [5.8] 166 18 Q22 0.9 [1.1]   1.3 load 6m50 25m14 8m42 - MonetDB is somewhat slower MonetDB is >10x faster Takes >1hr to run Error, empty result   TPCH scale factor 10, timing in seconds   MonetDB/SQL PostgreSQL MySQL Q1 40 [42] 510 203 Q2 7 [5.3] 54 1586 Q3 22 [24] 798 393 Q4 11 [15] 35 122 Q5 12 [12] 5.5 15538 Q6 1.3 [1.2] 172 62 Q7 6.1 [5.7] 439 6680 Q8 9.3 [9.2] 251 939 Q9 15.8 [16] 2240 8169 Q10 19 [39] 6.1 924 Q11 0.7 [0.7] 25 689 Q12 9.6 [12] 179 106 Q13 48[83] 140 496 Q14 1.4[1.4] 169 5850 Q15 3.1 [3.1] 168 71 Q16 5.0 [4.4] 115 58 Q17 6.5[5.7]   8 Q18 17 [19] 882   Q19 14 [15] 218 5 Q20 4.4 [3.1]   744 Q21 20 [48] 477 4426 Q22 5.2 [3.3]   4 load 14m31 63m04 17m07 MonetDB is somewhat slower MonetDB is >10x faster Takes >1hr to run Error, empty result   TPCH scale factor 20, timing in seconds   MonetDB/SQL PostgreSQL MySQL Q1 326 [298] 1009   Q2 21 [14] 171   Q3 88 [95] 424   Q4 38 [43] 77   Q5 76 [64] 10   Q6 36 [36] 301   Q7 11 [9] 1268   Q8 29 [25] 639   Q9 257 [296] 8098   Q10 180 [166] 42   Q11 6.7 [5] 68   Q12 61 [60] 328   Q1, , 3 99 [90] 357   Q14 80 [81] 386   Q15 30 [29] 429   Q16 13 [14] 279   Q17 32 [85]     Q18 88 [67] 1521   Q19 47 [51] 589   Q20 20 [37]     Q21 115 [110] 906   Q22 11 [11]     load 45m00 123m16 -   MonetDB is somewhat slower MonetDB is >10x faster Takes >1hr to run Error, empty result   TPC-H是一种决策支持基准。它包含一整套面向商业的特殊查询和并发数据修改内容。该基准中选择的查询和数据库中的数据都具有广泛的全行业关联性。这种测试基准所描述的决策支持系统可检查大量的数据，所执行的查询也具有很高的复杂度。 TPC-H所报告的性能计量单位被称为“TPC-H复合式每小时查询性能单位”（TPC-H Composite Query-per-Hour Performance Metric - QphH@Size），反映的是系统处理查询的多方面能力，包括查询执行时选定的数据库大小、单个流提交查询时的查询处理能力，以及多个并发用户提交查询时的查询吞吐量。TPC-H的价格/性能比计量单位的表达方式为 $/QphH@Size 。       4：TPC-E TPC组织（交易处理性能委员会，Transaction Processing Performance Council）却宣布推出新的TPC-E，以取代有14年历史的TPC-C。TPC-E这一全新的数据库服务器评测标准开始受到越来越多人的关注.    “TPC-C与TPC-E相比，哪一个更权威、更实用？”这是一个萦绕在很多刚刚接触TPC-E的人的脑海中的一个基本问题。也许你会说，如果TPC-E不够好，TPC组织为什么要用它来取代TPC-C呢？但不可否认的一个事实是，TPC-C从1992年起已经实行了16年，而TPC-E从去年3月推出还只有一年半的时间，很多用户知道TPC-C，却不了解TPC-E。我想要解决这个问题，首先得分析一下TPC组织为什么要用TPC-E来取代TPC-C。     原因主要有两个：一是TPC-C的模型已经老化，二是TPC-C的测试成本太高。     TPC-C的模型还是十几年前的东西——过时的C/S架构，模拟的是批发商系统，简单的数据库和业务逻辑。而当今WEB2.0时代的OLTP应用，大多采用流行的B/S架构，需要更大规模的并行处理能力，数据库和业务逻辑也更加复杂。显然，如果再用过去的模型来模拟今天的应用环境，确实显得有些不合时宜了。     为此，TPC-E对模型进行大刀阔斧的创新——模拟证券经纪公司而不是批发商的流量和交易模式，从C/S架构过渡到B/S架构，数据类型从原来的3种扩展到10种，事务类型从原来的5种增加到12种，数据表由原来的9个增加到了33个，数据库构成更加复杂，也更加符合实际应用，当然对服务器的性能要求也更高了。        表1：TPC-E与TPC-C数据库比较 再来看看TPC-C的测试成本。由于TPC-C的模型比较简单，服务器在测试时只是做一些简单的数据查询、修改和删除操作；而在多核计算盛行的今天，针对这种应用，强大的服务器CPU容易处于等待数据的空闲状态，I/O因而成为严重瓶颈。为了提升I/O，保证测试性能，服务器厂商往往需要动用大量的内存和磁盘。比如IBM和惠普公司在获得最高分的TPC-C测试时都使用了7000块硬盘。这使得参加TPC-C测试所需要的成本高达千万美元。如此巨额成本大大提高了TPC-C的门槛，将很多小型服务器厂商拒之门外。而且，从用户角度来看，实际应用可能并不需要如此海量的内存和磁盘，TPC-C结果的适用性也受到了质疑。       而TPC-E则不同。由于数据库更加复杂，要执行的事务处理更多——TPC-E标准中定义的事务有12种，每个事务对应数据库管理系统中的一个或多个带输入和输出参数的存储过程，而且会涉及到不同表间的关联，这使得服务器CPU容易处在“有事可做”的状态，因而对内存和磁盘I/O的要求也相对小一些。浪潮服务器方案技术经理乔鑫告诉IT168记者，TPC-C的硬件投入比TPC-E要高出3倍以上，由于TPC-E所需要的磁盘数量仅是TPC-C的十分之一，从而大大降低了服务器厂商搭建硬件环境的成本。       图6: TPC-E测试模型之物理结构         TPC组织负责TPC-E推广的安德里亚斯此前在接受媒体采访时也曾表示，新测试费用比较廉价的部分原因是对硬件的要求更加合理了，另外一个原因就是TPC将提供软件的源代码，取代了要求测试人员自己编写代码。       可见，模型更新和成本降低让我们看到了TPC-E新标准的魅力：更加逼近现实，更有代表性，会更具广泛性。   TPC-E对用户有什么参考价值       那么，对于用户来说，在实际采购数据库服务器过程中，又如何来理解和看待TPC-E的测试结果呢？       由于数据库的应用一般有两种，一种是OLTP，即在线联机事务处理，另一种是数据挖掘。就目前来说，OLTP仍然是主流应用。所以从一定程度来说，TPC-E的结果对于数据库系统采购都有一定的参考价值，比如银行、证券、税务报税系统、电子商务网站、电信业务等都是比较典型的OLTP应用。英特尔服务器性能市场经理高丰告诉IT168，虽然不同用户的应用环境各不相同，TPC-E无法提供一一对应的方案，但其结果对采购决策还是有重要的方向性指导意义。       与TPC-C一样，TPC-E的测试结果也主要有两个指标：性能指标（tpsE，transactions per second E)和性价比（成本/tpsE）。其中，前者是指系统在执行多种交易时，每秒钟可以处理多少交易，指标值越大越好；后者则是指系统价格与前一指标的比值，数值越小越好。       比如，某系统TPC-E测试值达到700tpsE，这意味着什么呢？对此，乔鑫告诉记者，700tpsE相当于这样一种应用环境：有36万用户同时在线，每分钟处理42万个事务，每分钟进行107万个数据库存储过程，每天（8小时）处理2亿个事务，5.08亿个数据库存储过程，90%以上的交易事务最长也只需不到3秒就能完成，应用的数据规模在3TB左右。           图7:TPC-E测试模型之逻辑结构   当然，光有性能还不够，毕竟用户环境千差万别，这时可以借助“成本/tpsE”这样一个性价比指标，然后根据自己的预算和要求，计算出需要多大规模的系统。       对于OLTP应用来说，除了性能和性价比，系统的可靠性和可用性也是非常关键的因素。虽然TPC无法给出一个量化的指标，但却是通过测试过程规范机制来保障系统的可靠性。       英特尔高级服务器性能工程师汪亚光介绍说，对于每个参加测试的厂商，TPC组织都会派出一位评审专家到现场监督，审查系统是否进行了数据保护，软硬件配置是否正确，磁盘损坏的情况下能否保证业务正常运行。比如有这样一个环节，当负载压力达到95%峰值时，在没有UPS保护的情况下，把所有服务器电源都拔掉，检测系统还能否正常恢复，数据完整性能否得到保障，数据是否会丢失——这对于系统的稳定可靠性是非常严峻的考验。       另外，要求保证测试结果稳定、连续运行两个小时以上，性能指标不能出现超出5%以上的波动。要知道在实际应用环境中，很少有系统会在峰值状态下连续运转两个小时。同时，高并发访问量和数据响应时间等因素也有严格的限制，在10种业务处理中，系统延迟最大不能超过3秒。因此，能够参加TPC-E测试，从侧面也能够证明服务器厂商在高端商用市场上的综合技术实力。      表2：TPC-E测试模型   哪些因素会影响TPC-E测试结果       跟SPEC CPU这类测试不同，TPC-E测试不仅仅是服务器某一方面的性能，而是评测整体方案的应用性能，这个方案是包括服务器、存储、OS、数据库等软硬件在内的一整套系统。浪潮乔鑫表示，“为了保证系统性能，在服务器、存储、操作系统、数据库软件等各个子系统上就不能出现短板。服务器厂商要做的是系统优化，即怎么让软件和硬件可以更好的配合，怎么让服务器和后端的存储进行更好的整合。”       也就是说，不同厂商选择不同的CPU、存储、OS、数据库，都有可能会对TPC-E的最终测试结果产生影响。这里，我们比较了参加TPC-E测试的几套四路服务器系统，发现六核系统比四核性能表现好，8GB光纤SAN存储比4GB光纤要好，操作系统和数据库软件的升级也会对TPC-E性能产生影响。       比如，四路服务器中，得分最高的三款采用的都是英特尔将在9月下旬正式发布的六核Dunnington至强 X7460。大体来看，四路六核系统的TPC-E性能比四路四核要高出50%左右，比四路双核更是高出3倍多。如Dell PowerEdge R900 四核版本的成绩是451.29，六核版本是671.35，相比之下提高了48%。记者就此向英特尔高丰进行求证，他表示，对于尚未发布的产品还不便于评论，但多核架构对于大规模并行处理确实有很大帮助。       再来看看存储方面。IBM System x3850 M2在去年和今年参加了两次测试，服务器配置都是四路四核Xeon X7350 2.93GHz处理器和128GB内存，但结果却不一样，从第一次的419.80 tpsE提升到了479.51tpsE，增长了14%。究其原因就在于，这两次参测方案使用了不同的存储、数据库软件和服务器操作系统。第一次用的是4GB光纤SAN存储、 SQL Server 2005 和Windows Server 2003，而第二次使用的是8GB光纤SAN存储、 SQL Server 2008和Windows Server 2008。       又比如，浪潮NF520D2 和Dell PowerEdge R900 都是最新的四路六核系统，都使用了SQL Server 2008和Windows Server 2008，但前者使用了128GB内存，后者使用了64GB内存，在后端存储的选择上也有差异，使得浪潮NF520D2的性能高出了5%左右。       可见，TPC-E看的不仅仅是CPU的性能，服务器系统设计、操作系统与数据库软件、存储架构等都非常关键。       小结       尽管TPC-E的权威性和适用性已毋庸置疑，但毕竟只推出了一年半的时间。所以，现在参加TPC-E测试的厂商数量和软硬件类别还不够丰富多样，比如参加评测的16套系统采用的全是英特尔至强处理器，看不到AMD的平台；HP、SUN等厂商还没有参与进来；操作系统选用的都是Windows，还没有Linux；数据库软件也只有SQL Server，而没有Oracle；很多用户还不了解TPC-E。但不管怎样，作为一个完全开放的第三方平台，我们有理由相信TPC-E会向TPC-C一样发展和成熟起来。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/24435147/viewspace-694527/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/24435147/viewspace-694527/