4.3　根本原因分析

那么我们要寻找，以确定我们应用程序的表现如何?通过每次性能测试都为我们提供了一定数量的KPI，可以帮助我们找到答案。

提示

在进行分析之前，你可能首先需要调整测试数据的时间范围，去掉加载和退出的时间，以确保测试结果的准确性。这也适用于那些在加载过程中使用逐步加压负载生成策略的测试。如果每个加载步骤都是同时加载一组虚拟用户（如每15分钟加载25个用户），则可能会在负载生成点之后突然出现一段人为的瞬间压力，从而影响您的测试数据（如图4-10）。在较长时间的测试之后，通过这种调整也可以减少一些数据，减少数据点将使分析变得容易。绝大多数自动化性能测试工具都提供调整数据范围的功能。

4.3.1　可扩展性和响应时间

良好的可扩展性和响应时间的模型就是随着虚拟用户和事务吞吐量的增加，平均响应时间平稳增长，但增长值处在可接受的范围内。而扩展性不佳的应用程序则有着完全不同的表现：伴随着虚拟用户负载的增加，响应时间随之增加，而且增加趋势不平稳，或者变得不稳定，标准方差远高于平均值。

图4-13展示了良好的可扩展性。图中代表平均事务响应时间的曲线在测试执行中持续增长，但是在达到最大并发用户数时，响应时间逐渐趋于平稳。假如最后响应时间仍处在你的性能测试目标内，那么这将是一个很好的结果。（由于测试执行的终止，在测试结束时响应时间会有一个突然的增长，这并不意味着应用程序突然出现问题）

图　4-13　良好的可扩展性/响应时间模型

图4-14和图4-15演示了不良的响应时间行为。在图4-14中，代表平均事务响应时间的曲线都紧随着代表活动虚拟用户数的那条曲线，一直持续到活动用户数约达到750时。从这一点开始，响应时间开始变得不稳定，这就意味着标准方差值较高，这个时候最终用户体验也会很差。

图　4-14　不良的可扩展性/响应时间模型

图4-15更加显著地展现了与图4-14相同一情况。本图例中响应时间与并发虚拟用户数量增长几乎呈同步增长趋势。

图　4-15　非常差的可扩展性/响应时间模型