性能测试及性能调优概述(2)

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

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

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

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

　　配置

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

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

　　测试

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

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

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

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

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

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

　　测试时务必要：

　　检查用于测试的应用程序的正确性和性能，查找内存泄漏和不正常的客户端请求响应延迟。

　　确保所有测试都正常进行。

　　确保可以使用相同的事务混合和相同的客户端生成相同的负载来重复所有测试。

　　文档更改和结果。

　　在每遍测试中，运行一系列完全相同的性能测试;否则，无法分辨不同的结果是由于测试中的改动还是应用程序更改造成的。使尽可能多的性能测试操作自动进行有助于消除因操作者造成的差异。

　　其他表面上是良性的因素影响性能测试的结果，如应用程序在测试开始前运行的时间。正如冷的汽车引擎与热引擎的性能不同，长时间运行的应用程序由于内存碎片这样的因素，其性能可能与刚启动的应用程序不同。

　　定义性能测试

　　性能测试期间，测量和记录性能目标中指定的度量标准值。达到全部性能度量标准(如思考时间、事务混合等)很重要。在这些约束下，测试应尽可能实际。例如，对应用程序进行测试，确定它在许多客户端同时访问它时的性能。多线程测试应用程序可以用可复制的方式模拟多个客户端，每个线程表示一个客户端。如果应用程序访问数据库，则数据库应包含实际数目的记录，并且测试应使用数据项的随机(但有效)值。如果测试数据库太小，数据库服务器的缓存效果将产生不符合实际情况的测试结果。如果输入或访问数据的方式不符合实际情况，则结果也可能不符合实际情况。例如，在主键上按字母顺序创建新数据是不太可能的。

　　通常，测试装置必须接受用户指定的输入参数，如事务混合、思考时间、客户端数目等。然而，测试装置本身可以规定创建实际的随机数据的规则。

　　创建了驱动应用程序的测试装置后，应该将所有运行测试的不变条件记入文档。最起码，这些条件应包括运行测试装置所需的输入参数。另外，应将如何设置运行测试的数据库记入文档。说明中应指定数据库不应包含前一遍测试所做的更改。说明中还应指定用于测试的计算机配置。在不同于应用程序所在的另一台计算机上运行测试装置，因为这样设置更接近生产环境。

　　确定基准性能

　　确定了性能目标并制定了性能测试后，运行一次测试以建立基准。验证环境与生产环境越相似，应用程序部署后的性能令人满意的可能性就越大。因此，一开始有一个符合实际情况的验证环境很重要。

　　幸运的话，基准性能将符合性能目标，并且应用程序不需要任何调整。但更可能的情况是，基准性能不令人满意。然而，记录初始测试环境和基准结果可以为调整工作提供坚实的基础。

原文转自：http://www.uml.org.cn/Test/200512261.htm