J2EE运行环境性能优化艺术之二  

　　
　　作者：Steven Haines；编译：仙人掌工作室
　　
　　前面一篇文章指出了性能优化的目的是提高应用支持的并发用户数量以及吞吐量、可靠性，优化的手段则应当是从应用、应用服务器、平台、外部依赖因素入手作系统地调整。无论是优化J2EE应用还是数据库、自定义的体系结构，最好的方法是先确定要采用的优化策略、分析该策略是否能够解决性能问题、确定实施该策略所需满足的前提条件。
　　
　　一、优化方法
　　
　　虽然我也希望能够告诉你：优化J2EE环境很简单，只需要把某几个参数调整到特定的值，一个小小的表格就足以把这些值全部列出。遗憾的是，实际问题要复杂得多，优化J2EE性能不仅要深入理解应用本身，而且还要掌握用户使用该应用的方式。下图展示了完整的优化过程。
　　
　　
　　
　　图2-1：调整性能因素的方法概览
　　
　　第一个必须考虑的因素就是用户，我们必须先回答下列问题：用户会怎样使用这个系统？根据问题的答案可以定义出一组要求系统执行的事务（在这里，“事务”这个概念是指用户发出的一系列请求）。注意这些事务必须能够典型地代表最终用户的操作行为，因为我们将根据这些事务的执行情况来调整系统！
　　
　　接下来，我们要在负载测试工具之内生成这些事务。负载测试工具能够控制并发用户数量、考虑时间、启动延迟等因素。
　　
　　模拟大量用户的操作方式对应用进行测试时，应当获取应用本身、应用服务器、底层平台、外部资源的运行时性能指数。最后，有了这些性能指数之后，还必须对这些数据进行对比、分析和解释。
　　
　　二、应用
　　
　　每一个应用都是不同的：响应用户请求的服务步骤不同，与后端资源的交互方式不同，业务需求也不同。例如，考虑一个合作伙伴通过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开发。