Gui性能日志生成系统、方法及gui性能分析方法

文档序号:6468326阅读:161来源:国知局
专利名称:Gui性能日志生成系统、方法及gui性能分析方法
技术领域
本发明涉及计算机技术领域,更具体地说,涉及一种GUI性能日志生成系 统、方法及GUI性能分析方法。
背景技术
无论是在开发环境或生产环境中,都需要一种分析应用程序运行性能的 工具,通过量化的性能指标,定位到具有性能缺陷的功能点,从而给出缺陷 的性质及初步的优化方向。
图形用户接口 (Graphical User Interface,简称"GUI")是屏幕产品的视 觉体验和互动才喿作部分,例如Windows以图形界面方式操作,用鼠标点击按钮 进行操作非常直观。
在Java领域,分析性能问题的主要工具是Java性能剖析器(Java Profiler), 其分析应用程序性能的方法如下(1 )在应用程序启动时,开启JVMTI ( Java Virtual Machine Tool Interface,是一套由Java虚拟枳4是供的、为Java虚拟才几相 关的工具提供的本地编程接口集合)服务;(2 )指定一个分析范围(例如可 以是某个命名空间的所有类),通过Java虚拟机的JVMTI接口,附加到正在运 行的应用程序上;(3 )记录应用程序执行过程中的Java指令执行或对象创建 等明细信息;(4 )性能剖析器根据记录的明细信息生成性能图表。
采用Java性能剖析器分析应用程序性能,由于必须记录分析范围内的每个 Java指令,会使所有Java指令的执行时间增加,累计的效果就是大大P争低了应 用程序的整体运行速度。而随着分析范围的增大,可能会几倍甚至几十倍地 增加功能的响应时间。Java性能剖析器进行性能分析的功能点很多,并且需要 做性能分析的功能点一般响应时间较长,附加上Java性能剖析器后,其响应时 间变为了原来的几倍甚至几十倍,使得性能分析者必须长时间地等待功能点 运行结束。因此现有技术对应用程序进行性能分析的分析效率低下。
并且,Java性能剖析器的配置和使用非常复杂,很难在生产环境中指导实 施人员或客户使用,而许多性能缺陷,只有在特定的生产环境中出现,无法 在开发环境中重现。因此必须要求在缺陷发生的第一现场就能搜集到相关的 性能数据,而现有的Java性能剖析器不能达到此要求。
另外,由于Java性能剖析器记录分析范围内的所有Java指令,并使得每个 Java指令增加了 一个延时。而在客户端最耗时的往往是对服务端的远程调用。 所谓"远程调用",在Java领域,是一种机制,可以在不同的Java虚拟机(JavaVirtual Machine,简称"JVM")之间实现对象与对象的通信。JVM可以位于 相同或不同的计算机上,在多个JVM中, 一个JVM中的对象可以调用其它JVM 中的对象的方法,而发起调用的JVM称为客户端,接收调用的称为服务端。
JVM做远程调用属于一种输入/输出,其执行的Java指令少,操作系统指 令多。因此,在最终的性能图表中,远程调用占用的时间比例往往会比真实 情况小,而大量执行Java指令的循环逻辑占用的时间比例会比真实情况大,从 而性能优化走向错误的方向。因此Java性能剖析器还存在失真问题。

发明内容
本发明的目的之一在于提供一种GUI性能日志生成系统、方法及GUI性能 分析方法,旨在能提高应用程序性能分析效率、且能有效反映性能真实情况。
为了实现发明目的,所述GUI性能日志生成系统包括
性能事务记录单元,记录在执行性能事务的第一时间和第二时间所述性 能事务对客户端的资源消耗差异,以及性能事务对服务端的远程调用参数;
性能日志生成单元,与性能事务记录单元进行数据交互,根据性能事务 记录单元记录的客户端的资源消耗差异和远程调用参数生成性能曰志。
该第一时间是性能事务开始,第二时间是性能事务结束。
该性能事务包括Action执行事件和UI初始化事件。
为了更好的实现发明目的,所述GUI性能日志生成方法,包括以下步骤 A.记录在执行性能事务的第 一 时间和第二时间所述性能事务对客户端的
资源消耗差异,以及性能事务对服务端的远程调用参数;
D.根据记录的客户端的资源消耗差异和远程调用参数生成性能日志。 该第一时间是性能事务开始,第二时间是性能事务结束,步骤A中记录在
执行性能事务的第 一 时间和第二时间所述性能事务对客户端的资源消耗的差
异进一步包括
Al .在性能事务开始时获取客户端的资源消耗参数; A2.在性能事务结束时获取客户端的资源消耗参数; A3.记录开始和结束时性能事务在客户端的资源消耗差异。 该性能事务包括Action执行事件和UI初始化事件。
为了更好的实现发明目的,所述GUI性能分析方法包括以下步骤 A,.根据性能事务执行的不同时间对客户端的资源消耗差异和对服务端 的远程调用参数生成性能日志;
B ,.根据远程调用参数判断性能事务对服务端的远程调用状况;C,.根据客户端的资源消耗差异判断性能事务在客户端的资源消耗状况。 该远程调用参数包括远程调用时间、远程调用次数和网络传输时间,步
骤B'包括
况; ' '° '…' '一 、
B3,.才艮据网络传输时间判断网络状况。
该客户端的资源消耗差异包括中央处理器处理时间、GC时间和/或GC 次数,步骤C,包括
Cl,.根据中央处理器处理时间判断性能事务对中央处理器的资源消耗状
况;
C2,.根据GC时间和/或GC次数判断性能事务对内存的资源消耗状况。 该分析方法还包括检测性能事务从本地文件系统读取文件的状况,根 据-险测结果分析性能事务响应状况。
由上可知,本发明记录了性能事务执行时对客户端的资源消耗以及对服 务端的远程调用参数,由于该性能事务能代表不同的功能点,因此无需对每 个Java指令进行分析,提高了应用程序性能分析效率;另外,记录参数时不会 造成指令的延时,所输出的性能参数能真实反映用户在一个操作后的等待时 间,因此能有效反映性能的真实情况。


图1是本发明其中 一个实施例中GUI性能日志生成系统的结构示意图; 图2是本发明其中一个实施例中GUI性能日志生成方法的流程图; 图3是本发明其中一个实施例中基于Action执行事件的性能日志生成方法 的流程图4是本发明其中一个实施例中基于Action执行事件的性能日志生成方法 的时序图5是本发明其中一个实施例中基于UI初始化事件的性能日志生成方法 的流程图6是本发明其中一个实施例中基于UI初始化事件的性能日志生成方法 的时序图7是本发明其中 一个实施例中Action执行事件与UI初始化事件具有嵌套 关系时GUI性能日志生成方法的流程6图8是本发明其中 一个实施例中Action执行事件与UI初始化事件具有嵌套
关系时GUI性能日志生成方法的时序图9是本发明其中一个实施例中GUI性能日志的逻辑结构图10是本发明其中 一个实施例中GUI性能日志的UML类图11是本发明其中 一个实施例中GUI性能分析方法的流程图12是本发明其中 一 个实施例中根据远程调用参数分析性能事务对服务
端的远程调用状况的方法流程图13是本发明其中 一个实施例中根据客户端的资源消耗差异判断性能事
务在客户端的资源消耗状况的方法流程图。
为了使本发明的目的、技术方案及优点更加清楚明白,以下结合附图及 实施例,对本发明进行进一步详细说明。
具体实施例方式
在本发明中,通过记录性能事务在客户端的资源消耗差异和对服务端的 远程调用参数,最后根据记录的资源消耗差异和远程调用参数生成性能日志, 以及根据性能日志的内容对GUI性能进行分析。这样,能提高应用程序的性能 分析效率且能有效反应性能真实情况。
图1示出了本发明的 一 个实施例中GUI性能日志生成系统的结构,该系统 包括性能事务记录单元100和性能日志生成单元200。应当说明的是,本发明 所有图示中各设备之间的连接关系是为了清楚阐释其信息交互及控制过程的 需要,因此应当视为逻辑上的连接关系,而不应仅限于物理连接。其中
性能事务记录单元IOO,用于记录在执行性能事务的第一时间和第二时间 该性能事务对客户端的资源消耗差异,以及性能事务对服务端的远程调用参 数。
性能日志生成单元200,与性能事务记录单元100进行数据交互,用于根 据性能事务记录单元100记录的客户端的资源消耗差异和远程调用参数生成 性能日志。
在一个实施例中,第一时间是性能事务开始,第二时间是性能事务结束, 性能事务记录单元100进一步在性能事务开始和结束时获取客户端的资源消 耗,并记录性能事务在开始和结束时客户端的资源消耗的差异。
在一个实施例中,性能事务包括Action执行事件和UI初始化事件。
图2示出了本发明的 一个实施例中GUI性能日志生成方法的流程,该方法基于图l所示的系统结构,包括以下步骤
在步骤S201中,记录在执行性能事务的第 一 时间和第二时间所述性能事 务对客户端的资源消耗差异,以及性能事务对服务端远程调用参数。
在步骤S202中,根据记录的客户端的资源消耗差异和远程调用参数生成 性能日志。
在一个实施例中,第一时间是性能事务开始,第二时间是性能事务结束。 记录在执行性能事务的第 一时间和第二时间所述性能事务对客户端的资源消 耗的差异具体包括(l)在性能事务开始时获取客户端的资源消耗参数;(2) 在性能事务结束时获取客户端的资源消耗参数;(3 )记录开始和结束时性能 事务对客户端的资源消耗差异。
在一个实施例中,性能事务包括Action执行事件和UI初始化事件。关于基 于Action执行事件和UI初始化事件的GUI性能日志生成方法将分别在下述内 容进行详细描述。
在一个具体的实施方案中,GUI性能日志生成方法的具体过程包括(1 ) 声明性能事务开始;(2)记录性能事务开始的时间点,并在性能事务开始的 时间点获取客户端的资源消耗参数;(3 )在性能事务执行过程中记录性能事 务对服务端的远程调用参数;(4)声明性能事务结束;(5)记录性能事务 结束的时间点,并在性能事务结束的时间点获取客户端的资源消耗参数,以 及记录性能事务开始和结束时客户端的资源消耗差异;(6)根据记录的客户 端的资源消耗差异和远程调用参数生成性能日志。
在一个实施例中,所记录的性能事务对服务端的远程调用参数具体包括 远程调用号、远程调用接口名、远程调用方法名、远程调用持续时间、上行 数据量、下行数据量和远程调用结束时间。所记录的客户端的资源消耗差异 包括中央处理器处理时间、GC时间和GC次数。
应当说明的是,性能事件是性能事务(Action)的组成部分, 一个性能事 务包含了多个性能事件,UI初始化事件即用户界面(UserInterface,简称"UI") 初始化事件。定义Action执行事件和UI初始化事件是为量化性能事务的时间组 成及与服务端的交互。
另夕卜,中央处理器(Central Processing Unit,筒称"CPU")处理时间指 CPU处理当前性能事务所花费的时间。固定型号的CPU,单位时间能够输出的 CPU处理时间是有限的,任何一个性能事务都不应过度地消耗CPU处理时间。
而垃圾回收(Garbage Collection,简称"GC")时间是一个性能事务在执 行过程中,Java虚拟机做内存回收的总时间。GC时间和GC次数是Java虚拟机 的内存回收机制。GC次数是指一个性能事务在执行过程中,Java虚拟机做内 存回收的总次数。GC时间和GC次数较大,说明当前性能事务对内存的使用有不合理之处。例如大量创建对象、申请大块连续内存等等。
图3示出了本发明的一个实施例中基于Action执行事件的性能日志生成方 法的流程。该实施例描述了处理Action执行事件时GUI性能日志的生成方法, 在一个实施例中,其具体时序过程可参考附图4。具体过程如下
在步骤S301中,ItemAction类声明Action执行事件开始。ItemAtion类是所 有Action类的动态代理类,用于在actionPerformed执行前后,声明性能事务的 开始和结束。在一个实施例中,Action执行事件可对应GUI中的一个按4丑或菜 单执行的业务逻辑。
在步骤S302中,执行actionPerformed。
在步骤S303中,记录Action执行事件开始的时间点,并在Action执行事件 开始的时间点获取客户端的资源消耗参数。在一个实施例中,如图4所示,bizl 和biz2分别表示纯客户端逻辑,其消耗一定的客户端资源,包括CPU处理时间、 GC时间和GC次数,在bizl和biz2执行开始的时间点获取CPU处理时间、GC时 间和GC次数。
在步骤S304中,在Action执行事件执行的过程中记录所述Action执行事件 对服务端的远程调用参数。在一个实施例中,所记录的远程调用参数包括远 程调用号、远程调用方法名、远程调用持续时间、上行数据量、下行数据量 和远程调用结束时间。在一个实施例中,如图4所示,rpcl和rpc2分别表示对 服务端的两个远程调用。
在一个具体的实施例中,在Action执行事件执行过程中记录的对服务端的 远程调用参数的内容如下
com.kingdee eas .base license .ILicenseController.requestLicense(com.kingdee .eas. base.license丄icenseUserlnfo, java.lang.String) int
time: 0 ms request: 419 B response: 85 B invoke—id: -972189611 end—time: 10:49:44
其巾,
com.kingdee.eas.base.license.ILicenseController.requestLicense(com.kingdee eas.base.license.LicenseUserlnfo, java.lang.String)是i亥远禾呈i周用方法名,time是 该远程调用持续时间,request是下行数据量,response是上行数据量,invoke id 是远程调用名,end time是远程调用结束时间。
在步骤S305中,记录Action执行事件结束的时间点,并在所述Action执行 事件结束的时间点获取客户端的资源消耗参数,以及记录客户端的资源消耗 参数的差值。在一个实施例中,如图4所示,bizl和biz2分别表示纯客户端逻 辑,其消耗一定的客户端资源,包括CPU处理时间、GC时间和GC次数,在bizl和biz2执行结束的时间点获取CPU处理时间、GC时间和GC次数,并记录与bizl 和biz2执行开始的时间点获取到的CPU处理时间、GC时间和GC次数的差值, 所述差值反映了 bizl和biz2执行时对客户端的资源消耗状况。
在一个具体的实施例中,所记录的客户端的资源消耗差值如下
cpu time :312 gc count: 3 gc time: 3 6
其中,cputime是CPU处理时间,gc count是GC次数,gctime是GC时间。 在步骤S306中,在Action执行事件对服务端的远程调用结束时通知
PerformanceLog类。在一个实施例中,通过执行invokePerformed通知
PerformanceLog类远程调用结束。
在步骤S307中,ItemAction类声明Action执行事件结束,PerfomanceLog
类将所述记录的内容输出到性能日志文件中。所记录的内容包括Action执行事
件开始和结束时Action执行事件对客户端的资源消耗差异和Action执行事件
执行过程中其对服务端的远程调用参数。
图5示出了本发明的一个实施例中基于UI初始化事件的性能日志生成方 法流程。该实施例描述了处理UI初始化事件时GUI性能日志的生成方法,在一 个实施例中,其具体时序过程可参考附图6。具体过程如下
在步骤S501中,创建UI对象实例。在一个实施例中,如图6所示,通过执 行initUIObject和BizUI创建UI对象实例。
在步骤S502中,UIFactory类声明UI初始化事件开始。在一个实施例中, 如图6所示,将UIFactory类作为所有UI的工厂类,在UI初始化事件执行前声明 性能事务开始,在UI初始化事件执行后声明性能事务结束。应当说明的是, 工厂方法模式是一种类的创建模式,用于定义一个创建产品对象的工厂接口 , 将实际创建工作推迟到子类中。在一个实施例中,UI初始化事件可以是执行 一些逻辑后弹出的编辑界面。
在步骤S503中,记录UI初始化事件开始的时间点,并在UI初始化事件开 始的时间点获取客户端的资源消耗参数。在一个实施例中,如图6所示,bizl 和biz2分别表示纯客户端逻辑,其消耗一定的客户端资源,包括CPU处理时间、 GC时间和GC次数,在bizl和biz2执行开始的时间点获取CPU处理时间、GC时 间和GC次数。
在步骤S504中,在UI初始化事件执行的过程中记录所述UI初始化事件对 服务端的远程调用参数。在一个实施例中,所记录的远程调用参数包括远程 调用号、远程调用方法名、远程调用持续时间、上行数据量、下行数据量和 远程调用结束时间。在一个实施例中,如图6所示,rpcl和rpc2分别表示对服 务端的两个远程调用。在一个具体的实施例中,在UI初始化事件执行过程中记录的对服务端的 远程调用参数如下
com.kingdee.eas.basedata.assistant.client.CurrencyEditUI.initUIObjectO time: 0 ms request: OB response: 0 B invoke—id: -1 end—time: 19:38:16
其中, — —
com.kingdee.eas.basedata.assistant.client.CurrencyEditUI.initUIObject是"i亥远牙呈 调用方法名,time是该远程调用持续时间,request是下行数据量,response 是上行数据量,invoke id是远程调用名,end time是远程调用结束时间。
在步骤S505中,记录UI初始化事件结束的时间点,并在所述UI初始化事 件结束的时间点获取客户端的资源消耗参数,以及记录客户端的资源消耗参 数的差值。在一个实施例中,如图6所示,bizl和biz2分别表示纯客户端逻辑, 其消耗一定的客户端资源,包括CPU处理时间、GC时间和GC次数,在bizl和 biz2执行结束的时间点获取CPU处理时间、GC时间和GC次数,并记录与bizl 和biz2执行开始的时间点获取到的CPU处理时间、GC时间和GC次数的差值, 所述差值反应了bizl和biz2执行时对客户端的资源消耗状况。
在一个具体的实施例中,所记录的客户端的资源消耗差异如下
cpu time:312 gc count: 3 gc time: 36
其中,cputime是CPU处理时间,gc count是GC次数,gctime是GC时间。 在步骤S506中,在UI初始化事件对服务端的远程调用结束时通知
PerformanceLog类。在一个实施例中,通过执行invokePerformed通知
PerformanceLog类远禾呈调用结束。
在步骤S507中,UIFactory类声明UI初始化事件结束,PerformanceLog类
将所述记录的内容输出到性能日志文件中。所记录的内容包括UI初始化事件
对客户端的资源消耗差异和对服务端的远程调用参数。
图7示出了本发明的一个实施例中Action执行事件与UI初始化事件具有嵌 套关系时GUI性能日志的生成方法的流程。在一个实施例中,其具体时序过程 可参考附图8。该实施例中,在列表界面BizListUI上选中一行,点击"修改" 按钮,执行一些逻辑后弹出编辑界面BizEditUI,则Action执行事件是UI初始化 事件的父事件。其具体过程如下
在步骤S701中,ItemAction类声明Action执行事件开始。
在步骤S702中,执行actionPerformed。
在步骤S703中,记录Action执行事件在客户端的资源消耗参数。
在步骤S704中,创建UI对象实例。
在步骤S705中,UIFactory类声明UI初始化事件开始。在步骤S706中,记录UI初始化事件在客户端的资源消耗参数。 在步骤S707中,UIFactory类声明UI初始化事件结束。 在步骤S708中,记录Action执行事件在客户端的资源消耗参数。 在步骤S709中,ItemAction类声明Action执行事件结束,PerformanceLog 类将所述记录的内容输出到性能日志文件中。
图9示出了本发明的一个实施例中GUI性能日志的逻辑结构。该性能曰志 基于图1所述系统及图2所示方法流程生成,所述性能日志记录了每个性能事 务在客户端的资源消耗参数以及所述性能事务在执行过程中对服务端的远程 调用参数。
在一个实施例中,所述性能事务包括Action执行事件和UI初始化事件。应 当说明的是,性能事件是性能事务的组成部分, 一个性能事务包含了多个性 能事件。定义Action执行事件和UI初始化事件是为量化性能事务的时间组成及 与服务端的交互。在一个实施例中,Action执行事件可对应GUI中的一个按钮 或菜单执行的业务逻辑,UI初始化事件对应执行一些逻辑后弹出的编辑界面。
图10示出了本发明的一个实施例中GUI性能日志的UML类图。该UML类 图基于上述GUI性能日志生成方法生成,其中
RpcLog类表示输出的GUI性能日志,其与至少一个Action (即性能事务) 关联,这里的Action包括Action执行事件和UI初始化事件,而一个性能事务与 至少一个ActionEntry关联,ActionEntry表示具体的性能事件,可包括以下内容
Rpclnvoke类,表示对服务端的远程调用。其输出的参数包括远程调用号 (invoke—id,用于唯一标志一次远程调用)、远程调用时间(time)、网络传 输时间(net time)、上行数据量(request)和下行数据量(reponse )等。
CachedRpclnvoke类,表示命中了本地緩存的远程调用,其实际并没有与 服务端进行交互,而直接从客户端获取数据。
Userlnput类,表示一次用户的操作,例如鼠标点击、键盘输入等。
SubAction类,表示子Action性能事件。例如,如图8所示,在列表界面 BizListUI上选中一行,点击"修改"按钮,执行一些逻辑后弹出编辑界面 BizEditUI,则Action性能事件是UI初始化性能事件的父事件,而UI初始化性 能事件是子Action性能事件。
Update Jar类,表示使用某个功能时,需要从服务端更新最新的程序包, 该性能事件用于量化用户等待时间中,更新下载的时间。
MainFrame Quit类,表示未声明性能事件的异步线程或主线程性能事件之 外的远程调用,在客户端退出时统一输出。
12Thread Su匪ary类,表示线程为AWT-EventQueue-l的内容,用于了解用
户操作的全过程。
stackleve卜l的Action,表示最外层性能事件。例如,用户通过鼠标点击界 面BizListUI上的"修改"按钮,首先执行按钮上绑定的性能事件,然后这个 性能事件的逻辑中又初始化了一个新界面BizEditUI,则BizListUI上"修改" 按钮绑定的性能事件是最外层性能事件(即父Action),其stackleveK,而 BizEditUI的初始化是子Action,其stackleve^2,以此类推。记录最外层性能事 件具体可包括以下性能参数
本次性能事件及其所有的子Action的远程调用总次数(stack RpcNumber)、本次性能事件及其所有的子Action的远程调用总时间(stack RpcTime )、本次性能事件及其所有的子Action的远程调用网络传输时间(stack NetTime)、本次性能事件及其所有的子Action的远程调用数据量(stack RpcBytes)、用户的所有鼠标或键盘输入次数(Operation)、每次用户操作的 网络通讯次数(waitRpcNumber )、每次用户操作的网络通讯数据量(wait RpcBytes)、客户端中央处理器处理时间(cpu Time)、客户端GC次数(gc Count)、客户端GC时间(gc Time )等等。
在本次性能事件及其所有子Action事件执行结束后,性能日志还将输出以 下性能参数每次用户操作的网络通讯次数在当前性能事件中的最大值(Max waitRpcNumber)、每次用户操作的网络通讯数据量在当前性能事件中的最大 值(Max waitRpcBytes )、每次用户操作的等待时间在当前性能事件的最大值 (Max waitTime )等。
在一个具体的实施例中,在本次性能事件及其所有子Action事件执行结束 后,性能日志输出的内容如下
==============rpcInvoke end============== 9:38:23
RPC Number: 6 SubAction Number: 2 Cached RPC Number: 0
rpc time: 1641 ms request: 1392 B response: 1918 B
stack rpc time: 2938 ms stack request: 3485 B stack response: 5965 B
stack RPCNumber: 13
cpu time: 312 gc count: 3 gc time: 36
action time: 6875 ms UserOperation: 4 MaxWaitRPCNumber: 6 MaxWaitRPCBytes: 4263 B MaxWaitTime: 1593 ms
图ll示出了本发明的一个实施例中GUI性能分析方法的流程,该方法基于 上述生成的性能日志,具体包括以下步骤
在步骤Sl 101中,根据性能事务执行的不同时间对客户端的资源消耗差异和对服务端的远程调用参数生成性能日志。
在步骤S1102中,根据远程调用参数判断性能事务对服务端的远程调用状况。
在步骤S1103中,根据客户端的资源消耗差异判断性能事务在客户端的资 源消库毛状况。
在一个实施例中,可根据上述GUI性能日志生成系统及方法生成性能日 志,所生成的性能日志用来分析GUI性能。
在一个实施例中,记录的性能事务对服务端的远程调用参数包括远程调 用号(invoke—id,用于唯一标志一次远程调用)、远程调用时间(time)、网 络传输时间(net time)、上行数据量(request)和下行数据量(reponse )等。 记录的客户端的资源消耗差异包括CPU处理时间(Cputime)、 GC时间(GC time)和GC次数(GC count)等。
图12示出了本发明的一个实施例中根据远程调用参数判断性能事务对服 务端的远程调用状况的方法流程,包括以下步骤
在步骤S1201中,根据性能事务对服务端的远程调用时间判断对服务端的 远程调用状况。在一个实施例中,性能事务响应时间较长大都由于对服务端 的远程调用不当,需确定对服务端的远程调用时间较长的性能事务。在大多 数情况下,用户操作等待的时间较长(即Max WaitTime较大),是因为对服 务端的远程调用比较耗时(即RpcTime较大),其中大多数情况,是某几次远 程调用比较耗时,因此需要确定耗时较长的性能事务,并联查服务端日志, 分析优化服务端算法。
在步骤S1202中,根据性能事务对服务端的远程调用次数判断对服务端的 远程调用状况。在一个实施例中,需要分析性能事务对服务端的远程调用次 数是否较多,对服务端的远程调用次数较多时表现为Max WaitRpcNumber较 大,则需要减少与服务端的交互次数。
在步骤S1203中,根据网络传输时间判断网络状况。在一个实施例中,网 络传输时间较长时表现为Net Time较大,则可能是与服务端交互的数据量过大 (即Max WaitRpcBytes较大),则需要只传输客户端显示必需的数据,或分 次异步传输数据;还有可能是网络状态不佳,则需分析网络延时、带宽等。
图13示出了本发明的一个实施例中根据客户端的资源消耗差异判断性能 事务在客户端的资源消耗状况的方法流程。具体包括以下步骤
在步骤S1301中,根据中央处理器处理时间判断性能事务对中央处理器的 资源消耗状况。在一个实施例中,中央处理器处理时间较长表现为CPU Time较大,则需要优化客户端方法调用,减少循环时间。
在步骤S1302中,才艮据GC时间和/或GC次数判断性能事务对内存的资源消 耗状况。在一个实施例中,内存回收时间或内存回收次数较大分别表现为gc Time或gcCount较大,则需要优化内存占有,以避免小对象频繁创建、不申请 大块连续内存、减少非连续内存占用等。
在一个实施例中,GUI性能分析方法还包括检测性能事务从本地文件系 统读取文件的状况,根据检测结果分析性能事务响应状况。性能日志分析性 能事件频繁从本地文件系统中读取文件也是导致性能事务响应时间较长的原 因之一,此时,需减少读取文件代码次数。
本发明提供的GUI性能日志生成系统、方法及GUI性能分析方法,相对于 Java性能剖析器,由于其仅记录能代表功能点的性能事务,对应用程序响应时 间的影响4艮小,因此能提高应用程序性能分析效率。由于所记录的性能事务 能代表一定功能点,性能日志中一个性能事务的时间组成,能真实反映用户 在一个操作后的等待时间,不存在Java性能剖析器对每个Java指令增加一个延 时导致的失真问题,因此能有效反映性能的真实情况。本发明可以很方便的 由用户或实施人员打开性能日志,因此可以在生产环境下使用。另外,由于 运行速度影响很小,可以在用户的日常操作中长时间打开,便于在第一现场 收集性能数据。本发明还提供GUI性能分析方法,便于快速分析性能缺陷,找 出伊M匕方向。
以上所述仅为本发明的较佳实施例而已,并不用以限制本发明,凡在本 发明的精神和原则之内所作的任何修改、等同替换和改进等,均应包含在本 发明的保护范围之内。
权利要求
1、一种GUI性能日志生成系统,其特征在于,所述系统包括性能事务记录单元,记录在执行性能事务的第一时间和第二时间所述性能事务对客户端的资源消耗差异,以及性能事务对服务端的远程调用参数;性能日志生成单元,与所述性能事务记录单元进行数据交互,根据所述性能事务记录单元记录的客户端的资源消耗差异和远程调用参数生成性能日志。
2、 根据权利要求1所述的GUI性能日志生成系统,其特征在于,所述第一 时间是性能事务开始,所述第二时间是所述性能事务结束。
3、 根据权利要求1或2所述的GUI性能日志生成系统,其特征在于,所述 性能事务包括Action执行事件和UI初始化事件。
4、 一种GUI性能日志生成方法,其特征在于,所述方法包括以下步骤A. 记录在执行性能事务的第 一 时间和第二时间所述性能事务对客户端的 资源消耗差异,以及性能事务对服务端的远程调用参数;B. 根据所述记录的客户端的资源消耗差异和远程调用参数生成性能曰
5、 根据权利要求4所述的GUI性能日志生成方法,其特征在于,所述第一 时间是性能事务开始,所述第二时间是性能事务结束,所述步骤A中记录在执 行性能事务的第 一 时间和第二时间所述性能事务对客户端的资源消耗的差异 进一步包括Al .在性能事务开始时获取客户端的资源消耗参数; A2.在性能事务结束时获取客户端的资源消耗参数; A3.记录开始和结束时性能事务对客户端的资源消耗差异。
6、 根据权利要求4或5所述的GUI性能日志生成方法,其特征在于,所述 性能事务包括Action执行事件和UI初始化事件。
7、 一种GUI性能分析方法,其特征在于,包括以下步骤 A,.根据性能事务执行的不同时间对客户端的资源消耗差异和对服务端的远程调用参数生成性能曰志;B,.根据所述远程调用参数判断性能事务对服务端的远程调用状况;C,.根据所述客户端的资源消耗差异判断性能事务在客户端的资源消耗状况。
8、 根据权利要求7所述的GUI性能分析方法,其特征在于,所述远程调用 参数包括远程调用时间、远程调用次数和网路传输时间,所述步骤B,包括B1 ,.根据性能事务对服务端的远程调用时间判断对服务端的远程调用状况;B2,.根据性能事务对服务端的远程调用次数判断对服务端的远程调用状况;B2,.根据网络传输时间判断网络状况。
9、 根据权利要求7所述的GUI性能分析方法,其特征在于,所述客户端的 资源消耗包括中央处理器处理时间、GC时间和/或GC次数,所述步骤C,包 括Cl,.根据中央处理器处理时间判断性能事务对中央处理器的资源消耗状况;C2,.根据GC时间和/或GC次数判断性能事务对内存的资源消耗状况。
10、 根据权利要求7至9中任意一项所述的GUI性能分析方法,其特征在于, 所述方法还包括检测性能事务从本地文件系统读取文件的状况,根据检测 结果分析性能事务响应状况。
全文摘要
本发明提供了一种GUI性能日志生成系统、方法及GUI性能分析方法。所述GUI性能日志生成方法包括以下步骤A.记录在执行性能事务的第一时间和第二时间所述性能事务客户端的资源消耗差异,以及性能事务对服务端的远程调用参数;B.根据所述记录的客户端的资源消耗差异和远程调用参数生成性能日志。采用本发明提供的GUI性能日志生成系统、方法及GUI性能分析方法,能够提高应用程序的性能分析效率且能有效反应性能真实情况。
文档编号G06F11/36GK101425037SQ20081018107
公开日2009年5月6日 申请日期2008年11月20日 优先权日2008年11月20日
发明者慷 殷 申请人:金蝶软件(中国)有限公司
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1