loadrunner - analysis

Posted 2020-10-04 小明变幻每当的预想

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了loadrunner - analysis相关的知识，希望对你有一定的参考价值。

一、打开analysis分析器

方法一：在controller中打开，Results ==》Analyze Result

方法二：打开analysis（有两种文件类型可以选择，1.analysis session files；2.loadrunner results。两种都可以）

二、configure measurements 设置

在分析图时，发现分析图的Y轴幅值过小时，就可以在这里进行设置，对Y轴进行适当的放大或缩小操作，如图所示：

三、设置筛选条件

四、analysis图

analysis分析器中提供了丰富的分析图，常见的有8类：

1）vuses图：在方案执行过程中，vuser在执行事务时生成数据。使用vusers图可以确定方案执行期间vuser的整体行为。它显示vuser状态和完成脚本的vuser的数量。主要包括正在运行的vuser图和vuser摘要图

2）错误图：主要统计方案执行时的错误信息。主要包括error statistics(by description)、error per second(by description)、error statistics和error per second四种图。

3）事务图：描述了整个脚本执行过程中的事务性能和状态。主要包括平均事务响应时间图、每秒事务数图、每秒事务总数、事务摘要图、事务性能摘要图、事务响应时间（负载下）图、事务响应时间（百分比）图和事务响应时间（分布）图。

4）web资源图：主要提供有关web服务器性能的一些信息。使用web资源图可以分析方案运行期间每秒点击次数、服务器的吞吐量、从服务器返回的HTTP状态代码、每秒HTTP响应数、每秒页面下载数、每秒服务器重试次数、服务器重试摘要、连接数和每秒连接数。

5）网页细分图：主要提供一些信息来评估页面是否影响事务响应时间。包括网页细分、页面组件细分、页面组件细分（随时间变化）、页面下载时间细分、页面下载时间细分（随时间变化）和已下载组件图

6）系统资源图：主要监控场景运行期间系统资源使用率的情况。可以监控windows资源、UNIX资源、SNMP资源、Antara Flame Thrower资源和SiteScope资源

7）web服务器资源图：主要用来捕捉场景运行时web服务器的信息。主要用来分析microsoft IIS服务器、apache服务器、iplanet/netscape服务器和iplanet(SNMP)服务器。

8）数据库服务器资源图：主要显示数据库服务器的统计信息。目前支持DB2、oracle、sql server和sybase数据库。

五、摘要报告

1、概要部分

2、统计部分

3、SLA

可以在摘要视图中单击如图所示的按钮，配置SAL。当然也可以在controller中设置SLA，建议在controller中进行设置。

SAL结果分析

以上图中蓝色框选中的事务为例，单击“Analyze Transaction”为例，得到下图

4、事务统计部分

注：事务的通过率一定要大于95%，也即失败率应该小于5%，因为如果事务失败率过高，就说明客户在使用系统时很容易出现错误，这样无论事务响应时间多么短也是不符合要求的，因为客户最基本的需求都没有被满足，功能都不能正确的处理，那么更无法谈性能了。

5、HTTP响应统计

HTTP是一种通信协议，它允许将超文本标记语言（html）文档从web服务器传送到web浏览器。HTML是一种用于创建文档的标记语言，这些文档包含到相关信息的链接。可以单击一个链接来访问其他文档、图像或多媒体对象，并获得关于链接项的附加信息。

HTTP响应状态码：当浏览者访问一个网页时，浏览者的浏览器会向网页所在服务器发出请求。当浏览器接收并显示网页前，此网页所在的服务器会返回一个包含HTTP状态码的信息头（server header）用以响应浏览器的请求。

HTTP状态码的英文为HTTP Status Code。

下面是常见的HTTP状态码：

200（成功）服务器已成功处理了请求。通常，这表示服务器提供了请求的网页。
201（以创建）请求成功，并且服务器创建了新的资源。
202（已接受）服务器已接受请求，但尚未处理。
203（非授权信息）服务器已成功处理了请求，但返回的信息可能来自另一来源。
204（无内容）服务器已成功处理了请求，但没有返回任何内容。
205（重置内容）服务器已成功处理了请求，但没有返回任何内容。要求用户清除表单内容，输入新的内容
206（部分内容）服务器成功处理了部分请求。
301（永久重定向）请求的网页已永久移动到新位置。服务器返回此响应（对Get或Head请求的响应）时。会自动将请求者转到新位置。
404（请求的网页未找到）服务器找不到请求的网页。例如，对于服务器尚不存在的网页经常会返回此代码.
500（服务器内部错误）服务器遇到错误，无法完成请求，一般是由于页面代码加载出错造成。

六、analysis常见图分析

在LR分析器中对资源使用的情况分析得很少，因为通常在性能测试过程中很少使用LR来监控系统资源的使用，特别是UNIX、LINUX和ALX操作系统，几乎不使用LR来监控，更多的是借助第三方工具来监控，当然如果服务器是windows操作系统，那么使用LR进行监控比较简单。

1、vuser图

它显示vuser状态和完成脚本的vuser的数量。将这些图与事务图结合使用可以确定vuser的数量对事务响应时间产生的影响。

X轴表示从方案开始运行以来已用的时间，Y轴表示方案中的vuser数，vuser图显示在测试期间的每一秒内执行vuser脚本的vuser数量及其状态。可以帮助确定任何给定环境中服务器上的vuser负载。默认情况下，此图仅显示为running的vuser。

2、点击率图

显示在方案运行过程中vuser每秒钟向web服务器提交的HTTP请求数。借助此图可以依据点击次数来评估vuser产生和负载量。一般会将此图与平均事务响应时间图放在一起进行查看，观察点击数对事务性能产生的影响。X轴表示方案从开始运行以来所用的时间，Y轴表示服务器上的点击数。

注意：点击率并不能衡量服务器的真实处理能力，也不能仅仅通过点击率来衡量服务器的处理能力，因为服务器即使出现了瓶颈也还会影响到这个值的变化，因为LR其实也是一个代理录制的工具，将录制过程中提交的请求录制成脚本，在回放时模拟用户重新提交这些请求，那么在提交的时间LR可以对HTTP请求进行统计，进而生成点击率视图。但是这并不代表LR画出来的点击率视图一定正确，假如客户端实际提交的HTTP请求为2000个/s，但点击率视图画出来的值为1000个/s，这说明客户端提交的请求根本就没有完全发送到服务器，那么这种情况最有可能是在网关处请求出现超时，因为每个网关端口都有一个允许其访问的最大值，当这个值过大时，网关也会出现排队现象，如果队列过长就会导致一些请求出现超时现象，最后导致统计出来的点击率的值不正确。

3、平均事务响应时间图

平均事务响应时间图直接反映系统的性能情况，这也是客户眼中的性能，在需要时必须明确地定义好业务的响应时间，在分析时一般先分析的响应时间，当平均事务响应时间符合定义时，也仅仅说明响应时间能达到要求，但是此时并不代表系统达到客户要求，因为LR统计出来的事务响应时间不一定正确，所以当事务响应时间达到要求后，也一定要分析一些其他的数据，需要确定的是业务是否都做成功了，如果业务都做成功了，并且事务响应时间达到要求，这样才能说明事务响应时间达到客户的要求；如果平均事务响应时间达不到要求，就需要进一步分析，是哪些原因导致事务响应时间过长，这样才能进一步优化系统的性能。

4、吞吐量图

显示方案运行过程中服务器上每秒的吞吐量。吞吐量的单位为字节，表示 vuser在一秒时间内从服务器获得的数据量。借助此图可以依据服务器吞吐量来评估vuser产生的负载量，可以和平均事务各应时间图对照观察，以查看吞吐量对事务性能产生的影响。

X轴表示方案从开始运行以来已用的时间，Y轴表示服务器的吞吐量（以字节为单位）。吞吐量直接反映了服务器的处理能力，如果服务器处理的吞吐量的值越大，说明服务器处理业务的能力越强，但是在测试过程中不可能一次就测试出服务器吞吐量的值，必须经过多次测试才能找到吞吐量的值，即测试过程中一定要找到吞吐量的拐点，这样才能找到服务器处理业务时的最大吞吐量，亦即服务器处理的最大能力。

七、合并图

不难看出，这些结果都是系统生成的单一性的结果图，如果想要分析得出更加系统、全面的结果我们就应该用到LR的一项重要技能——合并图

LoadRunner结果图Analysis提供三种类型的合并：
· 叠加，即查看共用一个X轴的2个图表的内容
· 平铺，
· 关联，即绘制两个图标的Y轴，彼此对应

1、“运行Vuser”和“平均事物响应时间”的关联图

需要注意的是，一般情况下随着“并发用户”的增加“平均事物响应时间”应该是越来越长。但是经常测试的朋友可能会遇上很明显的当并发用户多的时候，平均事物的响应时间是越来越短的。

通过该合并图可以分析随着用户数量的变化，各个事务平均响应时间的变化，从而可以得出各个事物在制定时间内最大的并发用户数。

2.“每秒点击数”与“吞吐量”的叠加图

“每秒点击数”反映了客户端每秒钟向服务器端提交的请求数量，如果客户端发出的请求数量越多，与之相对的“吞吐量”也应该越大，并且发出的请求越多会对“平均事务响应时间”造成影响，所以在测试过程中往往将这三者结合起来分析。

上图是“每秒点击数”与“吞吐量”的叠加图，正常的统计结果两者应是一一对应成正比关系。（如果“每秒点击数”正常，而“吞吐量”不正常，则表示服务器虽然能够接受服务器的请求，但返回结果较慢，可能是程序处理缓慢。如果“吞吐量”正常，而“每秒点击次数”不正常，则说明客户端存在问题，那种问题一般是网络引起的，或者录制的脚本有问题，未能正确的模拟用户的行为）

3.“运行Vuser”和“吞吐量”的关联图

并发用户数和吞吐量瓶颈之间存在一定的关联，（在网络和服务器正常的情况下，随着并发用户数增加，网络吞吐量也会增加。）因此可以通过不断的增加并发用户书和吞吐量观察系统的性能瓶颈。然后从网络、数据库、应用服务器和代码本身4个环节确定系统的性能瓶颈。

4.“每秒点击数”与“吞吐量”的关联图

在比较吞吐量和每秒的点击率中我们可以获得服务器在执行过程中的情况。如果服务器如和预期的一样在执行，那么吞吐量会随着它每秒的点击量增加而增加。这是期望实现的情况，因为点击增加一次就会需要服务器发送更多的信息给用户。如果电机的次数增加而吞吐量恒定或减少以及在固定范围内壁咚，就说明服务器无法执行增加的请求（每秒点击率），结果就是事务反应时间的增加。