测试规划

        当性能测试环境被建立且在最佳状态运行时，下一步是制定测量被测试的应用程序的性能和特征的详细的测试计划。下面提供的信息可被用作应完成的任务和应进行的测量的清单。许多规划推荐还将指导您如何完成容量计划步骤，这些步骤能使您了解必须定义多少 JVM 才能处理生产中全部的预期的用户负载。

个别测试的持续时间

        一般来说，对于个别测试，您应该只在最大负载级别上运行下面描述的个别测试和配置点，运行时间最多为 10 至 30 分钟。第一组测试运行应严格被用于在各种配置点和负载级别上收集数据。在分析了结果并确定了应用程序定义的预期的最佳配置点后，您就可以执行更长时间的测试（持续时间为 12 小时或更长）以测量长期运行的应用程序的特征。更长时间的测试还提供在指定的负载下功能和稳定性测试。

单个 JVM 和多个 JVM 的测量

        性能测试有两个基本设置：单个 JVM 和多个 JVM。单个 JVM 测试在单独运行时可说明基本的应用程序性能。一些测量值（例如每秒响应的数量、servlet 响应时间和后端访问的数量）可提供预期的最大吞吐量。这些都是最大值，因为群集的环境的性能可能因后端资源的限制而难以超过单个应用程序的性能。群集的环境提供可伸缩性和故障转移。在极少数情况下，在多个 JVM 配置中可能出现在单个 JVM 配置中不可能出现的应用程序问题。

推荐：在所有的测试中，您必须既使用单个 JVM 配置，也使用群集的多个 JVM 配置。

JVM 堆大小设置

        您可以使用一组从最小到最大的值来调整 JVM 堆大小设置直到找到最佳设置。servlet 引擎线程数量设置将在某种程度上决定最佳设置，这是因为每个堆栈都使用 JVM 中的内存。

        推荐：通过合理地增加 JVM 堆大小设置来对它进行调整以确定应用程序的最佳内存设置。请确保 JVM 堆大小设置与同一台服务器上的任何其他应用程序不超出机器的物理内存的限制。请记住基本的操作系统也有必须被考虑的内存要求，在所有的操作系统环境中，内存交换会对应用程序性能产生负面影响。

生成的垃圾收集

        针对所有操作系统平台的生成的垃圾收集（generational garbage collection）概念在 JVM V1.3 中被引入。一般来说，启用生成的垃圾收集将使积极创建许多临时对象并运行有大量用户的大容量应用程序受益。然而，可能是这种情况，也可能不是，这取决于应用程序是如何使用对象的。

        请注意在性能测试期间出现的主要的垃圾收集周期的数量并理解在这些周期中对应用程序的性能含义。将导致更小的 JVM 大小的物理内存的限制常常使您看到在负载下更高的收集率。理解这里的性能影响对于在生产环境中避免意外有重要意义。与流行的看法相反，垃圾收集不会导致应用程序服务器丢失请求。

        推荐：对于每一组 JVM 堆大小设置，请在一次测试的运行中启用垃圾收集，在另一次中禁用它。请您花足够的时间来运行这些测试以确保至少执行几个垃圾收集周期从而可以测量应用程序的行为。请通过观察 JVM 如何利用可用内存和用去的内存来监视垃圾收集周期。

servlet 引擎线程池

        servlet 引擎线程池的大小决定了包含 Web 应用程序的 JVM 一次可执行的工作量。在 WebSphere Application Server V4.0 和更新的版本中，线程池定义了反映池大小的限制的最小值和最大值。一般来说，大容量的应用程序有较大的线程池大小，但是有些因素（例如应用程序瓶颈、synchronized 关键字的使用和／或代码中的其他限制）将阻碍大线程池的高效利用。

        利用 servlet 引擎线程池的应用程序往往是使用 servlet 和 JSP 的应用程序。这也包括基于 SOAP 的应用程序。直接与 EJB 交谈的应用程序客户机不使用 servlet 线程，但的确使用 ORB 线程（请看下一部分）。

        推荐：请用不同的最小和最大线程池大小来测试应用程序以确定哪些设置使应用程序完成尽可能多的工作。一般来说，为了使线程池的大小更大，您可以上调 JVM 堆大小设置，但在开始测试时请使用最小内存设置。请监视应用程序对 CPU 的利用率。一旦应用程序对 CPU 的利用率接近 80%，您将遇到 CPU 的极限，因为必须为基本的操作系统本身保留周期。

        别忘了 servlet 引擎线程池的大小直接影响 Web 服务器上的 MaxClient 设置。请确保 Web 服务器有足够已定义的侦听器以避免在负载测试客户机端出现“连接失败”错误。如果确实出现了“连接失败”错误，那么 Web 服务器的侦听器的最大数量设置太低了，您必须增加它。

ORB 线程池的大小

        运行于容器中的 EJB 在被分配到 ORB 线程池的线程中执行。与 EJB 通信的应用程序（这些应用程序基于远程方法调用（Remote Method Invocation，RMI）和 servlet）必须使 ORB 线程池的大小被配置。

推荐：请调整 ORB 线程池的大小。请监视线程池和 EJB 活动／响应时间以确定最佳的线程池的大小。

连接池

        使用有连接池的 JDBC 资源的应用程序需要设置连接池的大小。广泛接受的实践把池中的最大连接数限制在 30-40 左右。太多的连接（连接数超过 40）不会给您带来什么好处，您应该记住每个被建立的连接消耗内存和网络资源。

        会话持久数据源一般只需把最大值定义为 10 个连接。绝不要使最大的连接池大小大于 servlet 引擎线程的数量。

推荐：请调整连接池的最大值和最小值。请监视 servlet 响应时间和吞吐量（请求／秒）、JDBC 活动和内存的利用情况以达到最佳性能。

用户

        您需要知道准确代表生产中应用程序的行为的性能测试活动的用户类型和数量，这一点很重要。不同的组织用不同的方法来测量用户与预期的负载之间的相关性。有些组织通过每秒 CICS 事务的数量（而不是用户的数量）来测量利用率。为了使用户负载与正确的尺度相关，您需要理解应用程序是如何利用后端资源的，这实际上是一道数学练习题。无论负载是如何被测量的，大家对最后的结果和它们表示的含义都应该有一个共同的理解。

用户的数量

        用户的数量定义了应用程序所受的某个负载。因为每个应用程序很可能有不同类型的用户（例如浏览目录的用户与买东西的购物者），所以您必须使用各种情景（全部这些情景类似于平均的、预期的工作负载）来测试应用程序。

        有些应用程序在高用户负载时的性能好于其他应用程序。有瓶颈问题或过多的同步的应用程序常常表现为较长的响应时间和较低的 CPU 利用率。

        单用户负载测试常常被用来建立应用程序基线性能。前面已讲过，如果应用程序在单用户负载级别上表现不佳或崩溃，那么继续在更高负载级别上进行应用程序的性能测试是没用的。同样，如果应用程序在 10 个用户级别上表现不佳，那么我建议您终止测试。

        一旦应用程序服务器上的 CPU 利用率接近并达到 100% 分，用户数量的增加只会导致更长的响应时间。这应该被测量和记录，因为它明确定义了应用程序的限制。这也有助于容量规划和确定群集环境中所需的应用程序克隆的数量以支持预期的负载。

用户的类型

        一个应用程序常常有几个类型的用户。例如，一个卖东西的 Web 站点至少有两种类型的用户：浏览者和购物者。一种类型的用户与该站点交互但什么也不买。另一种用户执行额外的功能（例如购物和信用卡验证）。并不是所有的用户都是购物者，但所有的用户至少都是浏览者。定义参与测试的用户类型是理解站点的性能的关键。如果您预先更多地了解使用站点的各种用户，那么您所进行的性能测试将更为逼真。同样，理解常被使用的页面的流动也是有益的。这就要求负载测试脚本的开发者理解应用程序、用户类型和这些用户的正常行为。

        推荐：请使用前面的所有规划推荐在以下用户负载级别上测试应用程序：1，10，100，500，800，1500 等（是否合适取决于现实的负载预期）。请监视应用程序的响应时间、吞吐量（请求／秒）、CPU 利用率、JVM 内存利用率、线程利用率和 JDBC 后端利用率。

CPU 的利用率

        为了理解应用的负载对被测试的应用程序的影响，您需要记录应用程序服务器机器的 CPU 的利用率。服务器的目的在于使它达到可能的最高的 CPU 利用率。如果昂贵的服务器在运行时 CPU 的利用率仅为 20%，那么它的性价比不高。在分布式环境中，CPU 的利用率必须在预期的最大负载、硬件故障和已定义的服务质量要求之间平衡。

图 5. CPU 和响应时间
 

        图 5 中的图表用蓝色显示了 CPU 的利用率，用红色显示了响应时间。一旦对 CPU 的利用达到饱和，增加的负载只会增加响应时间。您必须比较测量值与预先定义的应用程序期望以确定在哪些负载级别上可接受的响应时间才是可能的。如果应用程序有瓶颈或其他问题，这个级别对应的 CPU 利用率可能明显更低。

请测量应用程序使服务器达到饱和状态时用户负载的级别并记录它。这些数字对容量规划演习有用。