lr_Analysis(z)

Analysis Summary Page

分析总结页面划分了三个主要的段，统计总结、事务总结以及HTTP响应总结。统计总结列出了在场景中统计的全部影响。

你可以在运行Vusers的顶点和场景运行的整个期间（这个阶段是17:08:38 – 17:54:35, 有 46分钟），对比吞吐量和统计点击率。

用户的数量和整个运行时间，就是衡量服务器/应用程序可承受吞吐量和点击率的性能了么？你必须对服务器/数据库性能和配置有更多的了解才可以确定。

下一个分析总结部分是事务总结，包括了每个单独的事务的统计，他们的回应时间（最小，平均，最大和标准偏差）

图中的“90 Percent”统计指出事务在当前行90%的最大响应时间。在这个统计数值之上，你可以知道90%的“A_MainPage_AFI…”这件事务最大的响应时间是94.845秒

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

所有的成功事务在“Z_”事务中至多等于最少通过的单独事务，这里不包括Vuser_init/end这两个事务，这是因为“Z_”事务记 录了整个脚本流的统计数字，而不只是一个单独事务。如果脚本中一个用户成功执行所有的步骤，从开始到结束，只有这个时候，“Z_”事务的成功值会上升。无 论如何，如果失败发生在脚本中的某一点，则事务失败的数量在发生失败的地方将会增加，并且“Z_”的失败事务数值也会随之增加。

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

最后部分的分析总结是HTTP响应总结，这包括了在测试过程中所有HTTP响应的总数和每秒统计的记录。最常出现的信号就是HTTP200，表明成功。这个HTTP所有响应的列表和它们的含意可以在术语表中查看附加的文档

Running Vusers

运行的用户图表显示了虚拟用户在场景中当前执行脚本的情况。一个虚拟用户按照测试脚本执行一次任务直到全部结束，这个用户已经执行了所需脚本的所有重复（iterations）除非手工停止controller中的用户

虚拟用户会在渐增的场景中被增加，不像上图中所有用户同时被加载，在虚拟用户的数量在压力测试计划中到达一个高度之后，会保持这些用户运行一段时间，再使用户数递减，递减的速度要比递增的快，因为从移除用户对服务器几乎没有任何不利影响。

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

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

Hits per Second

每秒点击率显示在网站服务器上随着时间推移的点击数量。这个图表可以显示整个场景或者最后60、180、600或3600秒的情况。你可以将它与事务响应时间图表对比来查看点击是如何影响事务的执行的。

每秒点击率的增涨表明服务器负荷的增加，所以将每秒点击率与事务响应时间和吞吐量对比，可以让你对服务器在压力下的执行有更多理解。当一个 网站服务器正在活动中，每秒点击率将会时常镜像成功的HTTP响应信号的总数。在上图中运行的第25分钟左右到达了尖锋。这可以在诸如运行的用户数、吞吐 量和事务响应时间中这些图表中找到答案。

Throughput

Throughput(吞吐量)展示了数据的总量,它基于字节，由网页服务器每秒向传送scenario的运行情况. Throughput 是基于字节/秒来传输的，它描述通过网络服务器传输的数据在网络上任意事件发生时的传输量。完美的吞吐量应该是随着每秒点击率的增加而增加，这种增加是建 立在带宽足够处理用户提出的所有请求的基础上的。

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

这个图表在展示了一个吞吐量在整个测试中普遍下降的情况，在前25分钟，这种减少的数量是少量却明显的，刚好对应了Hits per Sencond的图表的尖锋时刻，比较这些统计的数字，最好的方法就是把这些图表结合起来。

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

Hits per Second - Throughput

这张图表是把hits per second和 throughput两图结合起来的结果，我们可以看到在25分钟前后，每秒的点击的爆增和吞吐量的减少是相应的。如果一台服务器的业务量低于最大负载量，则每秒点击率通常

会映射吞吐量。上述图表中的结果最有可能的情况是由于用户负载的增加，因为更多用户将会引起每秒点击率的增长，并且当服务器不再处理大量的请求的时候，吞吐量将会减少。

说到后面的RunningVusers图表，我们知道在前25分钟，加载250个用户会使其到达峰值，由此，预期的每秒点击率的增长和吞吐量的减少说明了服务器的负载已经达到了它的最大值。我们可以预计事务的处理时间和每秒可能发生的错误也会在25分钟前后达到峰值。

Average Transaction Response Time

平均事务处理时间图表显示了平均每个事务的结束的反应时间。反应时间是从客户端请求到服务器响应的全部时间。通常的响应时间会与当前在测试场景中运行的Vusers的数量一致。

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

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

Transactions per Second (Passed/Failed)

每秒事务图表显示了随着时间推移，事务成功和失败的数量。一个事务表示单独的一个步骤或一个虚拟用户在一组用户中的执行。例如，这个过程是在一个事务中并发测试在网站上进入并确认登录信息

在规定时间内测试场景中的每秒事务数与运行的虚拟用户数相一致，并且随着虚拟用户的增加，每秒事务数也会增加。如果随着虚拟用户的减少，每 秒事务数也会减少，这时场景中很可能出现了问题。你应该先对比运行的虚拟用户数量与每秒事务图，以核实一次虚拟用户的增加是否导致每秒点击率、事务响应时 间和吞吐量的增加，将这些统计数据放到一起会帮助你找出问题发生的主要原因

Total Transactions per Second

每秒总事务图显示的是在测试场景的运行中，所有事务通过与失败的总和。我们可以清晰地看到所有事务的运行情况，像上一张图表一样，有更多特定的每秒事务，这张图表中红线代表失败的总数，说明正在运行的服务器由于一个用户已经超出它可以承载的最大能力

图中的红线说明事务失败的总数，在25分钟左右的时候出现了预期的峰值，表明服务器已经超出了可以承受用户的最大值。注意在35分钟前锐减的错误，这与测试中虚拟用户的减少相对应

Transaction Summary Graph

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

分析这张图表你可以发现事务成功/失败的比率，并确定哪个事务看起来需要更多注意。单一事务的大量失败表明在测试场景中有某类型的问题在一个时刻出现了，出现这种问题的原因可能是某个服务器或页面的问题。此外，分析其它结果会有助于确定事务失败的特殊原因。

例如，最右侧的事务失败率达到91.47%，明显地这已经超出了预期值。通过分析其它图表，你会发现它们精确地说明这个事务的失败情况。单独的事务同时出现通过与失败，暗示着场景中在某一点出现了问题。所以对比运行虚拟用户的数量、响应时间和吞吐量是有必要的。

注意这里的“Z_”事务，以且所有出现失败事务的总和，这个值总是大于任意一个单独事务失败的事务

Transaction Performance Summary

事务每秒执行总结图表除了在测试场景中规定了最小值、平均值、最大值响应时间之外与事务总结图表相似，

最右侧的事务是“Z_”事务，它在图中有最大值，因为它是所有事务之和。没有哪个事务单独表现出比其他事务高很多的响应时间，但是左边数第二个事务有30.2秒的平均响应时间值。如果可以得到此事务所需资源的更多信息（包括完成数据库的操作，服务器是否正常接收数据），你就会发现高出平均响应时间的原因。

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

Transaction Response Time (Under Load)

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

平缓的加载使你可以侦测到当虚拟用户数量达到多少时，事务响应时间会出现不好的变化。通过对比测试时间表与这张图表的统计数字，你可以确定响应时间的一个峰值与虚拟用户的增长是否相对应，否则你只能在其它地方找到问题出现的原因。

图中的加载0-20位用户时的平均响应时间是可以被忽略的，因为测试是从20个用户开始的。非常高的响应时间是因为LR测试软件本身的资源 使用，且从0-20用户在测试中没有任何的影响。用户初始化后，运行40用户时，平均响应时间锐减。最可能的原因是这40个用户在不同的网页/服务器之间 重新被分配，之后到达60用户

Transaction Response Time (Percentile)

事务响应时间显示了事务在一定时间内的响应百分比。图中事务的平均响应时间（绿线）到达90%时，响应时间已经超过了200秒。基于这点还 很难作出结论，不同于普通的观察。例如，事务在到达90%时的响应时间比在10%时要多。也很难直接地用其它图表而不用这张图表，因为在X轴上衡量事务百 分率这部分数据,想要在这些统计数据的基础上做出对比的结论实在困难。

HTTP Status Code Summary

HTTP状态标准总结包含了饼图显示了HTTP响应数量的集合，它按照状态分类。在多数测试中主要的响应标准是200，成功。图中50%的部份是200，25%是500（失败），另25%是请求页面404（未找到）。HTTP响应的详细标准和含义在附加的词汇表中说明

HTTP Responses per Second

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

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