【IT168 技术文章】

    J2EE即Java 2企业版，或Java 2 Enterprise Edition，最近几年已经跃升成为几个响当当的技术缩写词之一。虽然有许多人乐意谈论J2EE，但真正能够胜任J2EE开发的人不是很多，善于开发J2EE应用的人就更少了。J2EE本身是一系列规范的集合，涉及诸多技术，除了包括人们熟知的Servlet、JSP之外，还包括EJB以及支持构建企业应用的整个基础设施。当前已经有不少实现了J2EE规范的应用服务器产品，其中包括：

    ◆ BEA WebLogic

    ◆ IBM WebSphere

    ◆ Oracle Application Server

    ◆ JBoss

    和其他技术一样，对于J2EE来说，构建一个健壮的、可伸缩的应用并保证其运行在非常好的状态是一门艺术，优化应用的运行环境也是一门艺术。掌握这门艺术的关键在于分析应用及其运行基础设置，同时还要求深入观察应用的运行情况。

    这个系列的文章主要探讨J2EE应用和应用服务器的性能优化问题。本文首先介绍性能优化的基本概念，介绍性能优化对于J2EE应用的意义，阐述J2EE环境中可优化的性能因素。

    一、什么是性能优化

    在深入探讨J2EE应用以及它下面的应用服务器的优化问题之前，首先我们要搞清楚性能优化到底是什么，因为在不同的场合性能优化这一概念有着不同的含义。就本文的讨论而言，性能优化的目标就是提高下面几个指标：并发用户数量，吞吐量，可靠性。

    换句话说，我们希望让应用更快地为更多的用户提供服务，且保证服务过程不会中断。

    当一个应用的性能未能满足要求，应当从哪里入手改善其性能？怎样的情况下才必须增加硬件设施？如何通过调整几个应用服务器的参数，获得比添加硬件设备更好的性能效果？这些问题都是实践中经常会遇到的问题，但遗憾的是，许多单位在看到应用的性能未能满足要求时，首先考虑的就是增加硬件设备。增加硬件设备无疑会提高应用的性能表现，但同时也会增加维护费用和硬件体系的复杂程度（更不用说购买硬件设备本身和软件许可的费用了）。

    我们的目标应该是首先从现有的应用和应用服务器榨取最大的性能，在此之后才考虑添加硬件设备。从长远来看，单纯靠添加硬件来提高性能很难获得好效果：虽然有可能暂时解决眼前的性能危机，但问题仍旧存在，一旦负载增加了又会出现。

    ■ 并发用户

    在应用服务器上运行应用，评估其在不能响应请求或响应请求所需时间超出许可范围之前能够支持的最大并发用户数量。响应时间可以由服务水准协议（Service Level Agreement，SLA，参见用 SLA 保证 Web 服务 ）定义，规定一个请求允许消耗的最长时间，超出该时间就被认为不可接受。对应用进行负载测试时很重要的一点是必须确保测试过程反映了应用实际运行过程中出现的典型事务，因为后来的性能优化措施将针对负载测试的结果进行。如果负载测试的事务不够典型，就不能有效地保证应用能够象测试环境中表现地那样为用户提供服务。

    ■ 吞吐量

    应用和应用服务器的吞吐量可以用每秒完成的事务数量来表示，它从一个侧面反映了应用和应用服务器的运行是否正常，指出了服务器的能力。我们的目标是通过应用和应用服务器的调整，来尽可能地提高服务器的吞吐量。

    ■ 可靠性

    除了支持最大数量的并发用户、可接受的响应时间之外，另一个要求就是尽量减少请求失败的次数。Web服务器都可能出现故障，最主要的原因是网络延迟或超时，而我们优化的主要工作就是确保用户能够收到他请求的信息。

    二、从哪些方面入手优化

    虽然一些性能监测和优化专家会试图让你相信某个企业应用的性能瓶颈或者在于应用本身的代码，或者在于应用服务器，但实际上，性能与这两者都有着密切的关系。应用的代码写得再好，如果应用服务器的配置不当，性能也不会好；同样地，应用服务器调整得再好，也难以掩盖应用代码中存在的缺陷。因此，首先要保证应用有一个稳固可靠的体系结构，有最优质高效的代码，在此基础上再来集中精力调整应用服务器。

    ■ 应用

    就优化性能而言，应用本身的优化属于最艰巨的步骤之一。首先要深入地分析业务逻辑，然后找出满足业务需求的非常受欢迎的解决方案。每一个业务领域都有其与众不同的特点，因此也不存在适用于所有业务领域的功能较多解决方案。然而，人们在实践中总结出了许多优秀的设计模式，在规划应用的体系结构时合理选用设计模式对性能大有好处。

    ■ 应用服务器

    选择应用服务器需要考虑许多因素，至少包括：应用服务器的价格，硬件部署，应用服务器厂商的表现，性能，等等。本文后面的讨论主要针对下面四种服务器：BEA WebLogic 7，IBM WebSphere，Oracle Application Server，JBoss。

    ■ 平台：硬件和JVM

    应用开发完毕、服务器选定之后，还要考虑操作系统和Java虚拟机的配置选项，适当地调整这些选项无疑也能够提高性能。

    ■ 后端资源

    许多J2EE应用需要访问后端资源，例如关系数据库。虽然后端资源的优化已经超出了J2EE的领域，但它决不是一个可以忽略的问题。即使应用在其他方面都做得很好，如果后端数据库总是迟迟不能响应，应用的整体性能必将大受影响。

    三、优化方法

    虽然我也希望能够告诉你：优化J2EE环境很简单，只需要把某几个参数调整到特定的值，一个小小的表格就足以把这些值全部列出。遗憾的是，实际问题要复杂得多，优化J2EE性能不仅要深入理解应用本身，而且还要掌握用户使用该应用的方式。下图展示了完整的优化过程。

    第一个必须考虑的因素就是用户，我们必须先回答下列问题：用户会怎样使用这个系统？根据问题的答案可以定义出一组要求系统执行的事务（在这里，“事务”这个概念是指用户发出的一系列请求）。注意这些事务必须能够典型地代表最终用户的操作行为，因为我们将根据这些事务的执行情况来调整系统！

    接下来，我们要在负载测试工具之内生成这些事务。负载测试工具能够控制并发用户数量、考虑时间、启动延迟等因素。

    模拟大量用户的操作方式对应用进行测试时，应当获取应用本身、应用服务器、底层平台、外部资源的运行时性能指数。最后，有了这些性能指数之后，还必须对这些数据进行对比、分析和解释。

    四、应用

    每一个应用都是不同的：响应用户请求的服务步骤不同，与后端资源的交互方式不同，业务需求也不同。例如，考虑一个合作伙伴通过Internet发送和处理交易请求的应用，其核心事务显然应该是收取交易请求，将交易请求提交给数据库，最后返回回执。相比之下，电子商务Web网站的核心事务就不同了，它的核心事务应该是提供一个可购买产品的目录，维护购物篮，以及处理购买信息。

    既然所有应用都是不同的，那么它们使用应用服务器资源的方式也不同，必须针对应用的具体情况指定不同的应用服务器配置。优化性能过程中最为重要的一个步骤就是：深入理解业务需求，定义一组精确反映最终用户操作方式的典型事务。如果这一步没有做好，很难指望应用会在实际运行环境中有好的表现。

    五、负载测试

    负载测试工具是一种能够模拟任意数量的用户与系统交互过程的工具，当前市场上已经有许多这类工具（参见本文后面的目录），虽然这些产品各有特色，但它们的核心功能不外乎：

    ◆ 能够针对应用系统执行用户定义的事务，保证适当的事务频度。

    ◆能够控制负载测试中并发用户的数量。

    ◆能够精确调整测试器在下列各方面的行为：两个请求之间用户的思考时间，上升到目标用户数量的速率。

    大多数商业负载测试器还提供了一个“学习”引擎，它允许测试者手工执行事务，而学习引擎则在后台观察和记录测试者的动作。

    总之，负载测试工具的目的是模拟实际运行环境中用户的操作方式。如果不能为应用定义一组典型的测试事务，就不能将应用精确地调整到最适合实际用户的状态。

    六、需要哪些信息？

    现在，我们已经有了模拟一系列并发用户的负载测试工具，每一个并发用户都能够运行典型地代表了应用使用情况的事务。接下来要做的是从应用和应用服务器获取运行时性能信息，包括：

    ◆应用服务器统计信息：内存使用情况，数据库连接使用情况，线程使用情况，等等。

    ◆应用性能（内部）：类和方法的响应时间，调用路径，异常方法，等等。

    ◆应用性能（外部）：负载测试器观察到的事务总量、构成事务的请求量。

    ◆平台性能：CPU，进程，等等。

    ◆后端资源性能：数据库性能，传统系统性能，等等。

    七、如何获取这些信息？

    我们主要探讨如何获取应用和应用服务器的性能数据；硬件、后端资源的性能数据已经超出了本文的范围。不同的应用服务器以不同的方式提供运行时性能数据，为了统一获取性能数据的机制，Sun发布了Java管理扩展（JMX，即Java Management Extension）。虽然目前JMX还未被所有的应用服务器厂商采用，但BEA WebLogic、IBM WebSphere 5、JBoss都已经选择JMX作为管理API，并通过JMX导出其配置和运行时信息；其他的应用服务器厂商也都提供了各自私有的获取运行时信息的办法，或者是通过提供几个专用的Servlet，或者是通过命令行工具。

    相比之下，获取应用的性能数据就比较复杂一些。虽然一些应用服务器能够监视应用的性能，报告最基本的性能信息，但一般而言，获取应用性能数据首选的办法还是通过代码指令。代码指令既可以直接嵌入到应用体系之内，例如在应用中嵌入一些监视性能的代码，然后通过某种方式导出到外部；或者也可以利用一个独立的进程，由该进程监视应用代码的运行情况。

    有许多商业软件厂商已经实现了能够连接到应用服务器的类装入器的代码指令，这样我们就不必对应用本身大动干戈，只要把应用部署到安装了监视设施的应用服务器上，应用服务器就会自动在创建应用的类时开始监视。

    在代码监视期间到底要收集哪些信息通常是可配置的，小到仅仅记录某个特定方法的响应时间，大到记录每一个发送给应用服务器的事务。不同的监视要求带来对系统的不同的开销和影响，收集的数据越多，监视操作的开销就越大，反之亦然。

    八、比较和分析数据

    前面我们探讨了如何在应用系统上用模拟负载进行测试，以及如何获取应用和应用服务器的运行时性能数据，接下来要做的就是比较和分析获得的数据，搞清楚每一个数据指标对系统性能的影响。如果要简略一点，这些数据可以用简单的折线图来表示，每次显示出一组或者多组数据，但大多数商业软件都提供了很强大的表现能力——包括用图形的方式来描述树形的调用路径，有的还有缩放功能。一些商业软件还能够显示出对比不同指标的运行时数据视图，有时可以当作指示性能问题的专用指示器。

    结束语：在考虑优化性能的方法时，通常下列三个步骤是必不可少的：第一，用典型的最终用户事务，对应用进行负载测试；第二，从应用服务器和应用获得运行时性能数据；第三，分析性能数据，在此基础上调整相关的性能选项。

    优化J2EE环境是一个需要反复进行的过程：第一次只能从一个看起来似乎不错的配置开始，然后测试、分析系统，再根据测试结果调整、配置系统，如此才能让应用的性能表现一直处于非常好的状态。

    在下一篇文章中，我们将分析应用服务器的一般体系结构，回答下列问题：当一个J2EE应用服务器声称自己遵从J2EE 1.3规范时，它应该提供哪些功能？它们各涉及哪些可调整的性能因素？

    九、附录：工具软件

    许多集成开发环境带有完善的测试和监视、诊断工具，但下面只列出一些专用产品。

    负载测试工具：

    ◆LoadRunner，由Mercury Interactive公司开发，属于非常受欢迎的产品/产品较受欢迎之一。

    ◆Benchmark Factory，由Quest Software公司开发。

    ◆The Grinder，源代码开放产品。

    监视工具/诊断工具：

    ◆PerformaSure，由Quest Software开发。

    ◆Interscope，由Wily开发

    ◆Indepth，由Precise开发。