基于数据库交易类中间件的性能分析方法

摘要

本发明公开了一种基于数据库交易类中间件的性能分析方法，包括如下步骤：a)定期采集每天业务调用情况、平均处理时间以及超长单笔业务的处理时间；b)预先设置数据业务的特定增长期；c)以当前业务分析前的一段时期作为采集周期，计算采集周期内每日数据业务的平均增长量；d)在特定增长期外，如果当前业务数量超过每日数据业务的平均增长量达到警告阀值，则对业务服务队列进行优化调整。本发明提供的基于数据库交易类中间件的性能分析方法，通过定期分段采集业务调用情况，能够准确预估应用业务变化的瓶颈所在，合理配置优化服务队列，保障中间件系统稳定运行，避免影响业务操作。

说明书

技术领域

本发明涉及一种数据库性能监测方法，尤其涉及一种基于数据库交易类中间件的 性能分析方法。

背景技术

Tuxedo(Transaction for UNIX has been Extended for Distributed Operation，即被 分布式操作扩展之后的UNIX事务系统)是一种交易类中间件，一般用于各种交易、 结算平台，比如电信、移动、金融等等的核心结算系统都会用到Tuxedo，多数运行 在linux、UNIX等操作系统上。一个TUXEDO应用系统的整体性能往往是由很多方 面决定的，操作系统、网络、数据库、以及应用系统的设计，程序的编写水平都会 影响该TUXEDO应用系统的性能。当性能不好时，主要表现在对客户段的请求响应 很慢。这时，如果用tmadmin中的pq命令察看，会发现有较多的请求在排队。这时 就要进行性能调优，而调优首先要确定整个系统的性能瓶颈所在，大致过程如下：

1、如果客户端与服务端之间在进行大批量的数据传输。可计算一下它们之间的 传输速度，并与FTP工具的速度相比较，来判断网络的速度是不是正常。看网络是 不是性能瓶颈。

2、如果客户端与服务端之间的数据传输量较少，但是服务端有大量的数据库操 作。则很有可能数据库是性能的瓶颈，可增加该服务的进程数来提高性能。如果增 加该服务的进程数之后，没起多大的作用。而且用数据库的性能分析工具观察发现 数据库的压力较大。则数据库是性能的瓶颈，应对数据库的进行性能调优。根据经 验，数据库往往是一个应用系统的性能瓶颈。

3、对UNIX/linux操作系统，可用sar,glance(hp)等命令察看。看CPU、IO、内 存的利用率是不是正常。对windows系统，可用任务管理器察看系统的资源使用情 况。可根据观察到的结果做相应的系统调优。

4、采用TUXEDO的性能分析工具txrpt。txrpt可统计出系统内每个SERVICE 的在某段特定时间内所处理的请求的总数及平均数。由此可见影响tuxedo中间件的 性能有很多方方面面，当表现只有一个请求队列排队，而服务有几百或者几千个,每 天的交易量几百万或者几千万次，如何有效的分析这些服务的瓶颈变得非常复杂。

现有的中间件性能监控方案多为单纯的信息采集与展示。例如：监控系统实时 采集业务，并将超过阀值的信息通知运维人员。监控系统关注的是信息本身，同时 运维人员成为了信息处理的终端，需高度持续关注每个服务队列告警情况，对已达 警告阀值的服务队列及时扩容处理等操作，如果处理不及时，将引发中间件严重故 障，直接影响业务操作。

随着移动运营商用户规模持续稳定增长和业务种类的不断增加，随之而来的是 业务量的大量增长，而承载关键业务的省级中心核心业务系统中间件如CRM营业、 BOSS营业、IVR客服、电子渠道、接口等中间件更是日益庞大。中间件服务数量不 断增加，应用业务量的不断增长，中间件承载压力越来越大，如何有效掌控业务量 增长情况，及时对服务性能使用中的瓶颈作出响应，保障中间件系统稳定运行，成 为中间件运维支撑的首要目标。

现有的中间件性能监控方案多为单纯的信息采集与展示。监控系统实时采集业 务，并将超过阀值的信息通知运维人员。监控系统关注的是信息本身，如“CRM营 业中的jf00013队列配置5个队列”，对于一个业务增多较少的业务来说，5个队列 可能意味本月服务单笔执行时间没有任何变化，对于一个业务增长在不同的时间段 业务调用比较集中时，5个队列的平均时间是正常而当单笔时间执行时间可能过长或 者出现等待，而影响业务。因此，运维人员获得信息后，需要通过分析解读，才能 将信息转化为知识，如“5个队列的在业务高峰期，部分单笔执行时间过长”。信息 本身是裸业务，没有好坏之分，只有形成了可视化才能引导工作方向。目前的监控 体系割裂了信息之间的关联性，没有对信息上下文之间的联系进行分析，缺少信息 向知识的自动转变的过程。同时运维人员成为了信息处理的终端，需高度持续关注 每个服务队列告警情况，对已达警告阀值的服务队列及时扩容处理等操作，如果处 理不及时，将引发中间件严重故障，直接影响业务。显然，面对支撑系统业务业务 量的高频增长，传统的基于信息的监控方法已无法满足精确运维的需要。

发明内容

本发明所要解决的技术问题是提供一种基于数据库交易类中间件的性能分析方 法，能够准确预估应用业务变化的瓶颈所在，合理配置优化服务队列，保障中间件 系统稳定运行，避免影响业务操作。

本发明为解决上述技术问题而采用的技术方案是提供一种基于数据库交易类中 间件的性能分析方法，包括如下步骤：a)定期采集每天业务调用情况、平均处理时 间以及超长单笔业务的处理时间；b)预先设置数据业务的特定增长期；c)以当前 业务分析前的一段时期作为采集周期，计算采集周期内每日数据业务的平均增长量； d)在特定增长期外，如果当前业务数量超过每日数据业务的平均增长量达到警告阀 值，则对业务服务队列进行优化调整。

上述的基于数据库交易类中间件的性能分析方法，其中，所述步骤d)中对业务 服务队列进行优化调整过程如下：若当前业务交易总数×平均处理时间÷服务队列 数大于警告阀值，则增加服务队列数。

上述的基于数据库交易类中间件的性能分析方法，其中，所述数据业务的特定 增长期根据历史采集数据进行设置，在特定增长期内，如果当前业务数量超过同期 特定增长期内的业务数量达到警告阀值，则对业务服务队列进行优化调整。

上述的基于数据库交易类中间件的性能分析方法，其中，所述数据业务的特定 增长期为BOSS数据库每月出账期。

上述的基于数据库交易类中间件的性能分析方法，其中，所述步骤c)在计算平 均增长量时剔除超长单笔业务以及因代码异常原因造成的每日增长量异常值。

上述的基于数据库交易类中间件的性能分析方法，其中，所述数据库交易类中 间件为tuxedo，所述步骤a)通过在ubbconfig配置文件中为所有服务添加 tuxerr.log保存交易详细明细；然后利用txrpt将所有主机的交易信息按每小时交 易总数，平均执行时间及每天每个服务交易总数进行统计；获取tuxedo服务名与服 务匹配对应关系，所述步骤d)计算服务平均处理时间t：

服务平均处理时间t＝交易总数×平均执行时间÷服务队列数÷3600，如果服 务平均处理时间t大于0.1秒，则增加服务队列数直至服务平均处理时间在0.1秒 内。

本发明对比现有技术有如下的有益效果：本发明提供的基于数据库交易类中间 件的性能分析方法，通过定期分段采集业务调用情况，能够准确预估应用业务变化 的瓶颈所在，合理配置优化服务队列，保障中间件系统稳定运行，避免影响业务操 作。

附图说明

图1为本发明基于数据库交易类中间件的性能分析架构示意图；

图2为本发明基于数据库交易类中间件的性能分析流程示意图；

图3为本发明利用Tuxedo的交易分析业务处理流程示意图。

具体实施方式

下面结合附图和实施例对本发明作进一步的描述。

图1为本发明基于数据库交易类中间件的性能分析架构示意图；图2为本发明 基于数据库交易类中间件的性能分析流程示意图。

请参见图1和图2，本发明提供的基于数据库交易类中间件的性能分析方法，包 括如下步骤：

步骤S1：定期采集每天业务调用情况、平均处理时间以及超长单笔业务的处理 时间；

步骤S2：预先设置数据业务的特定增长期；所述数据业务的特定增长期根据历 史采集数据进行设置，如设定BOSS数据库每月出账期为特定增长期；

步骤S3：以当前业务分析前的一段时期作为采集周期，计算采集周期内每日数 据业务的平均增长量；计算平均增长量时剔除超长单笔业务以及因代码异常原因造 成的每日增长量异常值；

步骤S4：在特定增长期外，如果当前业务数量超过每日数据业务的平均增长量 达到警告阀值，则对业务服务队列进行优化调整；具体优化调整过程如下：若当前 业务交易总数×平均处理时间÷服务队列数大于警告阀值，则增加服务队列数。在 特定增长期内，如果当前业务数量超过同期特定增长期内的业务数量达到警告阀值， 则对业务服务队列进行优化调整。

下面给出一个具体应用实例，某客服的CRM营业中间件、CRM客服中间件、BOSS 营业中间件、BOSS客服中间件、IVR自动台中间件、接口、电渠中间件、一级BOSS 中间件及应急、备服等共74套中间件,每套中间件有5000多个服务,结合业务生命 周期及服务智能预警系统定期对所有中间件服务统一进行分析、预处理操作。如图3 所示，本发明利用Tuxedo的交易分析业务处理流程如下：

1、获取tuxedo效易信息

例如某客户有74套tuxedo中间件，中间有CRM\BOSS营业客服、接口电渠tuxedo 中间件部署txrpt监控脚本,对tuxedo每笔交易中的信息处理时长进行统计当不分 析只记录信息本身，信息本身不可读，需要通过第三方工具按照每小时生成统计报 告。

i)tuxedo中间件ubbconfig配置文件中所有服务添加tuxerr.log用于保存 交易详细明细RQADDR＝"QryUserScore.Q1"CLOPT＝"-A-r-t-e /crmtux1/run/log/tuxerr.log。

i i)主机部署txrpt交易分析脚本，主要内容如下，将自动将所有主机的交易 信息转换统计按每小时交易总数，平均执行时间及每天每个服务交易总数的报表.

txrpt-d${mon}/${day}-s 0:00-e 23:59<$HOME/run/log/tuxerr.log> $HOME/monitor/txrpt/log/$ip.$LOGNAME.$year${mon}${day}。

2、获取tuxedo服务名与服务对应关系

Tuxedo中程序调用的是SERVICES，而配置文件中用的是Server。一个Server 中可以有多个SERVICES。Txrpt使用的是SERVICES,在分析中需要对所有SERVICES 与SERVER对应关系进行匹配。由于UBB配置文件中配置为SERVER,运维主要针对 SERVER进行分析、总结、优化。本案中匹配完成对UBB进行优化、修改等操作。

i)通过tuxedo管理工作tmadmin获取服务对应关系；

i i)对txrpt报告与获取的服务对应关系做匹配；

i i i)公式计算服务是否需要优化；

服务平均处理时间t＝(交易总数×平均执行时间÷服务队列数÷3600)≤0.1

将txrpt生成的交易信息分析每个服务每天调用的高峰期所处的时间段。跟据 公式将调用次数乘以平均执行时间获取总时间。需要将总时间除以services数量 (ubbconfig中的MIN值)在除以3600秒，由于需要提前量将服务提升10倍解决业 务并发，所以除以3600秒后应该小于0.1，就可以获取每小时3600秒内是否可以满 足业务处理要求，而不产生服务排队。而对于服务平均处理时间大于0.1的则需要 关注优化，调整服务队列数，使得服务平均处理时间控制在0.1秒以内。

虽然本发明已以较佳实施例揭示如上，然其并非用以限定本发明，任何本领域 技术人员，在不脱离本发明的精神和范围内，当可作些许的修改和完善，因此本发 明的保护范围当以权利要求书所界定的为准。