性能测试及性能调整概述

　　明确了具体的性能要求后，可以开始进行测试，确定应用程序是否满足这些要求。性能测试假定应用程序稳定、可靠地运行。因此，在测试中消除尽可能多的变数很重要。例如，代码中的错误可以导致出现性能问题，甚至掩盖性能问题。要精确地比较不同性能测试的结果，应用程序必须正确地工作。如果调整过程修改了组件的实现，则重新测试应用程序的功能尤其重要。应用程序必须通过功能性测试后才可以测试性能。除了应用程序更改外，硬件、网络通信量、软件配置、系统服务等诸多方面也会发生意外的更改。控制应用程序更改很重要。

　　测量性能

　　要正确地调整性能，必须准确完整地记录每次测试的结果并进行维护。记录应包括：

　　精确的系统配置，尤其是与前几次测试的不同之处

　　原始数据和性能监视工具计算的结果

　　这些记录不仅指示应用程序是否达到性能目标，而且有助于识别未来性能问题的潜在原因。

　　性能调整是与性能管理相关的主要活动。当性能降到最基本的水平时，性能调整由查找和消除瓶颈组成，瓶颈是在服务器中的某个硬件或软件接近其容量限制时发生和显示出来的情况。

　　在开始性能调整循环之前，必须做一些准备工作，为正在进行的性能调整活动建立框架。您应该：

　　识别约束 - 站点的业务实例确定优先级，而优先级又设立边界。约束(如可维护性和预算限制)在寻求更高的性能方面是不可改变的因素。必须将寻求性能提高的努力集中在不受约束的因素上。

　　指定负载 - 这涉及确定站点的客户端需要哪些服务，以及对这些服务的需求程度。用于指定负载的最常用度量标准是客户端数目、客户端思考时间以及负载分布状况;其中客户端思考时间是指客户端接收到答复到后面提交新请求之间的时间量，负载分布状况包括稳定或波动负载、平均负载和峰值负载。

　　设置性能目标 - 性能目标必须明确，包括识别用于调整的度量标准及其对应的基准值。总的系统吞吐量和响应时间是用于测量性能的两个常用度量标准。识别性能度量标准后，必须为每个度量标准建立可计量的基准值与合理的基准值。

　　注意 由于性能和容量的关系如此密切，因此您识别的约束、负载和目标也适用于容量规划。

　　建立了性能调整的边界和期望值后，可以开始调整循环，这是一系列重复的受控性能试验。

　　调整循环

　　重复以下所示的四个调整循环阶段，直到获得在开始调整过程前建立的性能目标。

　　调整循环

　　收集

　　收集阶段是任何调整操作的起点。在此阶段，只是使用为系统特定部分选择的性能计数器集合来收集数据。这些计数器可用于网络、服务器或后端数据库。

　　不论调整的是系统的哪一部分，都需要根据基准测量来比较性能改变。需要建立系统空闲以及系统执行特定任务时的系统行为模式。因此，可以使用第一遍数据收集来建立系统行为值的基准集。基准建立在系统的行为令人满意时应该看到的典型计数器值。

　　注意 基准性能是一个主观的标准：必须设置适合于工作环境且能最好地反映系统工作负荷和服务需求的基准。

　　分析

　　收集了调整选定系统部分所需的性能数据后，需要对这些数据进行分析以确定瓶颈。记住，性能数字仅具有指示性，它并不一定就可以确定实际的瓶颈在哪里，因为一个性能问题可能由多个原因所致。某个系统组件的问题是由另一系统组件的问题导致的，这种情况也很普遍。内存不足是这种情况的最好示例，它表现为磁盘和处理器使用的增加。

　　以下几点来自“Microsoft Windows 2000 资源工具包”，提供了解释计数器值和消除可能导致设置不适当的调整目标值的错误数据或误导数据的指南。

　　监视名称相同的进程 — 监视某个实例而没有监视另一个实例的异乎寻常大的值。有时，系统监视器将多个实例的组合值报告为单个实例的值，这就错误地报告了同名进程的不同实例的数据。可通过按进程标识符对进程进行跟踪来解决此问题。

　　监视多个线程 - 当监视多个线程而其中一个线程停止时，一个线程的数据可能似乎被报告成了另一个线程的数据。这是由于线程的编号方式所导致的。可通过将进程线程的线程标识符包含在日志或显示中来解决此问题。为此，请使用“线程/线程 ID”计数器。

　　数据值中的不连续峰值 - 不必太重视数据中偶尔的峰值。这些峰值可能是由于进程的启动，并不是该进程随时间改变的计数器值的准确反映。尤其是平均计数器可以导致峰值随时间停留的效果。

　　监视一段延长的时期 - 建议使用图形代替报告或直方图，因为后两种视图仅显示最后的值和平均值。结果，当查找峰值时，可能得不到这些值的准确反映。

　　排除启动事件 - 除非有特殊的原因需要将启动事件包含在数据中，否则排除这些事件，因为它们产生的临时性高峰值往往歪曲了整体性能结果。

　　零值或缺少的数据 - 调查所有出现的零值或缺少的数据。这些零值或缺少的数据会妨碍建立有意义的基准。

　　配置

　　收集了数据并完成结果分析后，可以确定系统的哪部分最适合进行配置更改，然后实现此更改。

　　实现更改的最重要规则是：一次仅实现一个配置更改。看起来与单个组件相关的问题可能是由涉及多个组件的瓶颈导致的。因此，分别处理每个问题很重要。如果同时进行多个更改，将不可能准确地评定每次更改的影响。

　　测试

　　实现了配置更改后，必须完成适当级别的测试，确定更改对调整的系统所产生的影响。在这一点上，这是确定更改是否有如下影响的问题：

　　性能提高 - 更改提高了性能吗?如果是，提高了多少?

　　性能下降 - 更改在其他位置导致了瓶颈吗?

　　对性能没有影响 - 更改对性能到底有何显著的影响?

　　如果幸运，性能提高到预期的水平，这时便可以退出。如果不是这样，则必须重新逐步进行调整循环。

　　提示 可以从监视日志文件(可导出到 Microsoft Excel)和事件日志中获取测试所产生的监视结果。

原文转自：http://www.ltesting.net