记录并评估结果

　　基于以上规划推荐的各种测试的执行涉及对应的保留记录的活动。只有记录了数据才能进行分析。保留记录是性能测试活动中重要的最后一步。

表 1. 样本电子表格收集了基于规划推荐的某次运行的结果。

日期／时间 2002 年 8 月 6 日 — 12:03:54
用户的数量 100
测试的持续时间（分钟） 10
  Web 服务器的设置 
MaxClients 600
TTL（每个进程的请求数的总和） 10,000
WebSphere Application Server 的设置 
JVM 堆大小的最小值 256
JVM 堆大小的最大值 512
生成的垃圾收集 关于 -XX 设置
servlet 引擎线程池大小的最小值 10
servlet 引擎线程池大小的最大值 200
ORB 线程池大小的最小值 10
ORB 线程池大小的最大值 200
Web 服务器的测量值 
CPU 的利用率（在最大时测量） 40-45 %
平均的吞吐量 0.45 秒
每秒的请求数 44.85
负载客户机的测量值 
每秒的请求数 44.85
请求数的总和 7,348
成功完成的请求数 7,342
超时的请求数 4
连接失败的请求数 2
第 1 个页面的响应时间 0.35 秒
第 2 个页面的响应时间 0.54 秒
第 3 个页面的响应时间 1.33 秒
WebSphere Application Server 的测量值 
servlet 的响应时间 0.28 秒
垃圾收集周期的数量 2
CPU 的利用率（在最大时测量） 33%
JDBC 每秒请求数 -- 查询 125
JDBC 的响应时间 -- 查询 37 ms
JDBC 每秒请求数 -- 插入 35
JDBC 的响应时间 -- 插入 125 ms
JDBC 每秒请求数 -- 更新 98
JDBC 的响应时间 -- 更新 222 ms

　　基于本文中给出的规划推荐的一组测试的结果与表 1 中列出的数据类似，其中记录了配置的各种元素和测得的结果。对于每个个别的测试系列，您都需要这样做。一组收集到的数据依赖于被应用程序所利用的后端资源。不直接访问 JDBC 资源的应用程序显然不会收集 JDBC 时间开销数据。您应该针对后端资源来收集基本的时间开销和频率数据。

　　一旦结果被收集并编译后，它们可被生成各种图表以说明应用程序的性能。结果的收集和编译可能涉及一些对数据的手工处理，因为没有一个工具能够收集所有所需的数据。

图 6. 按用户数量来显示完成的请求数
 

图 7. 按页面和用户数量来显示响应时间

　　图 6 和图 7 显示了在把测试结果合并成一个电子表格后可被创建的两个可能的图表。在图形格式中，结果可以一对一地被并排放置以使其他人能够分析结果。您应该提供说明任何测量到的或观察到的异常的文本，当性能结果显著提高或下降时，您更应该这样做。

（别忘了手工维护的电子表格或数据库中可能存在人犯下的错误。为了找出可能的错误或错误的表示，您应该在数据被记录后审阅一下数据。）

　　数据的分析涉及找出应用程序的以下特征以确定各种最佳值：

servlet 响应时间和客户机响应时间
网络的带宽
应用程序服务器和 Web 服务器的 CPU 的利用率
后端资源的利用率
网络组件的利用率

　　一旦确定了最佳设置，您必须考虑应用程序是应该在自己的应用程序服务器上运行还是与其他应用程序一起在应用程序服务器上运行。您还必须考虑在相同的物理机器上运行的应用程序服务器的数量，因为很可能有物理资源的限制。最后，对于群集的环境，您不仅必须评估应用程序服务器机器上的物理限制，还必须评估被应用程序所利用的后端资源。所有这些因素将适用于生产环境的性能和容量规划阶段从而达到最佳性能。

性能测试的频繁程度

　　一个常见的误解是性能测试是一次性的工作。如果您从不更改应用程序代码或机器配置，那么性能测试是一次性的工作。然而，经常出现的情况是应用程序代码被更改或更好的机器配置被用于生产环境或这两种情况都发生了。因此，每当应用程序代码或机器配置被更改时，您必须再次执行性能测试以确定可达到最佳性能的新参数。

结束语

　　性能测试规划是定义、理解和执行的全面组合。在开发周期中尽早地、尽可能多地测试是在把应用程序发布到生产环境前确定性能问题的最佳方式。专门负责性能测试的小组可提供一致的测试并使个别的开发小组不必再肩负性能测试的责任。一般来说，使您深入了解 JVM 和应用程序特征的工具是物有所值的，因为它们使您快速确定问题并使性能测试活动尽可能的快速和高效。