LoadRunner_Analysis(z) 分析

LoadRunner_Analysis(z) 分析

lr_Analysis(z)

Analysis Summary Page

Analysis Summary(分析总结页面)

分为三个部分：

Statistics Summary(统计总结)、Transaction Summary（事务总结）、HTTP Responses Summary（HTTP响应总结）；

Statistics Summary —— 列出了在场景中统计的全部影响；

可以看到此次测试最多运行了70个Vusers，可以在Running Vusers的顶点和场景运行期间【09:59:49-10:11:46，12分钟】，对比吞吐量、统计点击率；

当然仅仅以Vusers数以及全场景运行时间来衡量服务器/应用程序可承受吞吐量、点击率的性能是远远不够的，必须对服务器/数据库性能和配置有更多的了解才可以确定系统可承受的压力以及瓶颈；

Transaction Summary —— 包括了每个单独的事务的统计，以及响应时间（Minimum、Average、Maximum、Std.Deviation【标准偏差】）；

90 Percent显示事务在当前运行90%的最大响应时间。例如，可以看到90%的“A_MainPage_AFI…”事务最大的响应时间是94.845s

成功和失败事务都在这里显示。前缀为“Z_”的事务包含了脚本中使用的所有事务统计的总和；

所有成功事务在“Z_”事务中至多等于最少通过的单独事务，不包括Vuser_init/end两个事务；

在这个统计数字的基础上，“Z_”事务中成功事务的总数为776，符合最少成功的单独事务“E_ResultsDisplay…”，而在另一方面，“Z_“总的失败数是所有事务之和；

HTTP Responses Summary —— 所有HTTP响应的总数和每秒统计的记录；

最常出现的信号就是HTTP200，表明成功。具体的含义请查看http状态码；

=============================================================

图表分析：

Running Vusers

显示虚拟用户在场景中执行脚本的情况。

上图遵循着标准的测试时间表，每分钟增加10个用户，到达最大用户数250时运行10分钟，之后每分钟减少25个用户；

一个Vuser按照测试脚本执行一次任务到全部结束时，这个用户已经执行了所需脚本的所有重复（iterations）。手工停止controller中的用户除外；

Vusers会在运行场景中逐渐增加，当用户数在测试计划中达到一个高度之后，会保持这些用户运行一段时间，再使用户数递减，递减的速度比递增的快，因为移除用户对服务器几乎没有任何不利影响；

压力测试出现问题的时候，都应该知道当前场景中的用户数量，压力测试的目的是诊断程序在虚拟压力下出现的问题，因此，当虚拟用户的数量达到某个值时，会看到数据都在减少，那么可以说明程序的不稳定。突发的数据向相反方向（正或负）的延伸都意味着运行的虚拟用户在增加中；

筛选：仅查看所有Vuser同时运行的时间段。筛选图之后，显示的图数据范围将缩小，仅显示符合指定条件的数据。所有其他数据将隐藏。

右击该图并选择Set Filter/Group By...（设置筛选器/分组方式），或者单击工具栏上的设置筛选器/分组方式按钮，在筛选条件区域，选择需要筛选的条件，确定。取消点击Clear Filter/Group By....

Hits per Second

每秒点击率显示在服务器上随着时间推移的点击数量。

显示整个场景或者最后60、180、600或3600秒的情况，可以将此图与事务响应时间图对比，查看点击是如何影响事务的执行的；

每秒点击率的增长说明服务器的负荷增加，当一个服务器正在运行时，每秒点击率将会时常镜像成功的HTTP响应信号的总数，例如上图25分钟左右到达了尖锋，这可以在诸如运行的用户数、吞吐量和事务响应时间中这些图表中找到答案；

Throughput

上图展示了吞吐量在整个测试中普遍下降的情况：前25分钟，吞吐量减少是少量却明显的，对应了Hits per Sencond图的尖锋时刻。

显示数据的总量，基于字节，服务器每秒传送scenario的运行情况。

Throughput基于byte/s传输，描述通过网络服务器传输的数据在网络上任意事件发生时的传输量。如果有足够的带宽，吞吐量是随着每秒点击率的增加而增加的。

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

这张图表展示了整个测试过程中吞吐量的一个正常减少，在25分钟前面这里，减少的数量不大却也清晰，与上一张图表Hit per Second正好对应，单纯的这些统计数字还是不如整体对比的看所有图表来得准确详细

Hits per Second - Throughput

hits per second和throughput对比图【关联两个图：右击 ——Merge Graphs...—— Correlate（关联）】，在25分钟左右，每秒的点击量的增加和吞吐量的减少是对应的。如果服务器的业务量低于最大负载量，每秒点击率通常会映射吞吐量；

上图中最有可能的情况是由于用户负载的增加，大量用户将会导致每秒点击率的增加，且当服务器不再处理大量请求的时候，吞吐量将会减少；

分析Running Vusers图，在前25分钟，加载250个用户会使其到达峰值，因此，预期每秒点击率的增长和吞吐量的减少说明服务器的负载已经达到了它的最大值，可以预计事务的处理时间、每秒可能发生的错误都会增长；

Average Transaction Response Time

显示平均每个事务结束的反应时间。反应时间是从客户端请求到服务器响应的全部时间。图上的点代表在场景运行的特定时间内事务的平均响应时间。

通常响应时间会与当前在测试场景中运行的Vusers数量一致；

响应时间增加最基本的原因是运行用户数的增加，因为随着用户进入测试场景的增加，服务器的工作量也会增加。服务器需要去响应一个增加的负载，于是平均响应时间就会增长；

上图中预期响应的增长时间，与其它图中25分钟左右数据变化一致，查看 “Z_AFIWhitePages_s2_e3_v3_Transaction”事务，这是最早能分析常规行为的方法，进入场景后的10分钟里，总响应时间增长到110s左右，在10分钟的时候Vusers运行的人数达到120，与前面对比，服务器工作量增大；

Transactions per Second (Passed/Failed)

上图显示随着场景的运行，事务成功、失败的数量。

在规定时间内测试场景中的每秒事务数与运行的虚拟用户数相一致，并且随着虚拟用户的增加，每秒事务数也会增加；如果随着虚拟用户的减少，每秒事务数也减少，那么场景中很可能出现了问题。

这种情况下，应先对比运行的虚拟用户数量与每秒事务图，确定一次虚拟用户的增加是否导致每秒点击率、事务响应时间以及吞吐量的增加，综合这些数据分析，有助于找出问题得原因。

Total Transactions per Second

上图显示测试场景运行中，所有事务通过与失败的总和。

红线代表事物失败的总数，说明正在运行的服务器由于一个用户已经超出它可以承载的最大能力；

25分钟左右出现了预期的峰值，表明服务器已经超出了可以承受用户的最大值。另：35分钟左右事物失败减少与测试中虚拟用户数的减少相对应；

Transaction Summary Graph

交易总数图表显示测试场景中所有成功、失败、停止事务的记录。成功事务是完全成功的，失败事务是由于未预期事件的出现（一个页面的加载失败，登录失败等）导致的，停止事务是指没有满足成功或失败条件。

通过分析上图，可以根据事务成功/失败比率，确定哪个事务看起来需要更加注意。

单一事务大量失败，表明在测试场景中有某类型的问题在一个时刻出现了，原因可能是某个服务器或页面的问题。结合其他图表分析，有助于确定事务失败的特殊原因。

Transaction Performance Summary

事务每秒执行总结图除了在测试场景中规定了最小值、平均值、最大值响应时间之外与Transaction Summary Graph（事务总结图）相似。最后是“Z_”事务，它在图中有最大值，因为它是所有事务之和。

这个例子中，0响应时间的事务是当虚拟用户被加载和退出测试场景时的初始化和终止，可以忽略不计。如果测试计划需要，初始化和终止中也可以包含多个动作，例如场景在三个部分中都需要事务，可以在进入程序时一次性初始化，执行动作时根据设置的次数运行，然后退出程序（终止）；

Transaction Response Time (Under Load)

事务响应时间（压力下）图是运行的虚拟用户数和平均事务响应时间表的结合。显示在测试场景的某一时刻事务响应时间与虚拟用户数的关系。此图有助于查看虚拟用户数加载、分析平缓加载的场景对响应时间产生的影响；

平缓加载，可以查看当虚拟用户数量达到多少时，事务响应时间会出现较大幅度的增加。

通过对比测试时间表与上图的统计数字，可以确定响应时间的一个峰值与虚拟用户的增长是否相对应，否则只能在其它地方找到问题出现的原因。

上图加载0-20用户时的平均响应时间是可以忽略的，因为测试是从20个用户开始的。非常高的响应时间是由于LR测试软件本身的资源使用。用户初始化后，运行40用户时，平均响应时间迅速较少，最可能的原因是这40个用户在不同的网页/服务器之间重新被分配，之后到达60用户；

Transaction Response Time (Percentile)

上图显示事务响应时间的响应百分比。

图中事务的平均响应时间（绿线）到达90%时，响应时间已经超过了200s。基于此图很难得出有利的分析内容；

HTTP Status Code Summary

HTTP状态标准总结包含饼图，显示HTTP响应数量的集合，按照状态分类；测试中，主要的响应标准是HTTP_200（成功）。

上图50%的部份是HTTP_200，25%是HTTP_500（失败），另外25%是HTTP_404（请求页面未找到）。具体的含义请查看http状态码；

HTTP Responses per Second

HTTP每秒响应图统计的是HTTP响应的状态标准，最常用的有HTTP_200（成功），HTTP_302（重定向），HTTP_404（未找到）和HTTP_500（内部服务器问题）。增加的HTTP响应意味着服务器正在处理更多的请求，并成功发送一个HTTP的响应给用户。

上图测试的整个过程中，“成功”响应标准与“页面未找到”响应标准的数量相对稳定，响应503标准在18分钟时开始出现一个峰值，说明服务器无法获得请求，在25分钟的时候503标准的每秒响应相当的大，达到每秒16次，说明这时服务器已经超出它可承受的最大值，此结论被其它结果支持。

=====================================================================================================

保存模板：

关联图可能会经常用到，下次分析场景时，为避免重新设置，可以将合并设置和筛选器设置保存为模板，并在其他Analysis会话中使用。

操作步骤：

1、Tools——Templates，打开“Apply/Edit Template”对话框；

2、在“Templates”窗格中，单击New，打开“Add new template”对话框；

3、输入模板名称，确定；

4、Save and close；

下次打开新的Analysis会话，需要使用保存的模板时，按如下操作：

1、Tools——Templates，打开“Apply/Edit Template”对话框；

2、从“templates”列表中选择模板，Apply to Session；