CN103793237A - J2ee 应用系统性能瓶颈定位方法与装置 - Google Patents

Abstract

本发明公开一种J2EE应用系统性能瓶颈定位方法与装置，用于监控J2EE应用系统在使用过程中出现的系统性能问题，该J2EE应用系统性能瓶颈定位方法包括：通过J2EE的虚拟机装载类载入器；获取所述类载入器所载入类对应方法的运行时间，所述运行时间用于定位J2EE应用系统性能瓶颈的位置。本发明技术方案不需要应用系统改造，通过实现可挂载式自定义类载入器，能够完全定位端到端的业务系统性能瓶颈。

Description

J2EE 应用系统性能瓶颈定位方法与装置

技术领域

本发明涉及信息运营管理领域，更具体的，涉及一种J2EE应用系统性能瓶颈定位方法与装置。 

背景技术

基于J2EE（Java 2Platform，Enterprise Edition，Java平台企业版）的B/S（Browser/Server，浏览器/服务器）架构的应用系统在企业内部的应用越来越广泛，在移动领域，包括核心的CRM（Customer Relationship Management，客户关系管理）应用、管信系统和对客户体验产生直接影响的网上营业厅系统等都是J2EE架构的。但在这些应用系统的使用过程中经常会发生一些系统性能问题，从而导致最终用户无法正常使用系统功能，极大地降低了用户体验效果。为了快速排除这些系统性能瓶颈，恢复系统地正常使用，需要对这些应用系统进行实时监控，采集性能数据，并且将采集的性能数据通过直观准确的方式进行端到端的分层，方便运维人员和开发人员进行应用性能瓶颈定位。同时由于运维人员和开发人员的专业知识和背景不同，运维人员希望快速了解系统性能瓶颈发生在哪一层，应该交给哪个专业组进行进一步诊断，而开发人员希望了解每一个Java调用方法的时间，引起性能瓶颈的具体SQL语句。 

为了详细了解发生系统性能瓶颈的业务的后台调用情况，并进行准确的定位，通常会有如下2个方向： 

第一，通过J2EE应用系统的改造，对于关键的方法进行日志的输出，从而获取具体的系统性能的详细数据，达到定位系统性能瓶颈的目的。 

第二，通过多种监控工具，包括数据库、中间件队列监控等方式来推断后台应用目前的系统性能瓶颈所在。 

但是，上述两种现有技术存在如下缺陷： 

1）通过应用额外的日志开发会增加很大工作量，一定程度上导致应用系统本身性能的下降，使得监控过程过多占用了被监控对象有限的资源。另外，由于这种方法无法通过开关迅速剥离日志记录，使得日志记录的额外性能开销无法快速去除，应用系统产生大量的日志，而日志如果记录不全，很难定位具体业务系统性能的瓶颈。 

2）通过多种监控工具进行应用不同阶段的监控和诊断。这种方法虽然可以监控和诊断一些应用开发的问题，比如SQL的低效率，但完全独立于应用端到端的连续性，而将应用的几个可预见的环节进行割裂式的监控和诊断，无法实现端到端监控和定位业务系统性能瓶颈的效果。 

因此，现有技术中存在J2EE应用系统性能监控效果不佳的问题。 

发明内容

本发明提供一种J2EE应用系统性能瓶颈定位方法与装置，用于解决现有技术中存在J2EE应用系统性能监控效果不佳的问题。 

为实现上述目的，根据本发明的一个方面，提供一种J2EE应用系统性能瓶颈定位方法，并采用如下技术方案： 

J2EE应用系统性能瓶颈定位方法包括：通过J2EE的虚拟机装载类载入器；获取所述类载入器所载入类对应方法的运行时间，所述运行时间用于定位J2EE应用系统性能瓶颈的位置。 

进一步地，所述在通过J2EE的虚拟机装载类载入器之前，所述定位方法包括：通过增加所述虚拟机的启动参数挂载所述类载入器。 

进一步地，所述获取所述类载入器载入的类所对应方法的运行时间包括：对载入所述类载入器的每一个类对应的每一个方法进行调用注册；获取所述每一个方法的执行开始时间和执行结束时间。 

进一步地，所述对载入所述类载入器的每一个类对应的每一个方法进行调用注册包括：在所述类载入器载入所述每一个类的Class字节码的同时，在所述Class中第一行和最后一行增加获取时间戳的输出语句。 

进一步地，在所述通过J2EE的虚拟机装载类载入器之后，所述定位方法还包括：通过判断所述载入类的类型来确定所述载入类的分层，所述分层用于 定位所述应用系统性能瓶颈所在的分层位置。 

进一步地，在所述类型为页面请求入口类型的继承类时，确定所述载入类的分层为WEB层。 

进一步地，在所述类型为连接池类时，确定所述载入类的分层为数据库连接层。 

进一步地，在所述类型为SQL语句的执行类的方法调用时，确定所述载入类的分层为数据库执行层。 

进一步地，在所述分层不为所属WEB层、所述数据库连接层以及所述数据库执行层时，确定所述载入类的分层为应用层。 

根据本发明的另外一个方面，提供一种J2EE应用系统性能瓶颈定位装置，并采用如下技术方案： 

J2EE应用系统性能瓶颈定位装置包括：装载模块，用于通过J2EE的虚拟机装载类载入器；获取模块，用于获取所述类载入器所载入类对应方法的运行时间，所述运行时间用于定位J2EE应用系统性能瓶颈的位置。 

进一步地，所述获取模块包括：调用模块，用于对载入所述类载入器的每一个类对应的每一个方法进行调用注册；获取子模块，用于获取所述每一个方法的执行开始时间和执行结束时间。 

进一步地，所述调用模块包括：增加模块，用于在所述类载入器载入所述每一个类的Class字节码的同时，在所述Class中第一行和最后一行增加获取时间戳的输出语句。 

进一步地，J2EE应用系统性能瓶颈定位装置还包括：确定模块，用于通过判断所述载入类的类型来确定所述载入类的分层，所述分层用于定位所述应用系统性能瓶颈所在的分层位置。 

本发明利用JVM（Java Virtual Machine，Java虚拟机）规范的类载入技术，在被监控应用启动时额外加载一个可选择的类载入器，从而获得J2EE应用在整个运行期间的所有方法调用链，同时通过应用分层识别（Application Layer Identify，ALI）技术来快速将J2EE的业务故障定位到Web层、应用层和数据库层，实现J2EE进行粗细结合，快速准确的性能瓶颈定位，可以同时帮助运维人员和开发人员对于应用进行性能优化。 

附图说明

附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中： 

图1表示现有技术中JVM启动和运行时的主要流程图； 

图2表示本发明实施例所述的J2EE应用系统性能瓶颈定位方法流程图； 

图3表示本发明实施例所述的JVM启动和运行时的主要流程图； 

图4表示本发明实施例所述的J2EE三层部署架构图；以及 

图5表示本发明实施例所述的J2EE应用系统性能瓶颈定位装置结构图。 

具体实施方式

以下结合附图对本发明的实施例进行详细说明，但是本发明可以由权利要求限定和覆盖的多种不同方式实施。 

图1表示现有技术中JVM启动和运行时的主要流程图。 

由于本发明基于J2EE应用，J2EE应用在运行时依赖于Java虚拟机(JVM)，参见图1所示，按照JVM的规范，所有执行代码都以字节码（.class文件）形式通过类载入器（Class Loader）载入到Java虚拟机，成熟的JVM产品都有其默认的类载入器，同时提供扩展默认类载入器的能力。 

本方案基于这个规范，实现了额外的类载入器。 

图2表示本发明实施例所述的J2EE应用系统性能瓶颈定位方法流程图。 

参见图2所示，J2EE应用系统性能瓶颈定位方法可包括如下步骤： 

S101：通过J2EE的虚拟机装载类载入器； 

S103：获取所述类载入器所载入类对应方法的运行时间，所述运行时间用于定位J2EE应用系统性能瓶颈的位置。 

基于所有执行代码都以字节码（.class文件）形式通过类载入器（Class Loader）载入到Java虚拟机，因此，在本实施例的技术方案中，通过步骤S101中的装载一自定义的类载入器，该自定义的类载入器能够获取通过该自定义的类载入器的类对应方法的运行时间，该运行时间便可用于定位J2EE应用系统性能瓶颈的位置。 

更具体的，J2EE应用系统性能瓶颈定位方法可通过图3进行说明，图3表示本发明实施例所述的JVM启动和运行时的主要流程图。对比图3与图1可知，挂载自定义类载入器可通过在物理机或操作系统层面，增加虚拟机启动参数-agentlib:CustomerClassLoader，实现挂载该自定义类载入器，但并不限于此。然后Java虚拟机将直接载入该自定义的类载入器，根据上述的JVM的规范可知，自定义类载入器在载入每一个类的Class字节码的同时，在Class中的每一个方法第一行和最后一行增加时间戳的输出，以获取该方法的执行时间，通过对该执行时间的分析，了解J2EE应用系统性能瓶颈的位置。 

本实施例通过上述方法，无需对应用系统任何改造就可以监控和快速准确定位J2EE应用在使用过程中的每一个方法调用链的时间。 

针对现有J2EE应用得三层部署架构特点，本案的技术部署如图4所示，图4表示本发明实施例所述的J2EE三层部署架构图。 

根据应用的特点，在每一个虚拟机上挂载自定义类载入器，这样，在虚拟机上载入的类都通过自定义类载入器，在载入过程中，通过类的注册方法，对每一个类的每一个方法进行调用注册。通过注册，获取每一个类的每一个方法的执行开始时间和执行结束时间，通过方法执行结束时间-方法执行开始时间，最终获取到每一个方法的运行时间。 

针对J2EE的访问规范，每一个请求都以JSP或者Servlet作为入口，J2EE通过一系列方法的调用，到数据库连接和SQL执行，最终返回请求内容作为结束，形成一个完整的方法调用链。这个过程一般从3个到数十个方法的调用。所有方法调用的结果示例如下： 

方法	耗时
		-/zjitsm/servlet/QueryAnalyse	40.9s
-QueryAnalyseAction.doPost()	40.9s
		-QueryAnalyse.analyse()	40.8s
-DataSourceImpl.getConnection()	8.7s
		-OraclePreparedStatement.executeQuery()	10.6s
-DataSourceImpl.getConnection()	9.9s

[0048] 

-OraclePreparedStatement.executeQuery()

10.6s

上述技术方案通过自定义类载入器获取所有类方法执行时间的技术，通过自定义载入器注册所有类方法执行，可以获取J2EE容器的生命周期中每一个具体方法的执行时间，方便开发人员诊断。

同时本发明考虑到普通维护人员没有开发背景，如果直接将所有请求的所有方法调用都列出，将不利于他们对于应用系统性能瓶颈的快速诊断，所以本方案在此基础上实现了一个关键技术，应用分层识别（Application Layer Identify，ALI）。 

因此，作为优选的实施方式，在所述通过J2EE的虚拟机装载类载入器之后，所述监控方法还包括：通过判断所述载入类的类型来确定所述载入类的分层，所述分层用于定位所述应用系统性能瓶颈所在的分层位置。 

并且，按照方法调用过程分成可以以下几个阶段： 

（一）WEB层 

WEB层的技术识别方法为JSP内部以及javax.servlet.HttpServlet的继承类的doPost、doGet方法以及其他该类自定义方法。而WEB层调用的总次数、总时长可以应用于请求并发以及J2EE服务器请求队列的故障诊断。 

因此，在所述载入类的类型为页面请求入口类型的继承类时，可确定所述载入类的分层为WEB层。 

（二）数据库连接层 

在Java体系中，最终与数据库的交互都是通过java.sql.Connection和javax.sql.DataSource完成，所以数据库连接层识别可以通过这2个类的连接方法进行数据库连接识别。在现代的J2EE应用中，更多使用了连接池技术，也就是不重复关闭然后再连接数据库的动作，基于以上特点，监控连接本身的连接和关闭没有意义，而需要监控从连接池获取已连接对象的时间。本方案集成了J2EE常用的10种连接池类，获取这些连接池获取连接的时间。因此，在所述载入类的类型为连接池类时，可确定所述载入类的分层为数据库连接层。 

（三）数据库执行层 

获取连接后，J2EE将执行特点业务逻辑的SQL语句，SQL语句执行时间很容易成为业务使用总体性能的瓶颈。在Java体系中，所有的连接或者连接 池对象在最后都会调用Statement的execute方法进行SQL语句的执行，本方案的识别技术就是通过这个方法的监控，来获取具体SQL语句的具体执行时间，从而快速定位业务系统性能瓶颈。因此，在所述载入类的类型为SQL语句的执行类的方法调用时，可确定所述载入类的分层为数据库执行层。 

（四）应用层 

应用层是实现应用逻辑的多个方法，在WEB层和数据库层之间起到承上启下的作用，包含的内容非常广。所以在应用层识别时，采用排除法进行识别，即非WEB层、数据库连接和数据库执行层的，统一归为应用层。这样，无论应用层的逻辑调用多么复杂多变，也能通过这种方法查看应用层的总体调用时间。 

按照应用的分层识别技术，所有Java方法调用结果可以进行如下层识别： 

由于上层调用时间包含下层调用时间，通过上层调用时间-下层调用时间，可以获取以下分层性能结果。 

通过以上分层的耗时，可以看到，针对/zjitsm/servlet/QueryAnalyse的请求，系统的性能瓶颈在数据库连接层和数据库执行层。这样运维人员能够快速将问题交由数据库开发人员进行处理。 

综上所述，本方案利用JVM规范以及J2EE应用的调用特点，创新的利用自定义类载入器获取每一个方法的调用时间，同时在具体方法调用时间的基础上利用应用分层识别技术，对J2EE进行粗细结合，快速准确的性能瓶颈定位，可以同时帮助运维人员和开发人员对于应用进行性能优化。 

图5表示本发明实施例所述的J2EE应用系统性能瓶颈定位装置结构图。 

参见图5所示，J2EE应用系统性能瓶颈定位装置包括：装载模块50，用于通过J2EE的虚拟机装载类载入器；获取模块52，用于获取所述类载入器所载入类对应方法的运行时间，所述运行时间用于判断J2EE应用系统的性能。 

优选地，所述获取模块52包括：调用模块（图中未示），用于对载入所述自定义类载入器的每一个类对应的每一个方法进行调用注册；获取子模块（图中未示），用于获取所述每一个方法的执行开始时间和执行结束时间。 

优选地，所述调用模块包括：增加模块（图中未示），用于在所述自定义类载入器载入所述每一个类的Class字节码的同时，在所述Class中第一行和最后一行增加获取时间戳的输出语句。 

优选地，J2EE应用系统性能瓶颈定位装置还包括：确定模块（图中未示），用于通过判断所述载入类的类型来确定所述载入类的分层，所述分层用于定位所述应用系统性能瓶颈所在的分层位置。 

具体地，确定模块按照以下方式确定载入类的分层：在所述类型为页面请求入口类型的继承类时，确定所述载入类的分层为WEB层；在所述类型为连接池类时，确定所述载入类的分层为数据库连接层；在所述类型为SQL语句的执行类的方法调用时，确定所述载入类的分层为数据库执行层；在所述分层不为所属WEB层、所述数据库连接层以及所述数据库执行层时，确定所述载 入类的分层为应用层。 

本发明通过自定义载入器注册所有类方法执行，可以获取J2EE容器的生命周期中每一个具体方法的执行时间，方便开发人员诊断。在此基础上，将所有方法利用应用分层识别技术快速汇聚成4个层次，实现运维人员对业务应用性能瓶颈的快速定位，最终有效保障和提高用户感知体验。而且被监控的J2EE应用系统无需任何改造，利用参数-agentlib挂载的启动方式也实现了与应用完全独立的运行模式，极具推广价值。因此，本发明不需要应用改造，实现可挂载式，能够完全端到端的定位业务系统性能瓶颈，同时实现了分层快速定位的技术。 

以上所述是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明所述原理的前提下，还可以作出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。 

Claims (13)

1.一种J2EE应用系统性能瓶颈定位方法，其特征在于，包括：

通过J2EE的虚拟机装载类载入器；

获取所述类载入器所载入类对应方法的运行时间，所述运行时间用于定位J2EE应用系统性能瓶颈的位置。

2.如权利要求1所述的定位方法，其特征在于，所述在通过J2EE的虚拟机装载类载入器之前，所述监控方法包括：

通过增加所述虚拟机的启动参数挂载所述类载入器。

3.如权利要求1所述的定位方法，其特征在于，所述获取所述类载入器载入的类所对应方法的运行时间包括：

对载入所述类载入器的每一个类对应的每一个方法进行调用注册；

获取所述每一个方法的执行开始时间和执行结束时间。

4.如权利要求3所述的定位方法，其特征在于，所述对载入所述类载入器的每一个类对应的每一个方法进行调用注册包括：

在所述类载入器载入所述每一个类的Class字节码的同时，在所述Class中第一行和最后一行增加获取时间戳的输出语句。

5.如权利要求1所述的定位方法，其特征在于，在所述通过J2EE的虚拟机装载类载入器之后，所述定位方法还包括：

通过判断所述载入类的类型来确定所述载入类的分层，所述分层用于定位所述应用系统性能瓶颈所在的分层位置。

6.如权利要求5所述的定位方法，其特征在于，在所述类型为页面请求入口类型的继承类时，确定所述载入类的分层为WEB层。

7.如权利要求6所述的定位方法，其特征在于，在所述类型为连接池类时，确定所述载入类的分层为数据库连接层。

8.如权利要求7所述的定位方法，其特征在于，在所述类型为SQL语句的执行类的方法调用时，确定所述载入类的分层为数据库执行层。

9.如权利要求8所述的定位方法，其特征在于，在所述分层不为所属WEB层、所述数据库连接层以及所述数据库执行层时，确定所述载入类的分层为应用层。

10.一种JJ2EE应用系统性能瓶颈定位装置，其特征在于，包括：

装载模块，用于通过J2EE的虚拟机装载类载入器；

获取模块，用于获取所述类载入器所载入类对应方法的运行时间，所述运行时间用于定位J2EE应用系统性能瓶颈的位置。

11.如权利要求10所述的定位装置，其特征在于，所述获取模块包括：

调用模块，用于对载入所述类载入器的每一个类对应的每一个方法进行调用注册；

获取子模块，用于获取所述每一个方法的执行开始时间和执行结束时间。

12.如权利要求11所述的定位装置，其特征在于，所述调用模块包括：

增加模块，用于在所述类载入器载入所述每一个类的Class字节码的同时，在所述Class中第一行和最后一行增加获取时间戳的输出语句。

13.如权利要求10所述的定位装置，其特征在于，还包括：

确定模块，用于通过判断所述载入类的类型来确定所述载入类的分层，所述分层用于定位所述应用系统性能瓶颈所在的分层位置。

Images