历史归档

        随着测试的进行，取得的测量结果应该与以前的运行结果相比较以确定性能是提高了还是下降了。应用程序监视工具通常可以用一种格式或另一种格式来保存被收集的数据。更高端的工具甚至可以把结果直接集成到数据库或其他数据存储库。如果您使用的工具不提供用可用的格式来保存数据的方法，那么您可以把相关的数据保存在简单的电子表格中。

程序的时间开销

        应用程序开发小组倾向于通过某种记录机制把性能时间开销测量构建到他们的应用程序中。在应用程序中记录性能测量结果的作法应被尽力劝阻，因为这将在应用程序中加入更多代码，这些代码不仅消耗处理周期，还必须被维护和测试。最终，固定在应用程序上并可由一个命令来控制的外部应用程序监视工具的效率更高。

监视 JVM

        为了更好地理解 JVM 是如何运行的，您需要在性能测试活动中监视 JVM 的几个重要的地方。一些需要观察的基本参数包括：

        活动的 servlet 引擎线程的个数：这使您能够理解 JVM 中的应用程序在任一时刻可以提供的最大工作量。它也有助于确定用于生产环境的所需的最大设置。 
        活动的 ORB 线程的个数：用于有 EJB 的应用程序。 
        可用的和用去的内存：有助于理解应用程序是如何利用内存的和垃圾收集周期的执行频率。 
        servlet 响应时间：有助于比较应用程序服务器上观察到的响应时间与负载测试客户机上测得的响应时间之间的异同。通过防火墙和其他网络组件的瓶颈可能带来被记录 servlet 响应时间所证实的延迟。

监视应用程序

        应用程序监视是特定于每个应用程序的。您应该考虑监视访问后端资源的重要方法。为了理解序列化／反序列化对象的方法对性能的影响，您必须观察这些方法。

        调用的频率和方法执行的持续时间是两个应该被获取的性能数字。频率需被监视以确定在不同的性能运行期间方法被调用的次数。方法执行的时间开销使您深入了解在某些任务上花费的响应时间的占全部响应时间的百分比，也有助于指出应用程序的瓶颈。开发者可以把这些信息用于进一步的代码重构以提高应用程序的性能。

监视后端资源

        性能测试期间的后端资源的监视是性能测试活动的至关重要的部分。任何应用程序的性能与环境中最慢的链路一样快。如果后端资源没有提供足够级别的性能，那么访问后端资源的应用程序也不在最佳的级别运行。后端资源的性能下降的原因可能有很多。您需要让每个特定资源的管理员使用正确的工具集和知识以帮助解决这种有关后端的任何问题。

监视网络资源

        网络连接的应用程序环境的常见链路是网络本身。参与测试活动的网络资源也必须被监视，它们的数据必须被分析以确保最大的吞吐量和效率。这包括整个网络（包括参与测试的任何防火墙、路由器、CSS 交换机、负载平衡器、反向代理等）。您必须首先解决由于错误配置防火墙、反向代理或其他网络设备所造成的任何性能问题，否则，被收集的数据总是不准确和／或不一致。

需检查的常见网络配置包括：

        被设置为半双工而不是全双工的吞吐量。 
        在往返于相同的一组设备时使用不同跳点的路由。 
        安装的用于代理而不是通行的防火墙。

应被监视的网络资源：

CPU（如果适用的话）。
处于“建立”状态的端口。
连接的吞吐量时间开销。
带宽。
设置性能期望

        在性能测试开始前就从几个不同的角度设置期望对于确保测试结果是有价值的且测试活动本身是成功的有很重要的意义。这些期望包括测试小组需要哪些不同的输入和哪些输出将定义合理的应用程序性能。如果您没有提前设置，那么您很难定义被测试的应用程序的性能是否是足够的好。

        同样，您必须设置性能测试活动的预期的持续时间。由于测试和被修改的参数的数量较多，性能测试需花去很长时间才能完成。提前安排适量的测试时间将使每个人受益。

应用程序的期望

        为了确定应用程序的性能是否是足够的好，您必须定义性能期望。列出以下期望应该是任何测试计划的第一部分：

可接受的 servlet 响应时间。
可接受的负载客户机响应时间。由于网络开销、通过 Web 服务器和防火墙的额外跳点等，它不同于 servlet 响应时间。
可接受的每秒请求的吞吐量。
可接受的后端资源响应时间。
可接受的每秒后端请求的吞吐量。
可接受的网络开销（包括 Web 服务器、防火墙、反向代理、负载平衡器、CSS 等）。

        同样，如果测试结果没有满足可接受的结果标准，那么您必须制定处理任何缺点的计划。缓解应用程序中的性能瓶颈的基本策略有两条：

扔掉更多有问题的硬件，这可能很贵。
排除应用程序瓶颈，这可能很费时。

        虽然预算限制常常是决定中的一个因素，但是根据具体问题，两种策略可能都是正确的和可行的。任一个解决方案都不便宜，但是，一般来说，排除应用程序瓶颈是更好的策略，故您应尽可能采用它。解决应用程序中的性能问题还将导致某种类型的事后分析过程（即记录并传播从这些任务中学到的知识）。

性能测试活动的总共持续时间

        不幸的是人们常常在开发周期的结束前（把应用程序转移到生产环境前）安排几周的性能测试。这种思想的问题是直到给应用程序施加负载时许多应用程序问题才会暴露出来，而且只有在性能测试阶段中应用程序才被施加生产环境的预期的负载量。

        即使应用程序的问题很少，开发周期的性能测试阶段可能需要几个月才能完成，这取决于应用程序、环境和许多可变的因素。有更多问题和错误的应用程序将花去多得多的时间。这是我强烈建议您尽早在性能测试环境中测试的一个原因。在开发周期中越早开始测试，您就能越早地检测到应用程序问题并正确地处理它。如果您等到开发周期快结束时才开始负载测试，那么您很可能遇到最坏的性能测试情景。

应用程序的接受标准

        在任何认真的软件开发活动后，在性能测试活动开始前，应用程序必须达到性能测试接受标准。如果应用程序没有达到这些标准，那么它不应该被性能测试环境所接受：

        单元测试能力。所有应用程序开发工作必须提供全面的单元测试策略和附带的可被执行的单元测试代码以确定构建是完整的和有效的。如果单元测试案例因为应用程序中的错误或缺少单元测试代码而无法被成功完成，那么应用程序不应该被性能测试所接受。 
        低负载级别能力。在单用户和 10 个用户负载级别上应用程序应该用去正常的计算时间来达到合理的性能和预先定义的期望。如果应用程序无法在低负载级别正常运行，那么它肯定无法在更高负载级别正常运行。开始性能测试将会浪费时间。 
        可用的测试数据。在性能测试期间执行应用程序所需的数据必须被提供或被详细描述以使性能测试小组能够建立与生产环境尽可能接近的副本。测试数据必须是真实的、一致的和完整的。

应用程序在以预期的行为通过性能测试前绝不能被用于生产环境。