CN103248511A - 一种单点业务性能的分析方法、装置和系统 - Google Patents

一种单点业务性能的分析方法、装置和系统 Download PDF

Info

Publication number
CN103248511A
CN103248511A CN2012100327758A CN201210032775A CN103248511A CN 103248511 A CN103248511 A CN 103248511A CN 2012100327758 A CN2012100327758 A CN 2012100327758A CN 201210032775 A CN201210032775 A CN 201210032775A CN 103248511 A CN103248511 A CN 103248511A
Authority
CN
China
Prior art keywords
rpc
log information
service end
sql
client
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN2012100327758A
Other languages
English (en)
Other versions
CN103248511B (zh
Inventor
杨银芳
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Kingdee Software China Co Ltd
Original Assignee
Kingdee Software China Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Kingdee Software China Co Ltd filed Critical Kingdee Software China Co Ltd
Priority to CN201210032775.8A priority Critical patent/CN103248511B/zh
Publication of CN103248511A publication Critical patent/CN103248511A/zh
Application granted granted Critical
Publication of CN103248511B publication Critical patent/CN103248511B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Abstract

本发明公开了一种单点业务性能的分析方法、装置和系统。本发明实施例通过确定需要分析的单点业务所对应的事件,来获取对应的客户端RPC日志信息,然后再通过客户端RPC日志信息获取到对应的服务端RPC日志信息,最后再结合客户端RPC日志信息和服务端RPC日志信息对单点业务的性能进行分析,从而实现了对客户端和服务端进行联查的目的,可以准确地对单点业务的性能问题进行定位,有利于改善单点业务的性能。

Description

一种单点业务性能的分析方法、装置和系统
技术领域
本发明涉及通信技术领域,具体涉及一种单点业务性能的分析方法、装置和系统。
背景技术
单点业务性能的分析,指的是对该单点业务在客户端或服务端的运行情况进行追踪、收集和分析。通过对单点业务性能的分析,可以定位该单点业务的性能问题,从而使得程序员可以根据该性能问题及时作出修改,有利于提高单点业务的性能。
在现有技术中,对单点业务性能的分析主要有三种,第一种是在oracle数据库(甲骨文数据库)层面上实现,主要通过会话级别打开SQL_trace(oracle数据库中的一种SQL跟踪手段)开关,收集SQL_trace文件来进行分析;一种是通过实例级别打开SQL_trace开关,收集SQL_trace文件来进行分析;另一种是通过oracle数据库的事件管理器(Oracle Enterprise manager)工具来查找耗时的SQL语句来进行分析。
在对现有技术的研究和实践过程中,本发明的发明人发现,不管采用以上的哪种分析方法,都无法对客户端和服务端进行联查,不利于定位单点业务的性能问题,从而不利于改善单点业务的性能。
发明内容
本发明实施例提供一种单点业务性能的分析方法、装置和系统,可以对客户端和服务端进行联查,精确地定位单点业务的性能问题。
一种单点业务性能的分析方法,包括:
确定需要分析的单点业务所对应的事件;
根据所述事件获取对应的客户端远程过程调用协议(RPC,RemoteProcedure Call Protocol)日志信息;
根据客户端RPC日志信息获取对应的服务端RPC日志信息;
根据所述客户端RPC日志信息和服务端RPC日志信息分析所述单点业务的性能。
一种单点业务性能的分析装置,包括:
确定单元,用于确定需要分析的单点业务所对应的事件;
第一获取单元,用于根据所述事件获取对应的客户端远程过程调用协议RPC日志信息;
第二获取单元,用于根据客户端RPC日志信息获取对应的服务端RPC日志信息;
分析单元,用于根据所述客户端RPC日志信息和服务端RPC日志信息分析所述单点业务的性能。
一种企业资源计划系统(ERP,Enterprise Resource Planning),包括本发明实施例提供的任一种单点业务性能的分析装置。
本发明实施例通过确定需要分析的单点业务所对应的事件,来获取对应的客户端RPC日志信息,然后再通过客户端RPC日志信息获取到对应的服务端RPC日志信息,最后再结合客户端RPC日志信息和服务端RPC日志信息对单点业务的性能进行分析,从而实现了对客户端和服务端进行联查的目的,可以准确地对单点业务的性能问题进行定位,有利于改善单点业务的性能。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本发明的一些实施例,对于本领域技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1是本发明实施例提供的单点业务性能的分析方法的流程图;
图2是本发明实施例提供的单点业务性能的分析方法的另一流程图;
图3a是本发明实施例提供的客户端RPC日志信息的统一建模语言(UML,Unified Modeling Language)模型图;
图3b是本发明实施例提供的第一服务端RPC日志信息的UML模型图;
图3c是本发明实施例提供的第二服务端RPC日志信息的UML模型图;
图4是本发明实施例提供的单点业务性能分析装置的结构示意图;
图5是本发明实施例提供的单点业务性能分析装置的另一结构示意图。
具体实施方式
下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域技术人员在没有作出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。
本发明实施例提供一种单点业务性能的分析方法、装置和系统。以下分别进行详细说明。
实施例一、
本实施例将从单点业务性能分析装置的角度进行描述。该单点业务性能分析装置具体可以作为独立的实体实现,也可以集成在客户端、服务端或其他设备中,比如,集成在企业资源计划(ERP,Enterprise Resource Planning)系统的客户端或服务端中,等等。
一种单点业务性能的分析方法,包括:确定需要分析的单点业务所对应的事件;根据所述事件获取对应的客户端远程过程调用协议RPC日志信息;根据客户端RPC日志信息获取对应的服务端RPC日志信息;根据所述客户端RPC日志信息和服务端RPC日志信息分析所述单点业务的性能。
如图1所示,具体流程可以如下:
101、确定需要分析的单点业务所对应的事件;
102、根据步骤101中确定的事件获取对应的客户端RPC日志信息;
其中,客户端RPC日志信息可以包括事件名、程序类名与方法名、访问标识、RPC调用的时间、RPC调用次数、RPC调用的时长和RPC总得调用时间等信息;
103、根据客户端RPC日志信息获取对应的服务端RPC日志信息;
其中,服务端RPC日志信息可以包括两个RPC日志信息,一个是针对SQL脚本与SQL所在的程序类名与方法名的SQL日志信息,另一个是针对SQL执行计划(Plan)的计划日志信息,为了描述方便,在本发明实施例中将SQL日志信息称为第一服务端RPC日志信息,而将计划日志信息称为第二服务端RPC日志信息,这两种RPC日志信息的内容具体可以如下:
(1)第一服务端RPC日志信息;
该第一服务端RPC日志信息具体可以包括程序类名与方法名、结构化查询语言(SQL,Structured Query Language)语句、SQL的执行时间、SQL标识和数据库方面总得耗用时间等信息;
(2)第二服务端RPC日志信息;
该第二服务端RPC日志信息具体可以包括SQL语句和执行计划信息等信息。
则根据客户端RPC日志信息获取对应的服务端RPC日志信息具体可以如下:
根据客户端RPC日志信息中的访问标识在第一服务端RPC日志信息中联查到对应的程序类名与方法名、SQL语句、SQL的执行时间、SQL标识和数据库方面总得耗用时间;
根据第一服务端RPC日志信息中的SQL标识在第二服务端RPC日志信息中联查到对应的SQL语句和执行计划信息。
104、根据步骤102中获取到的客户端RPC日志信息和步骤103中获取到的服务端RPC日志信息分析该单点业务的性能。例如,具体可以如下:
(1)根据客户端RPC日志信息中的事件名、程序类名与方法名、访问标识、RPC调用的时间、RPC调用次数、RPC调用的时长和RPC总得调用时间分析该单点业务在客户端上的程序性能;
(2)根据第一服务端RPC日志信息中的程序类名与方法名、SQL语句、SQL的执行时间、SQL标识和数据库方面总得耗用时间分析该单点业务在服务端上的程序性能;
(3)根据第二服务端RPC日志信息中的SQL语句和执行计划信息得到执行计划的时间,根据执行计划的时间分析所述单点业务在服务端上的SQL性能。
其中,客户端RPC日志信息和服务端RPC日志信息为根据单点业务的执行情况而预先生成的日志信息,即,在确定需要分析的单点业务所对应的事件之前,该方法还可以包括:
调用客户端的RPC程序,以及调用服务端的RPC程序;
在客户端和服务端执行单点业务时,利用调用的客户端的RPC程序对单点业务的执行情况进行监控,并在客户端生成客户端RPC日志信息;以及,利用调用的服务端的RPC程序对单点业务的执行情况进行监控,并在服务端生成服务端RPC日志信息。
由上可知,本实施例通过确定需要分析的单点业务所对应的事件,来获取对应的客户端RPC日志信息,然后再通过客户端RPC日志信息获取到对应的服务端RPC日志信息,最后再结合客户端RPC日志信息和服务端RPC日志信息对单点业务的性能进行分析,从而实现了对客户端和服务端进行联查的目的,可以准确地对单点业务的性能问题进行定位,有利于改善单点业务的性能。
实施例二、
根据实施例一所描述的方法,一下将举例作进一步详细说明。
首先,可以分别为客户端RPC程序和服务端RPC程序设置一个触发开关,其中,在本发明实施例中,客户端RPC程序的触发开关称为客户端的RPC开关,而服务端RPC程序的触发开关则称为服务端的RPC开关。
其次,当需要为某个单点业务生成RPC日志信息(即在客户端生成客户端RPC日志信息,在服务端生成服务端RPC日志信息)时,就可以分别启动客户端的RPC开关和服务端的RPC开关,从而触发客户端RPC程序和服务端RPC程序的调用,然后,在客户端和服务端执行单点业务时,分别利用客户端RPC程序和服务端RPC程序对单点业务的执行情况进行监控,使得可以在客户端生成客户端RPC日志信息,以及在服务端生成服务端RPC日志信息,这样,后续就可以利用客户端RPC日志信息和服务端RPC日志信息快速定位该执行的单点业务的性能。
以下将以ERP系统中的单点业务A为例作详细说明。其中,该ERP系统包括ERP客户端和ERP服务端(简称为客户端和服务端),且客户端和服务端中均集成有本发明实施例提供的单点业务性能分析装置。
参见图2,单点业务A性能的分析方法流程具体可以如下:
201、客户端接受用户的设置,以触发客户端的RPC开关的开启;
例如,具体可以接受用户在服务端所进行的设置,比如接收用户在服务端输入的客户端RPC开关的启动指令,然后根据该启动指令触发客户端RPC开关的开启;或者,
具体也可以接受用户在客户端所进行的设置,比如接收用户在客户端输入的客户端RPC开关的启动指令,然后根据该启动指令触发客户端RPC开关的开启。
202、服务端接受用户的设置,以触发服务端的RPC开关的开启;
例如,具体可以接收用户在客户端输入的服务端RPC开关的启动指令,然后根据该启动指令触发服务端RPC开关的开启。
其中,步骤201和步骤202的执行可以不分先后。
203、当客户端的RPC开关被开启时,触发单点业务性能分析装置调用客户端RPC程序,同理,当服务端的RPC开关被开启时,也触发单点业务性能分析装置调用ERP服务端RPC程序,于是,客户端RPC程序和ERP服务端RPC程序开始运行。
204、ERP系统执行单点业务A。
205、单点业务性能分析装置利用调用的客户端的RPC程序对单点业务A的执行情况进行监控,并在客户端生成客户端RPC日志信息“rpcD.V60SP1.log”;以及,单点业务性能分析装置利用调用的服务端的RPC程序对单点业务A的执行情况进行监控,并在服务端生成服务端RPC日志信息:“RpcSqlD.V60SP1.log”和“Sq1PlanD.V60SP1.log”。
其中,客户端RPC日志信息,以及两个服务端RPC日志信息的结构可以如下:
参见图3a、图3b和图3c,这些图为各种RPC日志信息的UML模型图,其中,在这些图中,粗线框表示活动类,粗线框中的内容表示类的属性,属性后可以跟上类型甚至缺省取值,比如“name:string”,其中,name即为类的属性,而“string”则是“name”的类型,意思为“字串型”。此外,空心实线箭头表示“一般化(generalization)”,具体表示位于箭头起始的对象继承于箭头指向的对象。“实心菱形到实线箭头”和“实线箭头”,表示“关联(Association)”,具体表示位于箭头起始的对象聚合箭头指向的对象;其中,“实心菱形到箭头”上的数字“1”表示一个对象,数字“0..*”表示零个或多个对象。
(1)客户端RPC日志信息:rpcD.V60SP1.log;
如图3a所示,该图为客户端RPC日志信息的UML模型图。
从图3a可以看出,RpcLog为一个日志文件。其中,RpcLog属于活动类,包括属性“name”,“name”意思为“名称”,其类型为“string”。
“RpcLog”聚合零个或多个“MainFrame Quit(意思为退出主框架)”,以及聚合零个或多个“Action(意思为方法)”。其中,“MainFrame Quit”属于活动类,为未声明Action之外的RPC日志信息,会在客户端退出时统一退出;“Action”也属于活动类,为客户端的性能事件,包括用户界面(UI,UserInterface)初始化和用户界面上任意按钮或菜单绑定的Swing Action(改变方法),“Action”嵌套时,通过顺序和stack(栈)表示父子关系,比如,如图3a中的“Action(stacklevel=1)”则表示有一层嵌套,其中,“Action(stacklevel=1)”为子Action,“Action”为父Action。之所以有嵌套的Action,是因为某些用户操作会跨Action,但不会跨最外层的Action,所以,一些关键的统计信息可以在子Action输出。
“Action”聚合零个或多个“ActionEntry(意思为方法事件)”,“ActionEntry”也属于活动类,不同类型的“ActionEntry”可以通过名称(即name)的命名规则来区分,比如,如果是普通的RPC调用(即RpcInvoke)所产生的“ActionEntry”话,则没有前缀,如果是缓存中的RPC调用(即Cached RpcInvoke)所产生的“ActionEntry”的话,则为“+++”,如果是子方法(即SubAction)所产生的“ActionEntry”的话,则为“---”,如果是用户输入(即User Input)的“ActionEntry”的话,则为“###”,等等。
“MainFrame Quit”聚合零个或多个“Thread Summary(意思为总线程)”,“Thread Summary”属于活动类,查看“Thread(意思为线程)”为“AWT-EventQueue-1”的“Summary(意思为汇总)”,可以了解用户操作的全过程。
“Thread Summary”也聚合零个或多个“ActionEntry”。
其中,“ActionEntry”主要可以由“RpcInvoke(即普通得Rpc调用)”、“CachedRpcInvoke(即缓存Rpc调用)”、“User Input(即用户输入)”或“SubAction(即子方法)”产生。其中,“RpcInvoke”可以联查服务端的性能事件RpcInvoke,“User Input”用于计算最外层“Action”中“waitxxx”的参数值,比如,计算“waitTime”、“waitRpcBytes”或“waitRpcNumber”等的参数值;“SubAction”用于说明子Action在父Action中的时序。
以下将对图3a中各个活动类的属性和类型进行简略说明,参见表一。
表一:
Figure BDA0000135624680000081
Figure BDA0000135624680000091
Figure BDA0000135624680000101
需说明的是,以上各个活动类的属性,以及属性的类型具体的名称和类型可参见现有技术,在此不再赘述。
(2)第一服务端RPC日志信息:RpcSqlD.V60SP1.log;
如图3b所示,该图为第一服务端RPC日志信息的UML模型图。
从图3b可以看出,“RpcSqlLog”聚合了零个或多个“Invoke(即调用)”,“Invoke”属于活动类,是服务端最重要的一类性能事件,用于处理一次远程调用,其中并不包含本地调用,所以也没有嵌套关系。其名称(name)可以由接口名和方法名构成,特殊的还可以加上参数值,例如虚模式查询。
“Invoke”聚合零个或多个“KSqlEntry(即K Sql事件)”,“KSqlEntry”属于活动类,主要由“KSql LogItem(即K Sql项目)”和“KDResultSet.next(即KD返回值)”,该“KSql LogItem”和“KDResultSet.next”均属于活动类,其中,“KSql LogItem”为一次Sql执行,为了减少输出数据量,查询Sql省略了selector(即选择)部分;而关于“KDResultSet.next”,需说明的是,JDBC遍历结果时,并不是一次把所有行取回服务端,而是建立了一个内存缓存区,逐页获取,其中,oracle(甲骨文,指一种数据库管理系统)一页具有10行,db2(指一种数据库管理系统)一页具有64行,next时如果跨页就需要进行appserver(运行Java企业组件的平台)和db server(即数据库服务器)间的网络通讯,以获取下一页的若干行结果。
以下将对图3b中各个活动类的属性和类型进行简略说明,参见表二。
表二:
Figure BDA0000135624680000111
Figure BDA0000135624680000121
需说明的是,以上各个活动类的属性,以及属性的类型具体的名称和类型可参见现有技术,在此不再赘述。
(3)第二服务端RPC日志信息:SqlPlanD.V60SP1.log;
如图3c所示,该图为第二服务端RPC日志信息的UML模型图。
从图3c可以看出,“RpcPlanLog”聚合了零个或多个“Sql”,“Sql”属于活动类,是数据库服务器的性能事件。应用服务器重启后,对于同一个数据中心的同一个sql,只异步地生成一次执行计划。
“Sql”聚合了零个或多个“SqlPlanEntry(sql语句执行计划事件)”,“SqlPlanEntry”属于活动类,主要可以由“OracleEntry(即Oracle数据库所生成的事件)”、“DB2Entry(即DB2数据库所生成的事件)”或“SqlServerEntry(即Sql服务器所生成的事件)”生成。其中,“OracleEntry”、“DB2Entry”和“SqlServerEntry”均属于活动类。
以下将对图3c中各个活动类的属性和类型进行简略说明,参见表三。
表三:
Figure BDA0000135624680000122
Figure BDA0000135624680000131
需说明的是,以上各个活动类的属性,以及属性的类型具体的名称和类型可参见现有技术,在此不再赘述。
206、当用户需要分析单点业务A的性能时,可以在发送分析单点业务A的性能的请求给单点业务性能分析装置。
207、单点业务性能分析装置接收到用户发送的请求后,根据单点业务A确定单点业务A对应的事件。
208、单点业务性能分析装置根据确定的事件获取对应的客户端RPC日志信息:“rpcD.V60SP1.log”;
其中,该“rpcD.V60SP1.log”包括事件名、程序类名与方法名、访问标识、RPC调用的时间、RPC调用次数、RPC调用的时长和RPC总得调用时间等信息,具体可参见步骤205。
209、单点业务性能分析装置通过RPC协议,根据客户端RPC日志信息中的访问标识使客户端与服务端之间的线程衔接,在“RpcSqlD.V60SP1.log”中联查到对应的程序类名与方法名、SQL语句、SQL的执行时间、SQL标识和数据库方面总得耗用时间;
其中,“RpcSqlD.V60SP1.log”的构造和内容具体可参见步骤205。
210、单点业务性能分析装置通过RPC协议,根据“RpcSqlD.V60SP1.log”中的SQL标识与“SqlPlanD.V60SP1.log”中的SQL语句的相关分析数据衔接,从而在“SqlPlanD.V60SP1.log”中联查到对应的SQL语句和执行计划信息。
其中,“SqlPlanD.V60SP1.log”的构造和内容具体可参见步骤205。
211、单点业务性能分析装置根据步骤208、步骤209和步骤210中获取到的各个RPC日志信息分析该单点业务A的性能,具体可以如下:
(1)根据客户端RPC日志信息中的事件名、程序类名与方法名、访问标识、RPC调用的时间、RPC调用次数、RPC调用的时长和RPC总得调用时间分析该单点业务在客户端上的程序性能;
(2)根据第一服务端RPC日志信息中的程序类名与方法名、SQL语句、SQL的执行时间、SQL标识和数据库方面总得耗用时间分析该单点业务在服务端上的程序性能;
(3)根据第二服务端RPC日志信息中的SQL语句和执行计划信息得到执行计划的时间,根据执行计划的时间分析所述单点业务在服务端上的SQL性能。
需说明的是,在本发明实施例中,为了描述方便,将客户端RPC日志信息命名为“rpcD.V60SP1.log”,将第一服务端RPC日志信息命名为“RpcSqlD.V60SP1.log”,将第二服务端RPC日志信息命名为“SqlPlanD.V60SP1.log”;应当理解的是,也可以是其他的命名方式,在此不再赘述。
由上可知,本实施例通过确定需要分析的单点业务所对应的事件,来获取对应的客户端RPC日志信息,然后再通过客户端RPC日志信息获取到对应的服务端RPC日志信息,最后再结合客户端RPC日志信息和服务端RPC日志信息对单点业务的性能进行分析,从而实现了对客户端和服务端进行联查的目的,可以准确地对单点业务的性能问题进行定位,有利于改善单点业务的性能。
进一步的,由于客户端RPC日志信息中包括了客户端程序执行的程序耗用的时间,以及客户端RPC调用的时间与次数等信息,而服务端日志信息中也包括了程序类名与方法名、SQL语句、SQL的执行时间、SQL标识、数据库方面总得耗用时间、SQL语句和执行计划信息等信息,所以相对于现有技术中只能收集到SQL的语句、SQL执行计划和执行时间等关键信息而言,可以更详尽和清楚地收集到单点业务的各种执行信息,有利于更准确地对单点业务的性能进行分析。
实施例三、
为了更好地实施以上方法,本发明实施例还提供一种单点业务性能的分析装置,如图4所示,该单点业务性能的分析装置包括确定单元301、第一获取单元302、第二获取单元303和分析单元304;
确定单元301,用于确定需要分析的单点业务所对应的事件;
第一获取单元302,用于根据确定单元301确定的事件获取对应的客户端远程过程调用协议RPC日志信息;
第二获取单元303,用于根据第一获取单元302获取到的客户端RPC日志信息获取对应的服务端RPC日志信息;
分析单元304,用于根据第一获取单元302获取到的客户端RPC日志信息和第二获取单元303获取到的服务端RPC日志信息分析所述单点业务的性能。
其中,客户端RPC日志信息可以包括事件名、程序类名与方法名、访问标识、RPC调用的时间、RPC调用次数、RPC调用的时长和RPC总得调用时间等信息;
而服务端RPC日志信息则可以包括两个RPC日志信息,一个是针对SQL脚本与SQL所在的程序类名与方法名的SQL日志信息,在本发明实施例中称为第一服务端RPC日志信息;另一个是针对SQL执行计划(Plan)的计划日志信息,在本发明实施例中称为第二服务端RPC日志信息。其中,第一服务端RPC日志信息具体可以包括程序类名与方法名、结构化查询语言(SQL,Structured QueryLanguage)语句、SQL的执行时间、SQL标识和数据库方面总得耗用时间等信息;而第二服务端RPC日志信息则具体可以包括SQL语句和执行计划信息等信息。
其中,如图5所示,第二获取单元303具体可以包括第一获取子单元3031和第二获取子单元3032;
第一获取子单元3031,用于根据客户端RPC日志信息中的访问标识在第一服务端RPC日志信息中联查到对应的程序类名与方法名、SQL语句、SQL的执行时间、SQL标识和数据库方面总得耗用时间;
第二获取子单元3032,用于根据第一服务端RPC日志信息中的SQL标识在第二服务端RPC日志信息中联查到对应的SQL语句和执行计划信息。
如图5所示,分析单元304具体可以包括第一分析子单元3041、第二分析子单元3042和第三分析子单元3043;
第一分析子单元3041,用于根据所述客户端RPC日志信息中的事件名、程序类名与方法名、访问标识、RPC调用的时间、RPC调用次数、RPC调用的时长和RPC总得调用时间分析所述单点业务在客户端上的程序性能;
第二分析子单元3042,用于根据第一服务端RPC日志信息中的程序类名与方法名、SQL语句、SQL的执行时间、SQL标识和数据库方面总得耗用时间分析所述单点业务在服务端上的程序性能;
第三分析子单元3043,用于根据第二服务端RPC日志信息中的SQL语句和执行计划信息得到执行计划的时间,根据执行计划的时间分析所述单点业务在服务端上的SQL性能。
需说明的是,其中,客户端RPC日志信息和服务端RPC日志信息为根据单点业务的执行情况而预先生成的日志信息,也就是说,在确定需要分析的单点业务所对应的事件之前,还可以生成客户端RPC日志信息和服务端RPC日志信息,即除了上述单元之外,该单点业务性能的分析装置还可以包括调用单元和日志生成单元,参见图5;
调用单元,用于调用客户端的RPC程序,以及调用服务端的RPC程序;
日志生成单元,用于在客户端和服务端执行单点业务时,利用所述客户端的RPC程序对单点业务的执行情况进行监控,并在客户端生成客户端RPC日志信息;以及,利用所述服务端的RPC程序对单点业务的执行情况进行监控,并在服务端生成服务端RPC日志信息。
以上各个单元的具体实施可参见前面实施例,在此不再赘述。
具体实施时,上述各个单元可以作为独立的实体来实现,也可以进行任意组合,作为同一或若干个实体来实现,即本发明实施例所给出的单点业务性能的分析装置的单元划分方式,仅仅为其中的一种划分方式,应当理解的是,还可以由其他的划分方式,在此不再赘述。
由上可知,本实施例的单点业务性能的分析装置的确定单元301可以确定需要分析的单点业务所对应的事件,然后由第一获取单元302来获取对应的客户端RPC日志信息,然后再由第二获取单元303通过客户端RPC日志信息获取到对应的服务端RPC日志信息,最后再由分析单元304结合客户端RPC日志信息和服务端RPC日志信息对单点业务的性能进行分析,从而实现了对客户端和服务端进行联查的目的,可以准确地对单点业务的性能问题进行定位,有利于改善单点业务的性能。
进一步的,由于客户端RPC日志信息中包括了客户端程序执行的程序耗用的时间,以及客户端RPC调用的时间与次数等信息,而服务端日志信息中也包括了程序类名与方法名、SQL语句、SQL的执行时间、SQL标识、数据库方面总得耗用时间、SQL语句和执行计划信息等信息,所以相对于现有技术中只能收集到SQL的语句、SQL执行计划和执行时间等关键信息而言,可以更详尽和清楚地收集到单点业务的各种执行信息,有利于更准确地对单点业务的性能进行分析。
实施例四、
相应的,本发明实施例还提供一种企业资源计划系统,即ERP系统,包括本发明实施例提供的任一种单点业务性能的分析装置,其中,单点业务性能的分析装置的具体说明可参见实施例三,在此不再赘述。
此外,该ERP系统还可以客户端和服务端;
客户端,用于与服务端进行交互以执行单点业务。
服务端,用于与客户端进行交互以执行单点业务。
以下将举例对该ERP系统的具体执行作简略说明。
在本例子中,将以客户端RPC日志信息为“rpcD.V60SP1.log”,第一服务端RPC日志信息为RpcSqlD.V60SP1.log,以及第二服务端RPC日志信息为SqlPlanD.V60SP1.log为例进行说明i。如下:
步骤1、当用户打开客户端的RPC开关时,单点业务性能的分析装置的调用单元调用客户端的RPC程序;
步骤2、当用户打开服务端的RPC开关时,单点业务性能的分析装置的调用单元调用服务端的RPC程序;
其中,步骤1和步骤2的执行可以不分先后。
步骤3、在ERP系统执行单点业务A时,单点业务性能的分析装置的日志生成单元利用调用的客户端的RPC程序对单点业务A的执行情况进行监控,并在客户端生成客户端RPC日志信息“rpcD.V60SP1.log”;以及,单点业务性能分析装置利用调用的服务端的RPC程序对单点业务A的执行情况进行监控,并在服务端生成服务端RPC日志信息:第一服务端RPC日志信息“RpcSqlD.V60SP1.log”和第二服务端RPC日志信息“SqlPlanD.V60SP1.log”。
其中,客户端RPC日志信息,以及两个服务端RPC日志信息的结构可参见实施例二,在此不再赘述。
步骤4、当用户需要分析单点业务A的性能时,可以在发送分析单点业务A的性能的请求给单点业务性能的分析装置。
步骤5、单点业务性能的分析装置的确定单元301接收到用户发送的请求后,根据单点业务A确定单点业务A对应的事件。
步骤6、单点业务性能的分析装置的第一获取单元302根据确定的事件获取对应的客户端RPC日志信息:“rpcD.V60SP1.log”;
其中,该“rpcD.V60SP1.log”包括事件名、程序类名与方法名、访问标识、RPC调用的时间、RPC调用次数、RPC调用的时长和RPC总得调用时间等信息,具体可参见实施例二中的步骤205。
步骤7、单点业务性能分析装置的第一获取子单元3031通过RPC协议,根据客户端RPC日志信息中的访问标识使客户端与服务端之间的线程衔接,在“RpcSqlD.V60SP1.log”中联查到对应的程序类名与方法名、SQL语句、SQL的执行时间、SQL标识和数据库方面总得耗用时间;
其中,“RpcSqlD.V60SP1.log”的构造和内容具体可参见实施二中的步骤205。
步骤8、单点业务性能分析装置的第二获取子单元3032通过RPC协议,根据“RpcSqlD.V60SP1.log”中的SQL标识与“SqlPlanD.V60SP1.log”中的SQL语句的相关分析数据衔接,从而在“SqlPlanD.V60SP1.log”中联查到对应的SQL语句和执行计划信息。
其中,“SqlPlanD.V60SP1.log”的构造和内容具体可参见实施二中的步骤205。
步骤9、单点业务性能分析装置的分析单元304根据获取到的各个RPC日志信息分析该单点业务A的性能,具体可以如下:
(1)第一分析子单元3041根据客户端RPC日志信息中的事件名、程序类名与方法名、访问标识、RPC调用的时间、RPC调用次数、RPC调用的时长和RPC总得调用时间分析该单点业务在客户端上的程序性能;
(2)第二分析子单元3042根据第一服务端RPC日志信息中的程序类名与方法名、SQL语句、SQL的执行时间、SQL标识和数据库方面总得耗用时间分析该单点业务在服务端上的程序性能;
(3)第三分析子单元3043根据第二服务端RPC日志信息中的SQL语句和执行计划信息得到执行计划的时间,根据执行计划的时间分析所述单点业务在服务端上的SQL性能。
该ERP系统具体可以是企业应用套件(EAS,Enterprise ApplicationSuites)系统。
由上可知,本实施例的ERP系统中的单点业务性能分析装置通过确定需要分析的单点业务所对应的事件,来获取对应的客户端RPC日志信息,然后再通过客户端RPC日志信息获取到对应的服务端RPC日志信息,最后再结合客户端RPC日志信息和服务端RPC日志信息对单点业务的性能进行分析,从而实现了对客户端和服务端进行联查的目的,可以准确地对单点业务的性能问题进行定位,有利于改善单点业务的性能。
进一步的,由于客户端RPC日志信息中包括了客户端程序执行的程序耗用的时间,以及客户端RPC调用的时间与次数等信息,而服务端日志信息中也包括了程序类名与方法名、SQL语句、SQL的执行时间、SQL标识、数据库方面总得耗用时间、SQL语句和执行计划信息等信息,所以相对于现有技术中只能收集到SQL的语句、SQL执行计划和执行时间等关键信息而言,可以更详尽和清楚地收集到单点业务的各种执行信息,有利于更准确地对单点业务的性能进行分析。
本领域普通技术人员可以理解上述实施例的各种方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成,该程序可以存储于一计算机可读存储介质中,存储介质可以包括:只读存储器(ROM,Read Only Memory)、随机存取记忆体(RAM,Random Access Memory)、磁盘或光盘等。
以上对本发明实施例所提供的一种单点业务性能的分析方法、装置和系统进行了详细介绍,本文中应用了具体个例对本发明的原理及实施方式进行了阐述,以上实施例的说明只是用于帮助理解本发明的方法及其核心思想;同时,对于本领域的技术人员,依据本发明的思想,在具体实施方式及应用范围上均会有改变之处,综上所述,本说明书内容不应理解为对本发明的限制。

Claims (10)

1.一种单点业务性能的分析方法,其特征在于,包括:
确定需要分析的单点业务所对应的事件;
根据所述事件获取对应的客户端远程过程调用协议RPC日志信息;
根据客户端RPC日志信息获取对应的服务端RPC日志信息;
根据所述客户端RPC日志信息和服务端RPC日志信息分析所述单点业务的性能。
2.根据权利要求1所述的方法,其特征在于,
所述客户端RPC日志信息包括事件名、程序类名与方法名、访问标识、RPC调用的时间、RPC调用次数、RPC调用的时长和RPC总得调用时间;
所述服务端RPC日志信息包括第一服务端RPC日志信息和第二服务端RPC日志信息;
所述第一服务端RPC日志信息包括程序类名与方法名、结构化查询语言SQL语句、SQL的执行时间、SQL标识和数据库方面总得耗用时间;
所述第二服务端RPC日志信息包括SQL语句和执行计划信息。
3.根据权利要求2所述的方法,其特征在于,所述根据客户端RPC日志信息获取对应的服务端RPC日志信息,包括:
根据客户端RPC日志信息中的访问标识在第一服务端RPC日志信息中联查到对应的程序类名与方法名、SQL语句、SQL的执行时间、SQL标识和数据库方面总得耗用时间;
根据第一服务端RPC日志信息中的SQL标识在第二服务端RPC日志信息中联查到对应的SQL语句和执行计划信息。
4.根据权利要求2或3所述的方法,其特征在于,所述根据所述客户端RPC日志信息和服务端RPC日志信息分析所述单点业务的性能,包括:
根据所述客户端RPC日志信息中的事件名、程序类名与方法名、访问标识、RPC调用的时间、RPC调用次数、RPC调用的时长和RPC总得调用时间分析所述单点业务在客户端上的程序性能;
根据第一服务端RPC日志信息中的程序类名与方法名、SQL语句、SQL的执行时间、SQL标识和数据库方面总得耗用时间分析所述单点业务在服务端上的程序性能;
根据第二服务端RPC日志信息中的SQL语句和执行计划信息得到执行计划的时间,根据执行计划的时间分析所述单点业务在服务端上的SQL性能。
5.根据权利要求1至3中任一项所述的方法,其特征在于,所述确定需要分析的单点业务所对应的事件之前,还包括:
调用客户端的RPC程序,以及调用服务端的RPC程序;
在客户端和服务端执行单点业务时,利用所述客户端的RPC程序对单点业务的执行情况进行监控,并在客户端生成客户端RPC日志信息;以及,
利用所述服务端的RPC程序对单点业务的执行情况进行监控,并在服务端生成服务端RPC日志信息。
6.一种单点业务性能的分析装置,其特征在于,包括:
确定单元,用于确定需要分析的单点业务所对应的事件;
第一获取单元,用于根据所述事件获取对应的客户端远程过程调用协议RPC日志信息;
第二获取单元,用于根据客户端RPC日志信息获取对应的服务端RPC日志信息;
分析单元,用于根据所述客户端RPC日志信息和服务端RPC日志信息分析所述单点业务的性能。
7.根据权利要求6所述的单点业务性能的分析装置,其特征在于,
所述客户端RPC日志信息包括事件名、程序类名与方法名、访问标识、RPC调用的时间、RPC调用次数、RPC调用的时长和RPC总得调用时间;
所述服务端RPC日志信息包括第一服务端RPC日志信息和第二服务端RPC日志信息;
所述第一服务端RPC日志信息包括程序类名与方法名、结构化查询语言SQL语句、SQL的执行时间、SQL标识和数据库方面总得耗用时间;
所述第二服务端RPC日志信息包括SQL语句和执行计划信息。
8.根据权利要求7所述的单点业务性能的分析装置,其特征在于,所述第二获取单元包括:
第一获取子单元,用于根据客户端RPC日志信息中的访问标识在第一服务端RPC日志信息中联查到对应的程序类名与方法名、SQL语句、SQL的执行时间、SQL标识和数据库方面总得耗用时间;
第二获取子单元,用于根据第一服务端RPC日志信息中的SQL标识在第二服务端RPC日志信息中联查到对应的SQL语句和执行计划信息。
9.根据权利要求7或8所述的单点业务性能的分析装置,其特征在于,所述分析单元包括:
第一分析子单元,用于根据所述客户端RPC日志信息中的事件名、程序类名与方法名、访问标识、RPC调用的时间、RPC调用次数、RPC调用的时长和RPC总得调用时间分析所述单点业务在客户端上的程序性能;
第二分析子单元,用于根据第一服务端RPC日志信息中的程序类名与方法名、SQL语句、SQL的执行时间、SQL标识和数据库方面总得耗用时间分析所述单点业务在服务端上的程序性能;
第三分析子单元,用于根据第二服务端RPC日志信息中的SQL语句和执行计划信息得到执行计划的时间,根据执行计划的时间分析所述单点业务在服务端上的SQL性能。
10.一种企业资源计划系统,其特征在于,包括权利要求6至9所述的任一种单点业务性能的分析装置。
CN201210032775.8A 2012-02-14 2012-02-14 一种单点业务性能的分析方法、装置和系统 Active CN103248511B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201210032775.8A CN103248511B (zh) 2012-02-14 2012-02-14 一种单点业务性能的分析方法、装置和系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201210032775.8A CN103248511B (zh) 2012-02-14 2012-02-14 一种单点业务性能的分析方法、装置和系统

Publications (2)

Publication Number Publication Date
CN103248511A true CN103248511A (zh) 2013-08-14
CN103248511B CN103248511B (zh) 2016-08-03

Family

ID=48927745

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201210032775.8A Active CN103248511B (zh) 2012-02-14 2012-02-14 一种单点业务性能的分析方法、装置和系统

Country Status (1)

Country Link
CN (1) CN103248511B (zh)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103745317A (zh) * 2013-12-31 2014-04-23 金蝶软件(中国)有限公司 业务处理性能分析方法和装置
CN103986748A (zh) * 2014-04-22 2014-08-13 世纪禾光科技发展(北京)有限公司 实现服务化的方法和装置
CN104468248A (zh) * 2013-09-16 2015-03-25 腾讯科技(深圳)有限公司 业务性能的监控方法、反向代理服务器、统计分析服务器及系统
CN106789353A (zh) * 2017-02-06 2017-05-31 百度在线网络技术(北京)有限公司 在客户端与服务端之间定位问题的方法和系统
CN107741885A (zh) * 2017-10-09 2018-02-27 用友网络科技股份有限公司 基于cs架构的事务与业务关联方法、关联系统
CN114500306A (zh) * 2021-12-21 2022-05-13 上海赛可出行科技服务有限公司 一种基于维度的监控服务自动采样验证方法

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101115264A (zh) * 2006-07-24 2008-01-30 中兴通讯股份有限公司 通讯终端故障监控系统及其实现方法
CN101217441A (zh) * 2008-01-16 2008-07-09 中兴通讯股份有限公司 无线射频识别阅读器的远程管理方法

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101115264A (zh) * 2006-07-24 2008-01-30 中兴通讯股份有限公司 通讯终端故障监控系统及其实现方法
CN101217441A (zh) * 2008-01-16 2008-07-09 中兴通讯股份有限公司 无线射频识别阅读器的远程管理方法

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
陈钧: "EAS常见系统性能问题处理指引", 《EAS常见系统性能问题处理指引》, 20 October 2010 (2010-10-20), pages 4 - 14 *
高倩云: "EAS单点业务性能问题RPC日志收集指南", 《EAS单点业务性能问题RPC日志收集指南》, 31 January 2012 (2012-01-31), pages 4 - 7 *

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104468248A (zh) * 2013-09-16 2015-03-25 腾讯科技(深圳)有限公司 业务性能的监控方法、反向代理服务器、统计分析服务器及系统
CN104468248B (zh) * 2013-09-16 2021-04-20 腾讯科技(深圳)有限公司 业务性能的监控方法、反向代理服务器、统计分析服务器及系统
CN103745317A (zh) * 2013-12-31 2014-04-23 金蝶软件(中国)有限公司 业务处理性能分析方法和装置
CN103745317B (zh) * 2013-12-31 2018-12-21 金蝶软件(中国)有限公司 业务处理性能分析方法和装置
CN103986748A (zh) * 2014-04-22 2014-08-13 世纪禾光科技发展(北京)有限公司 实现服务化的方法和装置
CN103986748B (zh) * 2014-04-22 2019-01-25 数贸科技(北京)有限公司 实现服务化的方法和装置
CN106789353A (zh) * 2017-02-06 2017-05-31 百度在线网络技术(北京)有限公司 在客户端与服务端之间定位问题的方法和系统
CN107741885A (zh) * 2017-10-09 2018-02-27 用友网络科技股份有限公司 基于cs架构的事务与业务关联方法、关联系统
CN114500306A (zh) * 2021-12-21 2022-05-13 上海赛可出行科技服务有限公司 一种基于维度的监控服务自动采样验证方法
CN114500306B (zh) * 2021-12-21 2024-01-09 上海赛可出行科技服务有限公司 一种基于维度的监控服务自动采样验证方法

Also Published As

Publication number Publication date
CN103248511B (zh) 2016-08-03

Similar Documents

Publication Publication Date Title
Mayer et al. An approach to extract the architecture of microservice-based software systems
KR101203333B1 (ko) 데이터베이스 추적의 프로그램적인 검색 및 재생을 위한시스템
US20130144866A1 (en) Fault tolerance based query execution
US20100115100A1 (en) Federated configuration data management
Prakash et al. Geo-identification of web users through logs using ELK stack
CN103248511A (zh) 一种单点业务性能的分析方法、装置和系统
CN109189782A (zh) 一种区块链商品交易查询中的索引方法
CN109033280A (zh) 日志搜索方法、系统、计算机设备和存储介质
CN110990447B (zh) 一种数据探查方法、装置、设备及存储介质
US20100281053A1 (en) Method, apparatus, and computer-readable medium for distributing a query
CN109710667A (zh) 一种基于大数据平台的多源数据融合共享实现方法及系统
CN108268468A (zh) 一种大数据的分析方法及系统
US10951540B1 (en) Capture and execution of provider network tasks
Anderson et al. Architectural Implications of Social Media Analytics in Support of Crisis Informatics Research.
CN111026709A (zh) 基于集群访问的数据处理方法及装置
CN108733543A (zh) 一种日志分析的方法、装置、电子设备和可读存储介质
CN105550351B (zh) 旅客行程数据即席查询系统及方法
CN114637903A (zh) 一种针对定向目标数据拓展的舆情数据采集系统
Yadav et al. An efficient web mining algorithm for Web Log analysis: E-Web Miner
CN111177481A (zh) 用户标识映射方法及装置
CN104750860B (zh) 一种不确定数据的数据存储方法
CN113918149A (zh) 接口开发方法、装置、计算机设备和存储介质
CN109063040A (zh) 客户端程序数据采集方法及系统
Martinez-Mosquera et al. Development and evaluation of a big data framework for performance management in mobile networks
Dissanayake A study on real-time database technology and its applications

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
C14 Grant of patent or utility model
GR01 Patent grant