明确了具体的性能要求后,可以开始进行测试,确定应用程序是否满足这些要求。性能测试假定应用程序稳定、可靠地运行。因此,在测试中消除尽可能多的变数很重要。例如,代码中的错误可以导致出现性能问题,甚至掩盖性能问题。要精确地比较不同性能测试的结果,应用程序必须正确地工作。如果调整过程修改了组件的实现,则重新测试应用程序的功能尤其重要。应用程序必须通过功能性测试后才可以测试性能。除了应用程序更改外,硬件、网络通信量、软件配置、系统服务等诸多方面也会发生意外的更改。控制应用程序更改很重要。
测量性能
要正确地调整性能,必须准确完整地记录每次测试的结果并进行维护。记录应包括:
精确的系统配置,尤其是与前几次测试的不同之处
原始数据和性能监视工具计算的结果
这些记录不仅指示应用程序是否达到性能目标,而且有助于识别未来性能问题的潜在原因。
性能调整是与性能管理相关的主要活动。当性能降到最基本的水平时,性能调整由查找和消除瓶颈组成,瓶颈是在服务器中的某个硬件或软件接近其容量限制时发生和显示出来的情况。
在开始性能调整循环之前,必须做一些准备工作,为正在进行的性能调整活动建立框架。您应该:
识别约束 - 站点的业务实例确定优先级,而优先级又设立边界。约束(如可维护性和预算限制)在寻求更高的性能方面是不可改变的因素。必须将寻求性能提高的努力集中在不受约束的因素上。
指定负载 - 这涉及确定站点的客户端需要哪些服务,以及对这些服务的需求程度。用于指定负载的最常用度量标准是客户端数目、客户端思考时间以及负载分布状况;其中客户端思考时间是指客户端接收到答复到后面提交新请求之间的时间量,负载分布状况包括稳定或波动负载、平均负载和峰值负载。
设置性能目标 - 性能目标必须明确,包括识别用于调整的度量标准及其对应的基准值。总的系统吞吐量和响应时间是用于测量性能的两个常用度量标准。识别性能度量标准后,必须为每个度量标准建立可计量的基准值与合理的基准值。
注意 由于性能和容量的关系如此密切,因此您识别的约束、负载和目标也适用于容量规划。
建立了性能调整的边界和期望值后,可以开始调整循环,这是一系列重复的受控性能试验。
调整循环
重复以下所示的四个调整循环阶段,直到获得在开始调整过程前建立的性能目标。
调整循环
收集
收集阶段是任何调整操作的起点。在此阶段,只是使用为系统特定部分选择的性能计数器集合来收集数据。这些计数器可用于网络、服务器或后端数据库。
不论调整的是系统的哪一部分,都需要根据基准测量来比较性能改变。需要建立系统空闲以及系统执行特定任务时的系统行为模式。因此,可以使用第一遍数据收集来建立系统行为值的基准集。基准建立在系统的行为令人满意时应该看到的典型计数器值。
注意 基准性能是一个主观的标准:必须设置适合于工作环境且能最好地反映系统工作负荷和服务需求的基准。
分析
收集了调整选定系统部分所需的性能数据后,需要对这些数据进行分析以确定瓶颈。记住,性能数字仅具有指示性,它并不一定就可以确定实际的瓶颈在哪里,因为一个性能问题可能由多个原因所致。某个系统组件的问题是由另一系统组件的问题导致的,这种情况也很普遍。内存不足是这种情况的最好示例,它表现为磁盘和处理器使用的增加。
以下几点来自“Microsoft Windows 2000 资源工具包”,提供了解释计数器值和消除可能导致设置不适当的调整目标值的错误数据或误导数据的指南。
监视名称相同的进程 — 监视某个实例而没有监视另一个实例的异乎寻常大的值。有时,系统监视器将多个实例的组合值报告为单个实例的值,这就错误地报告了同名进程的不同实例的数据。可通过按进程标识符对进程进行跟踪来解决此问题。
监视多个线程 - 当监视多个线程而其中一个线程停止时,一个线程的数据可能似乎被报告成了另一个线程的数据。这是由于线程的编号方式所导致的。可通过将进程线程的线程标识符包含在日志或显示中来解决此问题。为此,请使用“线程/线程 ID”计数器。
原文转自:http://www.uml.org.cn/Test/200512261.htm