压力测试结果分析

世界上每天都有越来越多的工具进行压力测试。实际上,对该主题的兴趣开始增长。

负载测试工具的主要任务是向系统施加给定的负载。但是除此之外,还有一项同样重要的任务-提供有关提交此负载的结果的报告。否则,我们将进行测试,但我们将无法说出其结果,也无法准确确定系统从什么时候开始降级。



目前最受欢迎的测试工具是Gatling,MF LoadRunner,Apache JMeter。它们都具有生成所执行的测试的现成报告以及单个图形或原始数据的能力,并以此为基础构建报告本身。







在编写任何报告之前,您需要了解我们为谁编写的报告以及我们追求的目的。如果您的目标是确定是否存在内存泄漏,在可靠性测试过程中是否解决了不稳定的工作,或者在回归测试中需要比较两个发行版,则没有必要为每个操作在报告中添加许多应用程序响应时间图。要回答这些问题,您只需要几个图表,当然,除非您已解决了这些问题并且不想理解它们。因此,在创建报告之前,请考虑是否真的需要向其中添加所有图形还是仅向最具指示性的图形添加图形,并给出测试目的的答案。此外,图表集及其对报告的分析取决于所选的负载模型-闭合或打开,因为不同的模型在图表上会给出不同的数字。



Tinkoff的我们积极使用加特林(Gatling)工具,因此,通过其示例,我们将告诉您如何创建梦report以求的报告以及进行分析时应从何处看。我还想立即指出,本文中描述的几乎所有图表都可以通过使用带有Grafana的工具捆绑包在线获得。它是使用预配置的仪表板即时创建报告的最便捷工具。而且,它使您可以根据发送的数据更快地创建几乎任何图形。几乎所有的负载测试工具都已经有现成的仪表板。还将提供其他工具的图形(MF LoadRunner和Apache JMeter),它们的分析与盖特林类似。



基本指标



指标



按组显示请求响应时间的数量和百分比分布。使用这种类型的图表可以方便地对测试结果进行快速的初步评估,而无需深入分析其余图表。



基于对等审查或SLA(非功能要求)预定义了组到组的阈值。例如,可能有三组:



  • 优秀-响应时间少于50秒;
  • 中-大于50,但小于100秒;
  • 糟透了-超过100秒。


在Gatling中,您可以自己在gatling.conf文件中配置从一个组移动到另一个组的阈值及其数目。最好根据方法来构建此类图表。APDEX(应用程序性能指数)

您还可以添加一个指标,其中包含失败请求的数量/百分比。







APDEX方法允许您在回归测试中使用指标来比较发行版:通过这种方式,您可以立即查看发行版总体上变差或变好了多少。不幸的是,该图在MF LoadRunner和Apache JMeter中并不是开箱即用的,但是使用Grafana仪表板可以很容易地创建它。



响应时间表



默认情况下,Gatling基于百分位数,平均和最大响应时间以及错误构建表。它跟踪的内容超出了SLA(超出非功能性要求)。通常,SLA指示百分位数95、99和错误百分比。因此,该表使您可以快速评估测试结果。



如果将查询分组为事务,则可以在表中同时看到单个查询的分数以及整个组和事务的分数。

HTML加特林报告
MF LoadRunner还在“分析摘要报告”块中创建表本身,称为事务摘要
在Apache JMeter中,此数据可以在“聚合报告”中找到


虚拟用户图表



它通常是分段测量的,并显示用户如何进入应用程序,从而说明实际的负载情况。应当立即注意到,对于MF LoadRunner和Gatling,这些图显示了虚拟用户数,对于Apache JMeter,这些图显示了线程数。



该图用于控制负载应用程序的正确性。设计方案必须与您实际提交给系统的内容相对应。例如,如果您在图表上看到与计划的方案有较大的向上偏差,则表明出了点问题:计算错误,启动了加载工具的副本超过所需的数量,等等。也许分析进一步的图表毫无意义,因为您提交的用户比计划的多100个,并且该系统最初设计为仅可用于10个用户。

此图分为两种类型:



  • 活动用户显示每秒当前有多少个线程处于活动状态。当线程启动和停止时,尤其是在开放负载模型中,此速率将在整个测试中波动。
  • VUser总数显示自测试开始以来总共已启动和停止的线程数。对于线程不会死亡的封闭负载模型很方便。


图的类型还取决于负载模型:



  • 封闭模式-用户必须根据计划的负载配置文件登录系统。如果该图显示了下降或峰值,则表明负载没有根据计算或计划的情况而变化,需要进一步研究。
  • — , . , . , , / . , — .


HTML Gatling Report
MF LoadRunner Running Vusers
Apache JMeter Active Threads Over Time , JMeter-Plugins.org


Response Time



最常用的度量单位是毫秒-它显示了对应用程序请求的响应时间。响应时间不应超过SLA。该图是用于在负载测试期间查找退化点的主要工具。



如果峰在图形上可见,则表示此时由于某种原因该应用程序没有响应-这可能是进一步研究的起点。响应时间应该是均匀的,在整个负载步骤中所有操作都不应出现峰值,并且还应与负载夹带相关。与其他工具不同,加特林不包括“净”(平均,未汇总)响应时间图。



除了每个请求的响应时间图以外,还可以显示一条带有总响应时间(总响应时间)的行。通过叠加施加的负载(VU / RPS)图,您可以跟踪因增加的施加负载(VU / RPS)而增加响应时间的相关性。Apache JMeter将此图称为“响应时间与线程”。



接下来,将有一个图,在图上可以有很多行,每行都显示自己的场景或请求。如果您具有包含许多操作和非线性配置文件的复杂测试,则建议您仅在报告中显示最具代表性的查询或一组查询。或者,您只能反映超出SLA / SLO的请求,以免弄乱计划和报告。

在MF LoadRunner中,该图称为“平均事务响应时间”,并显示事务的平均时间
对于Apache JMeter,该图在JMeter-Plugins.org网站的高级软件包中存在两个版本,被称为“随时间变化的响应时间”,默认情况下称为“响应时间图”。我认为,更直观,更方便是首选





图变化



可以进行修改,其中应用响应时间百分位数,并为所有请求添加一条平均响应时间。由于平均响应时间对尖锐的异常值非常敏感,因此在此处使用百分位会更正确。



在性能测试中,最常用的是第95位和第99位。但是,如果您查看平均响应时间,则应考虑标准偏差(均方根)。

HTML加特林报告
对于MF LoadRunner,该图将称为事务响应时间(百分比)
您还可以使用同一扩展集中的Response Times Percentiles图获得Apache JMeter百分位数


响应时间分布



还有出色的图表,显示了时间分布对请求数量的依赖性。



这种图表有点类似于指标,但是可以更完整地显示时间分布,而不会受到百分位数或其他总计的限制。使用图表,您可以更清楚地定义指标组的边界。MF LoadRunner没有这样的时间表。

每个请求的HTML加特林报告
还有另一种选择,可以根据整个测试的成功和错误查询,从查询数量中分配查询执行时间
MF LoadRunner Transaction Response Time (Distribution)
Apache JMeter Response Times Distribution


Latency



根据该指标,还可以区分出一个额外的参数延迟(毫秒)-延迟时间(通常将其理解为网络延迟)。此参数显示从发送请求结束到从系统接收到第一个响应数据包之间的时间。

如果该参数增加,您也可以使用此参数在网络级别上测量延迟。期望它趋于零。这类图和下一种图主要用于深入分析和发现性能问题。该图形在盖特林中并不是开箱即用的。在MF LoadRunner中,如果您已安装监视代理,则该图在“网络虚拟化图”块中称为“平均延迟图”。

在Apache JMeter中,此图仅存在于扩展集中,称为随时间推移的响应延迟


带宽



与上述指标类似,您可以选择带宽参数(每秒千位数)-通道的带宽。它显示了每单位时间可以传输的最大数据量。



通过在加载工具上更改此参数,您可以模拟与应用程序的不同连接源:4G移动或有线网络。免费版的加特林没有此图表,它仅在付费版的加特林FrontLine中可用。该图仅在MF LoadRunner中是开箱即用的,它与“延迟”位于同一块中,称为“平均带宽利用率图”。



每秒请求图



每秒测量的数量-显示在1秒内进入系统的请求数。



该图显示了系统在负载下可以处理多少个请求,它还是构建报告的主要图。它也跟踪超越SLA的情况,因为随着通过退化点或局部极值时负载的增加,可以观察到故障,然后急剧增加。这通常是由于以下事实:当应用程序开始降级时,请求也开始在应用程序的入口处堆积(出现队列),然后应用程序给予它们某种响应,或者请求因超时而下降,这导致图形急剧增加-因为收到了答案。



  1. VU, RPS/TPS , .
  2. Response Time, , .


HTML Gatling Report
MF LoadRunner Hits per Second
Apache JMeter Hits per Second


TPS



它以每秒的碎片数为单位,并在1秒内显示事务数(事务中可能有许多请求)。



例如,交易“输入您的个人帐户”包括以下请求:打开主页,输入用户名,密码,按“发送”按钮,重定向到欢迎页面-每单位时间。在加特林(Gatling)中,只能使用Grafana获得图形,因为对于HTML报告中的组,图形仅按响应时间构建。

MF LoadRunner-每秒事务数
对于Apache JMeter扩展软件包-每秒事务数


错误表



通常以速率(每秒数)进行测量-该图显示错误请求数量的增加。将值作为请求总数的百分比来度量也很方便。此图通过错误的数量或百分比跟踪SLA越界。



如果覆盖“响应时间”图,则可以看到错误的增加如何影响应用程序响应时间的增加。



默认情况下,加特林没有单独的图形,仅显示错误。在加特林(Gatling)中,它与VU图结合在一起,立即显示了负载的增加如何影响错误数量的增加,并有助于检测超出SLA或根本没有出现错误的阈值。Apache JMeter也没有单独的时间表,它与事务数量图表结合在一起。

HTML加特林报告
在MF LoadRunner中,此图称为每秒错误数


HTTP响应状态



还可以通过应用响应代码在图表上绘制错误数量的分布图-方便用于错误分类。



例如,如果您在上一张图表中获得了100%的收益,则开始分析是由于服务器没有响应而导致的50x错误,还是由于池不正确且用户无法登录而导致的403错误(例如,您正在使用HTTP协议。

最初,Gatling的免费版本没有此图表,它仅在Gatling FrontLine的付费版本中可用。为了使图形显示在免费版本中,您需要重新配置logback.xml,以便将日志收集在graylog中,并且已经在其中,以构建所需的图形。

在MF LoadRunner中,此图称为每秒HTTP响应数
Apache JMeter从高级软件包中将此图称为“每秒响应代码”


吞吐量图



通常以每秒位数为单位。该图显示了应用程序的吞吐量,即应用程序每单位时间发送和处理了多少数据。

它通常用于深入分析应用程序问题。加特林只在FrontLine中包含此图,而在免费版本中则不包含。

该图在MF LoadRunner中开箱即用,称为吞吐量
在Apache JMeter中,该图被称为高级包中随时间变化的字节吞吐量


可能的修改



  1. Response Time, , (Throughput). Response Time, Throughput , : - .
  2. Bandwidth, , .
  3. VU, , , . .




测试后,可以使用基于HTML的加特林报告或通过配置Graphite-InfluxDB-Grafana监视包来获取大多数图形为了显示,可以使用仪表板库https://grafana.com/grafana/dashboards/9935中的现成仪表板



在分析和编译仪表板以进行加特林时,应考虑到InfluxDB中的结果是聚合存储的,并且仅适用于NT结果的初步评估。建议在测试后将Simulation.log重新加载到数据库中,并基于该数据库构建最终报告并搜索系统性能问题。



指标矩阵描述



我们上面描述的所有内容都以小平板电脑的形式总结了所有这些知识。

一种 VU 响应时间 要求 失误 通量
VU , RPS/TPS/HITS , , VU . , , , .
Response Time , . , , (Throughput). Response Time, Throughput , : -
Requests , , . . , . SLA . . ,
Errors , ,
Throughput ,



All Articles