五、负载测试
负载测试工具是一种能够模拟任意数量的用户与系统交互过程的工具，当前市场上已经有许多这类工具（参见本文后面的目录），虽然这些产品各有特色，但它们的核心功能不外乎：
◆ 能够针对应用系统执行用户定义的事务，保证适当的事务频度。
◆能够控制负载测试中并发用户的数量。
◆能够精确调整测试器在下列各方面的行为：两个请求之间用户的思考时间，上升到目标用户数量的速率。
大多数商业负载测试器还提供了一个“学习”引擎，它允许测试者手工执行事务，而学习引擎则在后台观察和记录测试者的动作。
总之，负载测试工具的目的是模拟实际运行环境中用户的操作方式。如果不能为应用定义一组典型的测试事务，就不能将应用精确地调整到最适合实际用户的状态。
六、需要哪些信息？
现在，我们已经有了模拟一系列并发用户的负载测试工具，每一个并发用户都能够运行典型地代表了应用使用情况的事务。接下来要做的是从应用和应用服务器获取运行时性能信息，包括：
◆应用服务器统计信息：内存使用情况，数据库连接使用情况，线程使用情况，等等。
◆应用性能（内部）：类和方法的响应时间，调用路径，异常方法，等等。
◆应用性能（外部）：负载测试器观察到的事务总量、构成事务的请求量。
◆平台性能：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开发。
