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

Abstract

本发明提供了一种GUI性能日志生成系统、方法及GUI性能分析方法。所述GUI性能日志生成方法包括以下步骤：A.记录在执行性能事务的第一时间和第二时间所述性能事务客户端的资源消耗差异，以及性能事务对服务端的远程调用参数；B.根据所述记录的客户端的资源消耗差异和远程调用参数生成性能日志。采用本发明提供的GUI性能日志生成系统、方法及GUI性能分析方法，能够提高应用程序的性能分析效率且能有效反应性能真实情况。

Description

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

技术领域

本发明涉及计算机技术领域，更具体地说，涉及一种GUI性能日志生成系统、方法及GUI性能分析方法。

背景技术

无论是在开发环境或生产环境中，都需要一种分析应用程序运行性能的工具，通过量化的性能指标，定位到具有性能缺陷的功能点，从而给出缺陷的性质及初步的优化方向。

图形用户接口(Graphical User Interface，简称“GUI″)是屏幕产品的视觉体验和互动操作部分，例如Windows以图形界面方式操作，用鼠标点击按钮进行操作非常直观。

在Java领域，分析性能问题的主要工具是Java性能剖析器(Java Profiler)，其分析应用程序性能的方法如下：(1)在应用程序启动时，开启JVMTI(JavaVirtual Machine Tool Interface，是一套由Java虚拟机提供的、为Java虚拟机相关的工具提供的本地编程接口集合)服务；(2)指定一个分析范围(例如可以是某个命名空间的所有类)，通过Java虚拟机的JVMTI接口，附加到正在运行的应用程序上；(3)记录应用程序执行过程中的Java指令执行或对象创建等明细信息；(4)性能剖析器根据记录的明细信息生成性能图表。

采用Java性能剖析器分析应用程序性能，由于必须记录分析范围内的每个Java指令，会使所有Java指令的执行时间增加，累计的效果就是大大降低了应用程序的整体运行速度。而随着分析范围的增大，可能会几倍甚至几十倍地增加功能的响应时间。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中记录在执行性能事务的第一时间和第二时间所述性能事务对客户端的资源消耗的差异进一步包括：

A1.在性能事务开始时获取客户端的资源消耗参数；

A2.在性能事务结束时获取客户端的资源消耗参数；

A3.记录开始和结束时性能事务在客户端的资源消耗差异。

该性能事务包括：Action执行事件和UI初始化事件。

为了更好的实现发明目的，所述GUI性能分析方法包括以下步骤：

A′.根据性能事务执行的不同时间对客户端的资源消耗差异和对服务端的远程调用参数生成性能日志，所述性能事务为能代表功能点的性能事务；

B′.根据远程调用参数判断性能事务对服务端的远程调用状况；

C′.根据客户端的资源消耗差异判断性能事务在客户端的资源消耗状况。

该远程调用参数包括远程调用时间、远程调用次数和网络传输时间，步骤B’包括：

B1′.根据性能事务对服务端的远程调用时间判断对服务端的远程调用状况；

B2′.根据性能事务对服务端的远程调用次数判断对服务端的远程调用状况；

B3′.根据网络传输时间判断网络状况。

该客户端的资源消耗差异包括：中央处理器处理时间、GC时间和/或GC次数，步骤C’包括：

C1′.根据中央处理器处理时间判断性能事务对中央处理器的资源消耗状况；

C2′.根据GC时间和/或GC次数判断性能事务对内存的资源消耗状况。

该分析方法还包括：检测性能事务从本地文件系统读取文件的状况，根据检测结果分析性能事务响应状况。

由上可知，本发明记录了性能事务执行时对客户端的资源消耗以及对服务端的远程调用参数，由于该性能事务能代表不同的功能点，因此无需对每个Java指令进行分析，提高了应用程序性能分析效率；另外，记录参数时不会造成指令的延时，所输出的性能参数能真实反映用户在一个操作后的等待时间，因此能有效反映性能的真实情况。

附图说明

图1是本发明其中一个实施例中GUI性能日志生成系统的结构示意图；

图2是本发明其中一个实施例中GUI性能日志生成方法的流程图；

图3是本发明其中一个实施例中基于Action执行事件的性能日志生成方法的流程图；

图4是本发明其中一个实施例中基于Action执行事件的性能日志生成方法的时序图；

图5是本发明其中一个实施例中基于UI初始化事件的性能日志生成方法的流程图；

图6是本发明其中一个实施例中基于UI初始化事件的性能日志生成方法的时序图；

图7是本发明其中一个实施例中Action执行事件与UI初始化事件具有嵌套关系时GUI性能日志生成方法的流程图；

图8是本发明其中一个实施例中Action执行事件与UI初始化事件具有嵌套关系时GUI性能日志生成方法的时序图；

图9是本发明其中一个实施例中GUI性能日志的逻辑结构图；

图10是本发明其中一个实施例中GUI性能日志的UML类图；

图11是本发明其中一个实施例中GUI性能分析方法的流程图；

图12是本发明其中一个实施例中根据远程调用参数分析性能事务对服务端的远程调用状况的方法流程图；

图13是本发明其中一个实施例中根据客户端的资源消耗差异判断性能事务在客户端的资源消耗状况的方法流程图。

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。

具体实施方式

在本发明中，通过记录性能事务在客户端的资源消耗差异和对服务端的远程调用参数，最后根据记录的资源消耗差异和远程调用参数生成性能日志，以及根据性能日志的内容对GUI性能进行分析。这样，能提高应用程序的性能分析效率且能有效反应性能真实情况。

图1示出了本发明的一个实施例中GUI性能日志生成系统的结构，该系统包括性能事务记录单元100和性能日志生成单元200。应当说明的是，本发明所有图示中各设备之间的连接关系是为了清楚阐释其信息交互及控制过程的需要，因此应当视为逻辑上的连接关系，而不应仅限于物理连接。其中：

性能事务记录单元100，用于记录在执行性能事务的第一时间和第二时间该性能事务对客户端的资源消耗差异，以及性能事务对服务端的远程调用参数。

性能日志生成单元200，与性能事务记录单元100进行数据交互，用于根据性能事务记录单元100记录的客户端的资源消耗差异和远程调用参数生成性能日志。

在一个实施例中，第一时间是性能事务开始，第二时间是性能事务结束，性能事务记录单元100进一步在性能事务开始和结束时获取客户端的资源消耗，并记录性能事务在开始和结束时客户端的资源消耗的差异。

在一个实施例中，性能事务包括Action执行事件和UI初始化事件。

图2示出了本发明的一个实施例中GUI性能日志生成方法的流程，该方法基于图1所示的系统结构，包括以下步骤：

在步骤S201中，记录在执行性能事务的第一时间和第二时间所述性能事务对客户端的资源消耗差异，以及性能事务对服务端远程调用参数。

在步骤S202中，根据记录的客户端的资源消耗差异和远程调用参数生成性能日志。

在一个实施例中，第一时间是性能事务开始，第二时间是性能事务结束。记录在执行性能事务的第一时间和第二时间所述性能事务对客户端的资源消耗的差异具体包括：(1)在性能事务开始时获取客户端的资源消耗参数；(2)在性能事务结束时获取客户端的资源消耗参数；(3)记录开始和结束时性能事务对客户端的资源消耗差异。

在一个实施例中，性能事务包括Action执行事件和UI初始化事件。关于基于Action执行事件和UI初始化事件的GUI性能日志生成方法将分别在下述内容进行详细描述。

在一个具体的实施方案中，GUI性能日志生成方法的具体过程包括：(1)声明性能事务开始；(2)记录性能事务开始的时间点，并在性能事务开始的时间点获取客户端的资源消耗参数；(3)在性能事务执行过程中记录性能事务对服务端的远程调用参数；(4)声明性能事务结束；(5)记录性能事务结束的时间点，并在性能事务结束的时间点获取客户端的资源消耗参数，以及记录性能事务开始和结束时客户端的资源消耗差异；(6)根据记录的客户端的资源消耗差异和远程调用参数生成性能日志。

在一个实施例中，所记录的性能事务对服务端的远程调用参数具体包括：远程调用号、远程调用接口名、远程调用方法名、远程调用持续时间、上行数据量、下行数据量和远程调用结束时间。所记录的客户端的资源消耗差异包括中央处理器处理时间、GC时间和GC次数。

应当说明的是，性能事件是性能事务(Action)的组成部分，一个性能事务包含了多个性能事件，UI初始化事件即用户界面(User Interface，简称“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中的一个按钮或菜单执行的业务逻辑。

在步骤S302中，执行actionPerformed。

在步骤S303中，记录Action执行事件开始的时间点，并在Action执行事件开始的时间点获取客户端的资源消耗参数。在一个实施例中，如图4所示，biz1和biz2分别表示纯客户端逻辑，其消耗一定的客户端资源，包括CPU处理时间、GC时间和GC次数，在biz1和biz2执行开始的时间点获取CPU处理时间、GC时间和GC次数。

在步骤S304中，在Action执行事件执行的过程中记录所述Action执行事件对服务端的远程调用参数。在一个实施例中，所记录的远程调用参数包括远程调用号、远程调用方法名、远程调用持续时间、上行数据量、下行数据量和远程调用结束时间。在一个实施例中，如图4所示，rpc1和rpc2分别表示对服务端的两个远程调用。

在一个具体的实施例中，在Action执行事件执行过程中记录的对服务端的远程调用参数的内容如下：

com.kingdee.eas.base.license.ILicenseController.requestLicense(com.kingdee.eas.base.license.LicenseUserlnfo，java.lang.String)int

time：0ms request：419B response：85B invoke_id：一972189611 end time：10:49:44

其中，

com.kingdee.eas.base.license.ILicenseController.requestLicense(com.kingdee.eas.base.license.LicenseUserInfo，java.lang.String)是该远程调用方法名，time是该远程调用持续时间，request是下行数据量，response是上行数据量，invoke id是远程调用名，end time是远程调用结束时间。

在步骤S305中，记录Action执行事件结束的时间点，并在所述Action执行事件结束的时间点获取客户端的资源消耗参数，以及记录客户端的资源消耗参数的差值。在一个实施例中，如图4所示，biz1和biz2分别表示纯客户端逻辑，其消耗一定的客户端资源，包括CPU处理时间、GC时间和GC次数，在biz1和biz2执行结束的时间点获取CPU处理时间、GC时间和GC次数，并记录与biz1和biz2执行开始的时间点获取到的CPU处理时间、GC时间和GC次数的差值，所述差值反映了biz1和biz2执行时对客户端的资源消耗状况。

在一个具体的实施例中，所记录的客户端的资源消耗差值如下：

cpu time：312gc count：3gc time：36

其中，cpu time是CPU处理时间，gc count是GC次数，gc time是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所示，biz1和biz2分别表示纯客户端逻辑，其消耗一定的客户端资源，包括CPU处理时间、GC时间和GC次数，在biz1和biz2执行开始的时间点获取CPU处理时间、GC时间和GC次数。

在步骤S504中，在UI初始化事件执行的过程中记录所述UI初始化事件对服务端的远程调用参数。在一个实施例中，所记录的远程调用参数包括远程调用号、远程调用方法名、远程调用持续时间、上行数据量、下行数据量和远程调用结束时间。在一个实施例中，如图6所示，rpc1和rpc2分别表示对服务端的两个远程调用。

在一个具体的实施例中，在U1初始化事件执行过程中记录的对服务端的远程调用参数如下：

com.kingdee.eas.basedata.assistant.client.CurrencyEditUl.initUlObject()

time：0ms request：OB response：0B invoke一d：一1end time：19:38:16

其中，

com.kingdee.eas.basedata.assistant.client.CurrencyEditUl.initUlObject是该远程调用方法名，time是该远程调用持续时间，request是下行数据量，response是上行数据量，invoke id是远程调用名，end time是远程调用结束时间。

在步骤S505中，记录U1初始化事件结束的时间点，并在所述U1初始化事件结束的时间点获取客户端的资源消耗参数，以及记录客户端的资源消耗参数的差值。在一个实施例中，如图6所示，biz1和biz2分别表示纯客户端逻辑，其消耗一定的客户端资源，包括CPU处理时间、GC时间和GC次数，在biz1和biz2执行结束的时间点获取CPU处理时间、GC时间和GC次数，并记录与biz1和biz2执行开始的时间点获取到的CPU处理时间、GC时间和GC次数的差值，所述差值反应了biz1和biz2执行时对客户端的资源消耗状况。

在一个具体的实施例中，所记录的客户端的资源消耗差异如下：

cpu time：312gc count：3gc time：36

其中，cpu time是CPU处理时间，gc count是GC次数，gc time是GC时间。

在步骤S506中，在UI初始化事件对服务端的远程调用结束时通知PerformanceLog类。在一个实施例中，通过执行invokePerformed通知PerformanceLog类远程调用结束。

在步骤S507中，UIFactory类声明U1初始化事件结束，PerformanceLog类将所述记录的内容输出到性能日志文件中。所记录的内容包括UI初始化事件对客户端的资源消耗差异和对服务端的远程调用参数。

图7示出了本发明的一个实施例中Action执行事件与UI初始化事件具有嵌套关系时GUI性能日志的生成方法的流程。在一个实施例中，其具体时序过程可参考附图8。该实施例中，在列表界面BizListUI上选中一行，点击“修改”按钮，执行一些逻辑后弹出编辑界面BizEditUI，则Action执行事件是UI初始化事件的父事件。其具体过程如下：

在步骤S701中，ItemAction类声明Action执行事件开始。

在步骤S702中，执行actionPerformed。

在步骤S703中，记录Action执行事件在客户端的资源消耗参数。

在步骤S704中，创建UI对象实例。

在步骤S705中，UIF ac tory类声明UI初始化事件开始。

在步骤S706中，记录UI初始化事件在客户端的资源消耗参数。

在步骤S707中，UIFactory类声明UI初始化事件结束。

在步骤5708中，记录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表示具体的性能事件，可包括以下内容：

RpcInvoke类，表示对服务端的远程调用。其输出的参数包括远程调用号(invoke id，用于唯一标志一次远程调用)、远程调用时间(time)、网络传输时间(net time)、上行数据量(request)和下行数据量(reponse)等。

Cached即cInvoke类，表示命中了本地缓存的远程调用，其实际并没有与服务端进行交互，而直接从客户端获取数据。

User Input类，表示一次用户的操作，例如鼠标点击、键盘输入等。

SubAction类，表示子Action性能事件。例如，如图8所示，在列表界面BizListUI上选中一行，点击“修改”按钮，执行一些逻辑后弹出编辑界面BizEditUI，则Action性能事件是UI初始化性能事件的父事件，而UI初始化性能事件是子Action性能事件。

Update Jar类，表示使用某个功能时，需要从服务端更新最新的程序包，该性能事件用于量化用户等待时间中，更新下载的时间。

MainFrame Quit类，表示未声明性能事件的异步线程或主线程性能事件之外的远程调用，在客户端退出时统一输出。

Thread Summary类，表示线程为AWT-EventQueue-1的内容，用于了解用户操作的全过程。

stacklevel＝1的Action，表示最外层性能事件。例如，用户通过鼠标点击界面BizListUI上的“修改”按钮，首先执行按钮上绑定的性能事件，然后这个性能事件的逻辑中又初始化了一个新界面BizEditUI，则BizListUI上“修改”按钮绑定的性能事件是最外层性能事件(即父Action)，其stacklevel＝1，而BizEditUl的初始化是子Action，其stacklevel＝2，以此类推。记录最外层性能事件具体可包括以下性能参数：

本次性能事件及其所有的子Action的远程调用总次数(stackRpcNumber)、本次性能事件及其所有的子Action的远程调用网络传输时间(stackNetTime)、本次性能事件及其所有的子Action的远程调用数据量(stackRpcBytes)、用户的所有鼠标或键盘输入次数(Operation)、每次用户操作的网络通讯次数(waitRpcNumber)、每次用户操作的网络通讯数据量(waitRpcBytes)、客户端中央处理器处理时间(cpu Time)、客户端GC次数(gcCount)、客户端GC时间(gc Time)等等。

在本次性能事件及其所有子Action事件执行结束后，性能日志还将输出以下性能参数：每次用户操作的网络通讯次数在当前性能事件中的最大值(MaxwaitRpcNumber)、每次用户操作的网络通讯数据量在当前性能事件中的最大值(Max waitRpcBytes)、每次用户操作的等待时间在当前性能事件的最大值(Max waitTime)等。

在一个具体的实施例中，在本次性能事件及其所有子Action事件执行结束后，性能日志输出的内容如下：

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝rpcInvoke end＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝9:38:23

RPC Number：6SubAction Number：2Cached RPC Number：0

rpc time：1641ms request：1392B response：1918B

stack rpc time：2938ms stack request：3485B stack response：5965B

stack RPCNumber：13

cputime：312gc count：3gc time：36

action time：6875ms UserOperation：4MaXWaitRPCNumber：6

MaxWaitRPCBytes：4263B Max WaitTime：1593ms

图11示出了本发明的一个实施例中GUI性能分析方法的流程，该方法基于上述生成的性能日志，具体包括以下步骤：

在步骤S1101中，根据性能事务执行的不同时间对客户端的资源消耗差异和对服务端的远程调用参数生成性能日志。

在步骤S1102中，根据远程调用参数判断性能事务对服务端的远程调用状况。

在步骤S1103中，根据客户端的资源消耗差异判断性能事务在客户端的资源消耗状况。

在一个实施例中，可根据上述GUI性能日志生成系统及方法生成性能日志，所生成的性能日志用来分析GUI性能。

在一个实施例中，记录的性能事务对服务端的远程调用参数包括远程调用号(invoke id，用于唯一标志一次远程调用)、远程调用时间(time)、网络传输时间(net time)、上行数据量(request)和下行数据量(reponse)等。记录的客户端的资源消耗差异包括CPU处理时间(Cpu time).GC时间(GCtime)和GC次数(GC count)等。

图12示出了本发明的一个实施例中根据远程调用参数判断性能事务对服务端的远程调用状况的方法流程，包括以下步骤：

在步骤S1201中，根据性能事务对服务端的远程调用时间判断对服务端的远程调用状况。在一个实施例中，性能事务响应时间较长大都由于对服务端的远程调用不当，需确定对服务端的远程调用时间较长的性能事务。在大多数情况下，用户操作等待的时间较长(即Max WaitTime较大)，是因为对服务端的远程调用比较耗时(即RpcTime较大)，其中大多数情况，是某几次远程调用比较耗时，因此需要确定耗时较长的性能事务，并联查服务端日志，分析优化服务端算法。

在步骤S1202中，根据性能事务对服务端的远程调用次数判断对服务端的远程调用状况。在一个实施例中，需要分析性能事务对服务端的远程调用次数是否较多，对服务端的远程调用次数较多时表现为Max WaitRpcNumber较大，则需要减少与服务端的交互次数。

在步骤S1203中，根据网络传输时间判断网络状况。在一个实施例中，网络传输时间较长时表现为Net Time较大，则可能是与服务端交互的数据量过大(即MaxWaitRpcBytes较大)，则需要只传输客户端显示必需的数据，或分次异步传输数据；还有可能是网络状态不佳，则需分析网络延时、带宽等。

图13示出了本发明的一个实施例中根据客户端的资源消耗差异判断性能事务在客户端的资源消耗状况的方法流程。具体包括以下步骤：

在步骤S1301中，根据中央处理器处理时间判断性能事务对中央处理器的资源消耗状况。在一个实施例中，中央处理器处理时间较长表现为CPU Time较大，则需要优化客户端方法调用，减少循环时间。

在步骤S1302中，根据GC时间和/或GC次数判断性能事务对内存的资源消耗状况。在一个实施例中，内存回收时间或内存回收次数较大分别表现为gcTime或gc Count较大，则需要优化内存占有，以避免小对象频繁创建、不申请大块连续内存、减少非连续内存占用等。

在一个实施例中，GUI性能分析方法还包括：检测性能事务从本地文件系统读取文件的状况，根据检测结果分析性能事务响应状况。性能日志分析性能事件频繁从本地文件系统中读取文件也是导致性能事务响应时间较长的原因之一，此时，需减少读取文件代码次数。

本发明提供的GUI性能日志生成系统、方法及GUI性能分析方法，相对于Java性能剖析器，由于其仅记录能代表功能点的性能事务，对应用程序响应时间的影响很小，因此能提高应用程序性能分析效率。由于所记录的性能事务能代表一定功能点，性能日志中一个性能事务的时间组成，能真实反映用户在一个操作后的等待时间，不存在Java性能剖析器对每个Java指令增加一个延时导致的失真问题，因此能有效反映性能的真实情况。本发明可以很方便的由用户或实施人员打开性能日志，因此可以在生产环境下使用。另外，由于运行速度影响很小，可以在用户的日常操作中长时间打开，便于在第一现场收集性能数据。本发明还提供GUI性能分析方法，便于快速分析性能缺陷，找出优化方向。

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本发明的保护范围之内。

Claims (10)

1.一种GUI性能日志生成系统，其特征在于，所述系统包括：

性能事务记录单元，记录在执行性能事务的第一时间和第二时间所述性能事务对客户端的资源消耗差异，以及性能事务对服务端的远程调用参数，所述性能事务为能代表功能点的性能事务；

性能日志生成单元，与所述性能事务记录单元进行数据交互，根据所述性能事务记录单元记录的客户端的资源消耗差异和远程调用参数生成性能日志。

2.根据权利要求1所述的GUI性能日志生成系统，其特征在于，所述第一时间是性能事务开始，所述第二时间是所述性能事务结束。

3.根据权利要求1或2所述的GUI性能日志生成系统，其特征在于，所述性能事务包括Action执行事件和UI初始化事件。

4.一种GUI性能日志生成方法，其特征在于，所述方法包括以下步骤：

A.记录在执行性能事务的第一时间和第二时间所述性能事务对客户端的资源消耗差异，以及性能事务对服务端的远程调用参数，所述性能事务为能代表功能点的性能事务；

B.根据所述记录的客户端的资源消耗差异和远程调用参数生成性能日志。

5.根据权利要求4所述的GUI性能日志生成方法，其特征在于，所述第一时间是性能事务开始，所述第二时间是性能事务结束，所述步骤A中记录在执行性能事务的第一时间和第二时间所述性能事务对客户端的资源消耗的差异进一步包括：

A1.在性能事务开始时获取客户端的资源消耗参数；

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’包括：

C1′.根据中央处理器处理时间判断性能事务对中央处理器的资源消耗状况；

C2′.根据GC时间和/或GC次数判断性能事务对内存的资源消耗状况。

10.根据权利要求7至9中任意一项所述的GUI性能分析方法，其特征在于，所述方法还包括：检测性能事务从本地文件系统读取文件的状况，根据检测结果分析性能事务响应状况。

Images