法律状态公告日
法律状态信息
法律状态
2013-06-05
授权
授权
2011-09-28
实质审查的生效 IPC(主分类):H04L12/26 申请日:20110512
实质审查的生效
2011-08-17
公开
公开
技术领域
本发明涉及一种服务器性能的评测系统。
背景技术
银行中间业务是指商业银行在资产业务和负债业务的基础上,利用技术、信息、机构网络、资金和信誉等方面的优势,不运用或较少运用银行的资财,以中间人和代理人的身份替客户办理收付、咨询、代理、担保、租赁及其他委托事项,提供各类金融服务并收取一定费用的经营活动。
在实际银行中间业务的应用环境中,包含了一系列后端数据处理及银行通用代收代付、代缴、批量、签约等核心中间业务,是典型的OLTP应用。银行中间业务应用环境由三部分实体所组成,即第三方合作者、客户和银行。其中第三方合作者一般指大公司、企业等大客户,与银行方面建立某种合作关系,委托银行与普通客户进行与中间业务有关的金融交易等;客户就是每个去银行交易的个体。客户、第三方合作者及银行自身的行为及它们间的交互事务处理就构成了整个银行中间业务的应用环境。典型的银行中间业务的业务模型如图1所示。
银行中间业务作为在线事务处理系统(OLTP,On-Line Transaction Processing)的典型业务,具有高吞吐量、高并发等特点,对应用在银行中间业务环境下的高端服务器的性能提出更高的要求。现有的OLTP性能测试方法主要是基于性能测试基准,事务处理委员会(TPC,Transaction Processing Council)推出的一系列针对OLTP的性能测试基准,如TPC-C,TPC-E。但是这种方法存在明显的缺陷,服务器生产厂商选择测试基准的出发点是向用户证明自己产品性能的优越性,为了这种优越性,厂商往往会提高被测机的硬件配置,屏蔽系统中的与测试无关但是在实际应用中需要的服务,而用户关心的是在特定的硬件配置及特定的应用下,系统是否能满足他们的性能,因此服务器生产厂商提供的测试结果并不完全可信。
发明内容
本发明的目的是提供一种面向银行中间业务的高端服务器性能评测系统,以解决现有技术屏蔽了评测系统中的与测试无关但是在实际应用中需要的服务的问题。它包括模型定制模块1、初始数据产生及装载单元2、负载模拟子系统3、待测数据库服务器4、监控模块5、控制管理台6和统计分析模块7;
模型定制模块1:在此模块中对银行中间业务模型中的数据库模型实现数据库中的建立数据表、建立各表的主外键约束和索引;
初始数据产生及装载单元2:在进行加压测试前,向待测数据库服务器4中载入初始数据;
负载模拟子系统3:负载模拟子系统的作用是产生大量并发虚拟用户,向待测数据库服务器4发送事务请求,以模拟真实世界中用户的操作行为;
待测数据库服务器4:待测的银行中间业务在线事务处理性能服务器是典型的数据库服务器,在其上完成银行中间业务模型中定义的事务处理过程;
监控模块5:在测试过程中实时监控待测数据库服务器4的资源利用状况;一旦发现测试不满足预期目标可以及时终止测试以节省时间;
控制管理台6:这一模块作为整个评测系统的控制中心,控制其他模块相互协调工作,它包含人机交互的操作,测试发起者根据评测目标部署测试场景,指定负载产生方式、虚拟用户数;
统计分析模块7:统计分析模块根据记录的测试过程中事务的运行结果,为测试人员提供测试结束后统计分析的功能。
附图说明
图1是典型的银行中间业务模型示意图,图2是本发明的结构示意图,图3是本发明实施方式二的结构示意图,图4是事务ContractCreate模型中事务三方操作关系示意图;图5是事务ContractModify模型中三方操作关系示意图,图6是事务ContractCancel模型中事务三方操作关系示意图,图7是事务Trade-Charge模型中事务三方操作关系示意图,图8是事务Trade-Payment模型中事务三方操作关系示意图,图9是事务BalanceLookup模型中事务三方操作关系示意图,图10是事务ContractLookup模型中事务三方操作关系示意图,图11是事务TradelookUp模型中事务三方操作关系示意图。
具体实施方式
具体实施方式一:下面结合图2具体说明本实施方式。本实施方式包括模型定制模块1、初始数据产生及装载单元2、负载模拟子系统3、待测数据库服务器4、监控模块5、控制管理台6和统计分析模块7;
模型定制模块1:在此模块中对银行中间业务模型中的数据库模型实现数据库中的建立数据表、建立各表的主外键约束和必要的索引,可采用手工编码或者第三方程序如SQLDeveloper完成上述功能。本实施方式用自动化脚本控制整个过程,实现数据库部署的自动化。
初始数据产生及装载单元2:在进行加压测试前,向待测数据库服务器4中载入一定量的初始数据。单线程导入数据的过程需要耗费很长时间,因此本文采用多线程的方式,在建立外键、索引以及约束前实现数据的导入,加快了数据导入速度。另外,为实现数据规模的动态可配置,本实施方式提供了测试人员通过控制管理台定制数据规模,初始数据导入时获取控制管理台的XML配置文件,并根据配置导入所需的数据。
负载模拟子系统3:负载模拟子系统的作用是产生大量并发虚拟用户,向待测数据库服务器4发送事务请求,以模拟真实世界中用户的操作行为;负载模拟子系统3中的控制器执行预先定义好的测试场景,通过控制高速网络中单台或者多台PC机作为负载发生器,运行模拟客户端程序产生虚拟用户,并发向待测目标机发出事务请求。负载模拟子系统3一般包括初始配置管理、随机数生成、应用负载生成、网络通讯和记录等模块。
待测数据库服务器4:待测的银行中间业务在线事务处理性能服务器是典型的数据库服务器,在其上完成银行中间业务模型中定义的事务处理过程;
待测数据库主要包括网络通讯、服务处理、事务实现及调用、数据库接口、数据库系统中事务处理逻辑几个模块。网络通讯模块负责接收负载模拟客户端的事务请求包并返回事务响应包;服务处理模块负责请求事务的调用及事务响应包的封装,这里涉及到数据库连接方式的选择,如一个模拟用户对应一个数据库连接或者采用数据库连接池;对于事务的实现,事务逻辑参考BIBmodel(银行业务模型)中的定义,实现方式都离不开数据库接口,一般可采用SQL语句交互或数据库存储过程的方式。
监控模块5:在测试过程中实时监控待测数据库服务器4的资源利用状况。一旦发现测试不满足预期目标可以及时终止测试以节省时间。对于交易处理性能指标我们根据负载模拟系统在运行的过程中返回的信息进行计算;
控制管理台6:这一模块作为整个评测系统的控制中心,控制其他模块相互协调工作,它包含一些人机交互的操作,测试发起者根据评测目标部署测试场景,指定负载产生方式、虚拟用户数等操作,还要在测试过程中对一些异常状况做出及时处理,以提高测试结果的准确性。本实施方式能提供对多个负载模拟客户端协同控制的支持,用户可以根据具体的测试需求定义测试配置,模拟客户端数量、实际用户数量、负载增长方式、事务比例关系,并在测试过程中收集各项性能指标,包括客户端交易指标每秒事务数、事务响应时间、目标机资源等信息,用于测试结果分析及测试报告的撰写。
统计分析模块7:统计分析模块根据记录的测试过程中事务的运行结果,如每秒事务数、事务响应时间、服务拒绝率以及目标机性能资源等信息,为测试人员提供测试结束后统计分析的功能。
具体实施方式二:下面结合图3具体说明本实施方式。本实施方式与实施方式一相比特点是:负载模拟子系统3包括初始配置管理器3-1、随机数生成器3-2、应用负载生成器3-3、网络通讯单元3-4和记录装置3-5;
初始配置管理器3-1:初始配置管理器从控制管理台6请求数据规模配置文件信息,从控制管理台6给出的配置文件中读取测试时长、事务混合比例、模拟用户数等信息,然后启动等量的用户模拟器,调用其他各个模块产生工作负载。
随机数生成器3-2:一般而言,性能测试的数据并非实际应用中的真实数据,而是程序生成的模拟数据,对此应提供随机数据生成器,以生成给定范围内的各种类型的随机数据。
应用负载生成器3-3:对于事务处理性能评测而言,负载生成模块包括事务类型的生成和对应事务参数的生成,本实施方式支持测试人员通过控制管理台6动态配置事务的混合比例,应用负载生成器根据混合比例生成事务类型,根据数据规模配置文件调用随机数生成器3-2产生满足一定约束的事务输入参数。
网络通讯单元3-4:网络通讯单元提供与待测数据库服务器4的通讯机制,完成将事务类型及输入参数信息发送给待测数据库服务器4,并接收待测数据库服务器4返回的事务处理信息。
记录装置3-5:在网络通讯单元3-4发送请求前和接收响应信息后记录时间,计算事务响应时间并记录响应的事务处理状态,向控制管理台6返回实时监控所必须的信息,并在本地形成事务处理日志文件。
在负载发生模块的设计中,为了避免网络中间设备,比如网关等设备成为负载子系统的瓶颈,除了尽量提高这些中间设备的性能外,更重要的是负载发生器应比较均衡的分布于不同的网段,来减小网关等设备对测试的影响。
具体实施方式三:本实施方式与实施方式一相比特点是负载模拟子系统3中的银行中间业务负载仿真模型包括数据库子模型、事务模型和事务的驱动模型;
所述数据库子模型包括:描述第三方合作伙伴基本信息表、与第三方合作伙伴存在业务往来的账户信息表、员工工资表、客户基本信息表、客户账户信息表、描述与银行中间业务相关的银行方面提供的产品信息表、渠道信息表、交易信息表、邮政编码表和签约类型表;
事务模型中的事务包括:八个交易类事务和三个系统维护类事务,交易类事务根据事务触发方式不同分为六个用户触发型事务和二个定时触发型事务;用户触发型事务模拟银行用户或第三方合作伙伴的行为,根据用户提供的事务输入参数触发事务,该类事务包括签约事务、签约修改事务、签约取消事务、账户余额查询事务、用户签约查询事务和用户交易记录查询事务;定时触发型事务根据签约事务产生的信息定时由系统触发,该类事务包括代收代缴事务和代发代付事务,系统维护类事务模拟八个交易类事务进行数据维护操作,包括数据一致性事务、交易清理事务和事务运行记录;
事务驱动模型:六类用户触发型事务,需要用户或第三方初始化设定事务配置比例比及负载业务的时间分布;用户触发型事务负载生成函数G(t)表示如下:
其中,gi(t)表示实体驱动型事务的时间分布函数,ki为事务模型初始化设定的事务配置百分比率;
对于两类定时触发型事务,由于签约事务参数将会影响两类事务的运行频度,为保证事务的分布符合现实银行中间业务规律,又能保证事务随机性,同时保证测试的可重复性;对签约参数进行反馈调度;两类定时触发型事务支持按星期、月、季度、年进行签约运行以及随机运行方式;因此,签约事务参数包括按星期、月、季度、年度和随机共五类参数;定时触发型事务负载生成函数F(t)表示如下:
(2)
其中,fij(t)表示定时触发型事务i的第j类参数的时间分布函数,fijn(t)表示事务i的第j类签约参数在第n次事务发生时的生成概率;kijn为事务i的第j类签约参数在第n次事务发生时的加权值;当kj(n)为1时,表示选择第j类签约参数,kj(n)随机生成,其生成为1的概率为wj(n),可由如下公式决定:
(3)
当第n次选择时生成第i个签约参数,则当前选择概率为wi(n),wi(n+1)表示第n+1生成第i类参数的概率,第j签约参数被第n次选中的概率为wj(n),第n+1次概率为wj(n+1);αj表示第i类参数的反馈因子。
银行中间业务是指商业银行在资产业务和负债业务的基础上,以中间人和代理人的身份替客户办理收付、咨询、代理、担保、租赁及其他委托事项,提供各类金融服务并收取一定费用的经营活动。在资产业务和负债业务两项传统业务中,银行是作为信用活动的一方参与;而中间业务则不同,银行不再直接作为信用活动的一方,扮演的只是中介或代理的角色,通常实行有偿服务。银行中间业务是银行的重要业务部分,关系到大量的现代商业交易需求,也是银行中可以进行自动化操作的主要业务部分。为保证对高端容错计计算机进行关于银行中间业务事务处理性能评测的合理性和可靠性,需建立针对典型银行中间业务模型(BIBmodel),此模型抽象了现实中的银行(Bank),银行个人用户(Customer),银行第三方合作伙伴(Partner)三种实体,如图1显示了三种实体之间的业务关系。
在BIBmodel数据库子模型中定义了24张数据表,这些数据表是通过对银行各种各样的中间业务进行调研,通过发现该类业务的中通用的数据表项,去除非经典的数据项而产生的。这些数据表中包含了银行中间业务操作的典型的数据项。
在BIBmodel中定义了各张数据表的各列类型和长度,这些值全是通过银行调研得到的,表的类型和长度的合理定义能够很好的满足性能的要求,同时节省不必要的存储空间的浪费。
(一)事务表定义
本银行中间业务数据库模型共有24张独立的表,总体分为四种类型,分析如下:
·Partnet表:有3张表,描述第三方合作伙伴基本信息表及账户信息,员工工资表;
·Customer表:有2张表,描述客户基本信息和客户账户信息等;
·Bank表:有13张表,描述与银行中间业务相关的银行方面提供的产品、渠道、交易等信息;
·Dimension表:有6张表,描述常规通用信息的表,如邮政编码表Zip_Code和签约类型表Contract_Type等;
表1
(二)数据库初始记录配置
1、表记录的数的统计关系
为更加真实的仿真银行中间业务,在BIBmodel模型中还提供了给表的数量上的关系,如有100%的Customer有一个账户,30%的Customer有2到3个账户,4%的Customer拥有3个以上的账户。在统计上平均每个用户有2.37个账户。同样对Partner也用同样的关系。简而言之就是除OUT_CONTRACT、IN_CONTRACT、PROCESS_CONTROL、BUSINESS_SERIAL、FAILED_TRANS表外其他的每张有外键约束的表都存在上述的统计定义。
表2
2、数据初始化历史记录数
所谓的数据库历史记录是数据表BUSINESS_SERIAL的记录条数。历史记录数跟数据库规模有关,在磁盘中保存一定时间段内的历史记录,通常是1到3个月的历史记录。而有10万个账户的数据库有数据历史记录数一定是比1万个账户的数据库历史记录多,具体值由测试参数和历史记录统计函数计算可得。
在BIBmodel中给出了初始化历史记录的统计规律。该统计规则需银行中提供数据。
(三)事务定义及统计约束
BIBmodel中各个事务发生比例及响应时间约束等信息如表3所示。值得注意的是,定时触发类事务代发代付事务和代收代缴事务是根据签约事务运行指定的计划进行定时执行的。BIBmodel中定义了事务响应最大容忍时间,若一个事务处理过程超过对应的最大容忍时间,则用户将不再等待事务执行结束,默认事务执行失败。
表3BIBmodel事务模型说明
事务Contract-Create模型
1、事务简述
签约事务Contract-Create适用于客户在网点办理的签约交易或个人客户经理/客户自己通过特色电子渠道办理的签约交易;主要考虑两类签约事务:第三方与银行签约或个人客户与银行签约;
步骤1.查询ContractID,
如果不存在,新建签约,存在出错
步骤2.变量初始化,及自动生成。数据补全
步骤3.插入记录
步骤4.提交事务
2、事务三方操作关系,如图4所示
3、事务参数及说明
说明:时间控制,每个月30天;每年365天;不区分工作日与休息日;系统没有节假日。
CRF_ID触发类型:
4、事务各参数输入执行概率
事务Contract-Modify模型
1.事务简述
签约修改事务Contract-Modify适用于客户或第三方在网点办理的修改已有签约交易;
主要考虑两类签约事务:第三方与银行签约或个人客户与银行签约;
步骤1.查询ContractID,
如果存在,修改签约,不存在出错,
步骤2.变量初始化,及自动生成。数据补全
步骤3.更新记录
步骤4.提交事务
2.事务三方操作关系如图5所示
3.事务参数
4.事务各参数输入执行概率
事务Contract-Cancel模型
1.事务简述
说明:仿真签约取消操作;外部指定删除已签约的事务,或者签约到期,自动删掉签约
步骤1:检查是In_Contract还是Out_Contract删除
步骤1.1:Out_contract删除
步骤1.2:删除与In_Contract相关的Out_Contract
步骤1.2.2:In_Contract删除
2.事务三方操作关系如图6所示
3.事务参数
4.事务各参数输入执行概率
事务Trade-Charge模型
1.事务简述
说明:完成银行中间业务中代发代付业务,如代付工资,奖金等
步骤:检查是定时还是临时Trade-Charge
步骤2.1:个人临时Trade-Charge
步骤2.2:第三方临时Trade-Charge
步骤3.1:个人定时Trade-Charge
步骤3.2:第三方定时Trade-Charge
2.事务三方关系如图7所示
3.事务参数
4.事务各参数输入执行概率
事务Trade-Payment模型
1.事务简述
说明:完成银行代收代缴业务,如交水电费,手机费等
步骤:检查是定时还是临时TradePayment
步骤2.1:临时TradePayment
步骤2.2:定时TradePayment
2.事务三方操作关系如图8所示
3.事务参数
4.事务各参数输入执行概率
事务Balance-Lookup模型
1.事务简述
说明:仿真用户或第三方对其名下的账户余额的查询;查询包括:交易详细记录查询、指定个人账户查询、指定第三方账户查询、个人所有账户查询、第三方所有账户查询
步骤Frame1:交易详细记录查询
步骤Frame2:个人所有账户查询
步骤Frame3:第三方所有账户查询
步骤Frame4:指定个人账户查询
步骤Frame5:指定第三方账户查询
2.事务三方操作关系如图9所示
3.事务参数
4.事务各参数输入执行概率
事务Contract-Lookup模型
1.事务简述
说明:仿真用户或第三方对其名下的已有的签约的查询;查询包括:指定个人账户查询、指定第三方账户查询、个人所有账户查询、第三方所有账户查询
步骤Frame1:个人所有账户查询
步骤Frame2:第三方所有账户查询
步骤Frame3:指定个人账户查询
步骤Frame4:指定第三方账户查询
2.事务三方操作关系如10所示
3.事务参数
4.事务各参数输入执行概率
事务Trade-LookUp模型
1.事务简述
说明:仿真用户或第三方对其自身通过银行中介服务进行的交易的记录查询;查询包括:交易详细记录查询、指定个人账户查询、指定第三方账户查询、个人所有账户查询、第三方所有账户查询
步骤Frame1:交易详细记录查询
步骤Frame2:个人所有账户查询
步骤Frame3:第三方所有账户查询
步骤Frame4:指定个人账户查询
步骤Frame5:指定第三方账户查询
2.事务三方操作关系如图11所示
3.事务参数
4.事务各参数输入执行概率
事务Data-Maintenance模型
1.事务简述
说明:该事务完成数据库数据的一致性与数据表字段的约束维护。
1)保障各账户的余额数大于0
2)保障数据库各记录约束关系、维护数据的一致性
2.事务操作
该事务不是三方交易事务,属于辅助事务。在此不提供UML图。
3.事务参数
系统自动读取数据库中各表。
4.事务各参数输入执行概率
无
事务Trade-Cleanup模型
1.事务简述
说明:该事务完成数据库数据在线历史记录管理和事务,事务一致性维护。
1)定期删除过期的交易历史
2)定期重做失败事务
2.事务操作
该事务不是三方交易事务,属于辅助事务。在此不提供UML图。
3.事务参数
有系统从FAILED_TRANS表读取
4.事务各参数输入执行概率
无
事务Trade-record模型
1.事务简述
说明:该事务用于记录写类型事务(事务1-5)的输入,已完成事务的重做,保障事务执行成功。
1)记录事务1-5的输入操作,和执行成功与否
2.事务操作
该事务不是三方交易事务,属于辅助事务。在此不提供UML图。
3.事务参数
4.事务各参数输入执行概率:无
机译: 一个面向客户和零售商的智能店内购物平台。这样一来,客户可以通过智能手机选择商品,进行扫描并为商品付款,并在不需人工干预的情况下结帐。该系统使用高端技术,例如用于反盗窃的人工智能,自动决策,计算机视觉,称重技术,电子电路和RFID。该框架使用复杂的IoT(物联网)技术和自学习算法,大数据分析,客户参与以及使用数据提取和知识挖掘的模式分析。
机译: 通过单值服务器性能指标评估服务器性能
机译: 这些中使用的服务器性能测量方法,服务器性能测量系统和计算机程序