Jiang LiHeng Good is good, but better carries it.

性能测试--4、结果解析:有效的根源问题分析

2020-03-09
jiangliheng
本文 2700 字,阅读全文约需 8 分钟

通常可以利用“拐点”来进行性能测试分析与定位。“拐点”的出现意味着应用程序的一种或多种资源利用达到了极限。

过程分析

实时分析(密切观察(watchful waiting))

通过工具,可以发现如下信息:

  1. 每个事务的响应时间,并且能够以图表和图形两种方式展现;(不仅包括完整的事务,也包括事务的任何组成部分);
  2. 能够监控每个脚本所分配的用户数以及测试全过程中所分配的用户总数;(可以实时观察用户负载增长和事务吞吐量增长时,应用程序的反应);
  3. 监控所有负载生成器,以便能够检查负载生成器是否过载;
  4. 需要监控与任何已经作为性能测试一部分的服务器、应用服务器以及网络KPI所有相关数据(需要其他工具配合);
  5. 有一个能够配置性能测试阀值的图形界面和发生错误时的指示器;
  6. 一个显示测试执行过程中所发生错误信息的图形界面。

测试后分析

性能测试结束后,测试工具可以存储性能测试结果供测试后分析。

性能测试输出的类型

统计入门

平均数和中位数

平均数:一系列数字的算术平均值。 中位数:是一组数据的中间值;比如1,2,2,2,3,9——–算术平均数为3.17,中位数为2。

中位数更能体现“平均数”。

标准方差和正态分布

标准方差反映所有数据与这组数据平均值之间的平均偏离度;较高的标准方差意味着最终用户的体验不够稳定;性能测试的目标应该使标准方差的值较小。

Nth百分比

统计学中的Nth百分比用于定义测试结果的采样比例;比如:40th百分比意味着选取在40%及小于40%的一组结果。

响应时间分布

关注响应时间的分布,如:平均值、中位值、P90值、标准方差等。

响应时间测量

应用程序或服务器每个事务的响应时间通常是性能测试的重点关注指标。

响应时间:指的是客户端向服务器发起请求到客户端接收到响应所花费的时间

思考时间:所有消耗在客户端的时间,代表最终用户和应用程序之间交互的正常延时与停顿

性能测试工具一般都工作在中间层,也就是说工作在表现层之下。

通常衡量响应时间不应该包括思考时间,关注的是从客户端请求到服务器完全返回响应所花费的时间(某些工具可以区分思考时间和响应时间)。

随着负载用户的增加,响应时间也会相应增加,但是增加幅度不一定同步。

添加事务中的“检查点”的响应时间,有助于提高响应时间的分析粒度,并且可以将相对较差的时间与特定事务的行为进行关联。

所有事务中的最差性能“检查点”排序图,有助于分析事务中突出的问题所在。

吞吐量和容量

事务吞吐量:强调对于某个事务的处理有多快。 容量:强调在某个时间段内能够处理多少事务。

吞吐量的降低是Web服务器层或应用服务器层达到容量极限的标志。

监控关键性能指标

远程监控:Windows注册表、基于Web的企业管理系统、简单网络管理协议、JMX技术、Rstatd(传统的基于RPC的监控工具); 客户端需要关注:CPU 使用率、内存使用率、页使用率、I/O(磁盘和网络)、磁盘可用空间。

服务器关键性能指标

最关注的两个指标:CPU 使用率、可用内存大小。

网络关键性能指标

接收和发送字节的网络流量。

负载生成器性能

负载生成器自己在性能测试过程中超负荷,会导致性能测试无法表现真实的行为,同时产生的结果不可信。

负载生成器需要监控的典型指标:

  • CPU 使用率
  • 可用内存
  • 页使用率
  • I/O(磁盘和网络)
  • 磁盘可用空间

根本原因分析

在进行分析之前,调整测试数据的时间范围,去掉加载和退出的时间,以确保测试结果的准确性。

保证分析的测试数据是一段稳定状态。

可扩展性和响应时间

良好的可扩展性和响应时间的模型就是随着虚拟用户和事务吞吐量的增加,平均响应时间平稳增长,但增长值处于可接受的范围内;反之,伴随着虚拟用户负载的增加,响应时间随之增加,而且增加趋势不平稳,或者变得不稳定,标准方差远高于平均值。

深入挖掘

找到问题的原因,需要结合服务器和网络KPI一起分析原因。

应用服务器内部

当一般级别应用服务器的监控不能提供更多的信息,我们需要找出具体的哪些组件的调用产生的问题。

寻找“拐点”

拐点:性能测试过程中在一定的吞吐量或一定数量的活动用户下,性能测试图中的一些或者说有事务的响应时间曲线有一个急剧的上升或下降趋势。

错误处理

检查所有性能测试过程中所发生的错误时非常重要的,因为这些错误可能表示应用程序的部分模块已经达到了性能极限。

基准数据

一个成功的性能测试项目最后的输出,将是一个基准性能数据,该基准性能数据可能在系统部署后的应用监控中用到。

分析报告检查列表

测试前的准备工作

  1. 确保您已经配置了合适的服务器、应用服务器和网络KPI;
  2. 确保您已经决定执行最后的混合性能测试;
  3. 确保负载生成器可以访问你的应用程序;
  4. 假如您的性能测试工具能够自动为性能目标设置阀值,并且把它作为性能测试体系的一部分(基于目标的性能测试场景);
  5. 性能测试工具把事务响应时间、当前虚拟用户数、服务器和网络KPI指标自动关联;设置KPI阀值的标准,定义是否测试通过;
  6. 如果使用第三方监控工具,在执行测试前,确保这些工具进行了正确的配置;
  7. 把第三方工具输出的数据整合到你的性能测试工具中。

测试执行过程中的工作

  1. 实时检查负载生成是否过载;
  2. 确保每次的测试执行都形成文档,保存下来:
    • 性能测试执行文件的名称,测试执行的日期和时间;
    • 对测试组成部分进行一个简要描述;
    • 当前执行的测试对应的测试结果文件名;
    • 与性能测试以及相关事务对应的所有输入数据文件名称;
    • 对测试过程中所发生的任何问题的简要记录。
  3. 测试执行过程注意如下事项
    • 突发错误(应用程序构架某些地方已经达到了它的极限;假如你的测试是由数据驱动的,可能你的测试数据不够使用;还有可能与特定的活动用户数量有关;);
    • 事务吞吐量突然下降;
    • 系统可用内存泄露问题;
    • 来自网管的紧急电话(生产系统崩溃)。

测试完成后的工作

  1. 一旦性能测试完成后,无论什么后果,都要确保您为每次测试收集了所有相关数据(第三方监控工具特别注意);
  2. 将所有测试资源(脚本、输入数据文件、测试结果等)备份到一个独立的文件夹是一个好的习惯,因为你不知道什么时候需要进行回归测试;
  3. 编写测试报告的时候,确保测试结果与性能目标对应,这些性能目标是在预测试的需求获取阶段设定的.

参考文档

  • 《应用程序性能测试的艺术》

微信公众号:daodaotest


作者:Jiang LiHeng
原文链接:https://jiangliheng.github.io/2020/03/09/performance-analysis/
本文版权归作者所有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文链接。


Comments

Content