【IT168 资讯】随着新的事务处理性能测试标准TPC-E的发布,已经有越来越多的企业公布了自己的测试结果。在严格遵循官方文档中给出的测试规范的前提下,如何搭建TPC-E测试环境,并实现具体的测试应用程序,结合这两个问题,本文详细介绍了达梦数据库TPC-E测试程序的架构设计和具体实现流程。
1 背景介绍
2007年3月19日,总部在美国的事务处理性能委员会(Transaction Processing Performance Council)宣布批准了名为TPC-E的新标准以取代自1992年沿用至今的TPC-C标准。TPC-E(大型企业信息服务测试标准程序),作为大型企业(Enterprise)信息服务的基准程序,与TPC-C一样,TPC-E的测试结果也主要有两个指标:性能指标(tpsE, transactions per second E)和性价比(美元/tpsE)。其中,前者是指系统在执行多种交易时,每秒钟可以处理多少交易,其指标值越大越好;后者则是指系统价格与前一指标的比值,数值越小越好。
新的测试包含了一个联机事务处理系统(OLTP) 性能分析,对各种软硬件平台进行模拟现代IT环境的压力测试。TPC-E不是一个纯学术基准,它模拟的是一个经纪公司的流量和交易模式。该测试模拟了一系列后端处理数据和经纪行前端客户在交易公司的典型行为--帐户查询,在线交易和市场调研。该模拟经纪行也与外界的金融市场相联系,根据市场变化执行指令并更新相关的帐户和市场信息。
与TPC-E相比,TPC-C只是针对一种模拟订单录入与销售环境测量每分钟商业事务(tpmC)吞吐量,测量的事务类型也只有四种。两相对比,TPC-E所采用的商业模型更为人们熟悉也更容易理解,也包含了更多的事务类型。
从实际测试过程上看,TPC会给出基准程序的标准规范(Standard Specification),参测的厂商则根据TPC组织公布的规范标准,最优地构造出自己的系统,使用最优的平台和最高效的应用程序。为了保证测试结果的客观性,参测厂商必须提交给TPC一套完整的报告,包括被测系统的详细配置、分类价格和包含五年维护费用在内的总价格等,该报告必须由TPC授权的审核员核实。一个值得注意的变化是,在性能指标中,时间单位从TPC-C中的以分钟计变为TPC-E中的以秒计。
2007年7月17日,Unisys在业内率先发布了针对TPC-E基准进行测试的首批基准测试结果。该测试是在Unisys ES7000/one企业级服务器和Microsoft SQL Server 2005企业版中进行的。测试结果树立了ES7000企业级服务器在Microsoft Windows环境中的性能、经济性和可扩展性等方面领先同类的卓越地位。此后,IBM、惠普和戴尔也先后发布了基于TPC-E基准测试结果。
2 体系结构
TPC-E模拟了真实世界中一个证券公司和那些贸易、会计查询和市场研究方面的客户之间的交易。这个公司会和金融市场产生联动,并基于客户的利益执行指令及更新那些账户信息。在TPC-E标准中,客户的数量可以代表不同规模的商业事务,把十种商业事务混合在一起执行。
2.1 数据库设计
TPC-E基准中主要定义了表1中的列举的33个表,具体测试的时候,根据不同的数据库管理系统和数据规模,可能需要建立一些辅助表和索引:
| 表名 | 中文表名 | 前缀 | |
| 客户类 | ACCOUNT_PERMISSION | 客户账目许可表 | AP_ |
| CUSTOMER | 客户信息表 | C_ | |
| CUSTOMER_ACCOUNT | 客户账目表 | CA_ | |
| CUSTOMER_TAXRATE | 客户税率表 | CX_ | |
| HOLDING | 客户股票持有表 | H_ | |
| HOLDING_HISTORY | 客户股票持有历史表 | HH_ | |
| HOLDING_SUMMARY | 客户股票持有总表 | HS_ | |
| WATCH_ITEM | 客户观察证券列表 | WI_ | |
| WATCH_LIST | 客户观察证券表 | WL_ | |
| 经纪人类 | BROKER | 经纪人表 | B_ |
| CASH_TRANSACTION | 现金交易表 | CT_ | |
| CHARGE | 交易费用表 | CH_ | |
| COMMISSION_RATE | 佣金率表 | CR_ | |
| SETTLEMENT | 结算表 | SE_ | |
| TRADE | 交易表 | T_ | |
| TRADE_HISTORY | 交易历史表 | TH_ | |
| TRADE_REQUEST | 交易请求表 | TR_ | |
| TRADE_TYPE | 交易类型表 | TT_ | |
| 交易所类 | COMPANY | 公司表 | CO_ |
| COMPANY_COMPETITOR | 公司竞争者表 | CP_ | |
| DAILY_MARKET | 日常市场统计表 | DM_ | |
| EXCHANGE | 交易所表 | EX_ | |
| FINANCIAL | 财政表 | FI_ | |
| INDUSTRY | 行业表 | IN_ | |
| LAST_TRADE | 最后交易表 | LT_ | |
| NEWS_ITEM | 新闻项表 | NI_ | |
| NEWS_XREF | 公司新闻参照表 | NX_ | |
| SECTOR | 公司领域表 | SC_ | |
| SECURITY | 证券表 | S_ | |
| 因素类 | ADDRESS | 地址表 | AD_ |
| STATUS_TYPE | 交易状态表 | ST_ | |
| TAXRATE | 税率表 | TX_ | |
| ZIP_CODE | 邮政编码表 | ZC_ |
表1 TPC-E基准中的表
TPC-E标准中定义的事务有12种,每个事务对应数据库管理系统中的一个或多个带输入和输出参数的存储过程,单个存储过程叫做一个事务帧。事务的种类有如下几种:
(1) Broker-Volume:经纪人交易统计事务,包含1个事务帧;
(2) Customer-Position:客户价值统计事务,包含3个事务帧;
(3) Market-Watch:市场观察事务,包含1个事务帧;
(4) Security-Detail:证券信息事务,包含1个事务帧;
(5) Trade-Lookup:交易查询事务,包含4个事务帧;
(6) Trade-Order:交易执行事务,包含6个事务帧;
(7) Trade-Status:交易状态事务,包含1个事务帧;
(8)Trade-Update:交易修正事务,包含3个事务帧;
(9) Market-Feed:市场跟踪事务,包含1个事务帧,该事务由TradeOrder事务引起;
(10)Trade-Result:交易结果更新事务,包含6个事务帧,该事务由TradeOrder事务引起;
(11)Data-Maintenance:数据维护事务,包含1个事务帧,每60秒执行一次;
(12)Trade-Cleanup:交易清理事务,包含1个事务帧,测试开始时执行一次,不强制使用。
前8种事务由证券公司执行,第9-10号事务由交易所执行,最后两种事务属于数据库维护事务,与客户操作无关。
2.2 逻辑架构
逻辑架构中的各个组件,如图1所示,包括Driver、Tier A和Tier B,其中Tier A和Tier B合起来叫做SUT(System Under Test待测试系统)。图中用三种颜色标识了不同内容:亮色部分代表TPC官方提供的程序,在测试中强制要求使用;黄色部分代表商用组件,比如数据库管理系统,数据库驱动程序;紫色部分代表必须由TPC-E测试的主办者实现的内容。
测试主办者实现的内容主要包括以下几点:
(1)Driving和Reporting:事务模拟驱动架构和统计报告,即Driver层测试程序的总控制模块(包括读取设置参数,建立各种队列、网络连接和工作线程等)和波形图以及报表显示模块;
(2)CE、MEE和DM:事务模拟器,在官方提供的EGenDriverCE、EGenDriverMEE和EGenDriverDM源代码包中分别实现了客户事务、交易所事务和数据库维护事务的随机产生类(注意:随机产生的是对应事务的存储过程的具体输入参数信息结构体),但是,如何调用这些类,如何把随机产生的事务封装成对应的可识别的网络消息,如何组织和管理众多的随机事务,并记录每个事务的开始时间和接收到返回信息的时间,都必须由测试主办者实现;
(3)EGenDriver Connector:驱动连接器,负责把随机产生的事务源源不断的发送出去,并接收返回信息;
(4)EGenTxnHarness Connector:事务连接器,负责接收网络消息,转换成对应的事务输入信息结构体,然后调用执行接口,并将返回信息通过网络发送到上层。

图1 测试架构的组件定义
(5)Frame Impletion:事务帧执行器,负责调用指定事务对应的存储过程,传递输入信息,并获取返回信息。每个事务对应数据库管理系统中的一个或多个存储过程,每个单独的存储过程叫做一个事务帧。
(6)Database Logic:测试主办者所写的事务帧,例如存储过程。
2.3 物理架构
图2是TPC-E测试标准的一个物理架构实例图。Driver层代表的是事务模拟和驱动层,可以把它当作是不同的客户在做各种不同的事务操作的模拟器,模拟的客户操作源源不断的从Driver层通过网络发送到下一层。Tier A层代表是与数据库进行连接的应用服务器层,它从网络接收Driver层发送来的各种操作指令,然后连接具体的数据库服务器,通过调用每种事务对应的存储过程来完成客户操作。Tier B层代表的是数据库服务器层,可以选择SQL Server、Oracle或者达梦数据库。当然,这只是一个大致的架构,在具体实现时,每一层并不一定要运行在不同的主机上,甚至在实现测试程序的时候,可以把相邻的层整合到一起。

图2 TPC-E测试标准物理架构实例图
3 测试程序的设计与实现
TPC官方提供了一些强制使用的代码和测试程序实现方法和规则的文档,图3给出了官方提供的测试实现样例总览图,每一种颜色代表的意义和上面提到的相同。
依据该图,将测试程序分三个部分来实现:TPCEDriver客户端程序、CEServer应用服务器程序和MEEServer应用服务器程序。TPCEDriver客户端程序模拟客户操作,负责产生随机事务信息并发送到CEServer服务器程序和MEEServer服务器程序,此外,还要传送TMEEIndexTable结构体给CEServer,里面保存了一组或多组TPCEDriver客户端的“主机名”和“端口号”,CEServer在处理TradeOrder事务时要用到该信息(通常情况下保存是本机的信息);CEServer模拟证券公司操作,执行CCE对象和CDM对象产生的事务,并返回输出信息,对于TradeOrder事务的处理比较特殊,不仅要返回输出信息,还要根据执行结果产生TradeRequest信息,然后根据TMEEIndexTable结构体中指定的地址,将它发送出去,由TPCEDriver客户端程序接收处理(用于CMEE对象产生随机事务);MEEServer模拟交易所操作,负责处理CMEE对象产生的事务,并返回输出信息。

图3 TPC-E测试实现样例总览图
3.1 TPCEDriver客户端程序
TPCEDriver客户端程序的功能逻辑主要包括如下几点:
(1)建立CCE、CMEE和CDM对象;
(2)继承CCESUTInterface、CMEESUTInterface和CDMSUTInterface类,名为CSUTInstance,该继承类负责把CCE、CMEE和CDM对象产生的随机事务信息结构体保存到特定的队列中;
(3)定义队列结构体SUTQueue,建立一个或多个队列,要求是FIFO(先进先出)类型;
(4)将指定的CSUTInsance对象与SUTQueue队列对象进行关联;
(5)将指定的CCE、CMEE或CDM对象与CSUTInsance对象进行关联;
(6)调用CDM对象的DoCleanupTxn()产生一个TradeCleanup事务信息结构体,发送到应用服务器执行,取消或中止所有未执行完的事务,也可以不执行;
(7)建立网络监听服务线程,负责接收CEServer执行TradeOrder事务返回的TradeRequest信息(用于CMEE对象),并保存到辅助队列中;
(8)建立CCE、CMEE和CDM对象的模拟驱动线程,源源不断的产生随机事务信息,并保存到特定的队列中;
(9)建立事务发送线程,从指定队列中获取随机事务信息结构体,并发送给CEServer或MEEServer;至于接收返回信息的过程,有同步和异步两种模式:使用同步模式时,事务发送线程会等待,直到发送的事务接收到返回信息,才继续发送下一个事务;使用异步模式时,事务发送线程不等待,直接发送下一个事务。为了减少建立接收返回信息线程的数量,提高网络通讯性能,并且方便统一管理,本测试程序中对于网络接收过程都调用了统一的完成端口模型;
(10)每秒统计一次执行结果,输出波形图,显示统计结果。
注意事项:
(1)CMEE对象依赖于CCE对象产生的TradeOrder事务的返回信息,只有当CCE对象产生的TradeOrder事务被执行后,将CEServer应用服务器发送的TradeRequest信息传递给CMEE对象的SubmitTradeRequest( PTradeRequest pTradeRequest ) 函数接口,才能产生新的MEE事务信息;另外,CDM对象每分钟只能产生一个Data-Maintenance(数据维护事务),而且要求必须在55秒内执行完毕。
(2)每个事务模拟类CCE、CMEE和CDM的对象只能对应一个事务队列;每个事务队列都是FIFO类型的;每个事务发送线程必须总是从同一个事务队列中取事务。
图4显示了TPCEDriver的驱动模型图:

图4 TPCEDriver驱动模型图
3.2 CEServer和MEEServer应用服务器程序
CEServer和MEEServer程序已经由微软公司提供,由于这两个程序是微软公司专门为SQL Server 2005数据库管理系统开发的,所以还需要修改数据库连接(ODBC方式)和操作的部分,以适应其他的数据库管理系统。

图5 CEServer执行Broker-Volume事务流程图
图5给出了CEServer程序执行Broker-Volume事务的流程图,CBaseServer是CCEServer和CMEEServer的基类,通过调用ListenAndDispatchThread(void *ptr)函数接口来进行网络监听,并为每一个新的连接建立单独的线程进行处理,具体的处理过程为:
(1)调用CCEServer的TCEServerLocals* CCEServer::InitializeLocal()接口来创建单独的TCEServerLocals结构体,初始化结构体中的相关对象:
CDBConnection m_DBConnection;
CBrokerVolumeDB m_dbBV;
CBrokerVolume m_BV;
其他事务对象没有列举出来;
(2)接收到一个完整的事务消息后,分析其事务类型,然后转到相应的事务类进行处理,对于Broker-Volume事务,调用CBrokerVolume类的函数接口void DoTxn( PBrokerVolumeTxnInput pTxnInput, PBrokerVolumeTxnOutput pTxnOutput )来执行事务;
(3) CBrokerVolume类的DoTxn函数接口中,会调用其CBrokerVolumeDB对象成员去执行具体的每一个事务帧;
(4) CBrokerVolumeDB类中具有CDBConnection对象成员,可以通过它进行数据库连接,提交事务或回滚事务等操作,具体执行SQL语句并分配语句句柄和段句柄的操作还是由CBrokerVolumeDB类实现。
至于其他事务的处理以及MEEServer的运行流程,和上面介绍的内容基本相似,这里就不在赘述。
4 总结
通过本文的介绍,希望能使读者了解TPC-E测试程序的系统架构和实现原理,当然,由于笔者水平有限,某些TPC-E官方文档中的英文术语可能翻译的不够准确,或者理解的不够透彻,如有不足之处,欢迎批评指正。
作者:龙涛(flybird_lt@yahoo.com.cn)
原文链接:http://blog.csdn.net/flybird_lt/archive/2008/03/20/2200447.aspx