LR性能测试分析流程

LR性能测试分析流程

一、     判断测试结果的有效性

（1）在整个测试场景的执行过程中，测试环境是否正常。

（2）测试场景的设置是否正确、合理。

（3）测试结果是否直接暴露出系统的一些问题。

（4）确定测试结果有效之后，就要对测试数据进行深入的分析。

二、     分析思路

（1）分析原则：由外到内，由表到里，层层深入。拆分问题，隔离问题；

具体的步骤为：先看summary汇总，再逐步看每个事物，最后在精确的去看网页细分图；

（2）对于一个应用系统，性能开始出现了下降，最直观最直接的表象就是系统的响应时间，

如果响应时间变长，则系统响应时间就是分析性能的起点。

（3）任何一个复杂的系统都可以分为网络和服务器两部分。

（4）性能测试不是一蹴而就的，而是贯穿整个性能测试的流程。

（5）性能分析调优是一个不断推理不断验证的过程，不断试错，不断改正，打开自己的思维。

三、     重点性能指标

1、TPS（每秒通过事物数，直接反应服务器的处理能力，可理解为地铁进站口刷卡机）

2、平均事物响应时间（最直观的指标，可作为突破口）

3、每秒连接数（可初步判断是否需要调优连接数配置）

4、点击数（直接反应请求数、客户端、网络，点击数出现问题一般为脚本或者网络出现了问题）

四、     Analysis主要提供的6大类分析图

（1）虚拟用户图：虚拟用户图分为运行状态的虚拟用户图、虚拟用户概要图和集合点图。

（2）Errors图：主要有错误统计、每秒错误数量两类。借助Errors图可以发现服务器什么时间发生错误以及错误的统计信息，可以分析服务器的处理能力。

（3）事务图：Analysis和事务相关的分析图表有事务总述图、事务平均响应时间图、每秒通过事务数图、事务性能摘要图、事务响应时间与负载分析图、事务响应时间（百分比）图、事务响应时间分布图等。

（4）Web资源图：主要有Web服务器的吞吐率图、点击率图、返回的HTTP状态代码图、每秒HTTP响应数图、每秒重试次数图、重试概述图、服务器连接数概要图、服务器每秒建立的连接数量图等。借助它能深入分析服务器的性能。

（5）网页细分图：在cobtroller中启动网页细分功能后，才可以在Analysis中查看网页细分图。网页细分图主要有网页分解总图、页面组件细分图、页面组件细分图（随时间变化）、页面下载时间细分图、页面下载时间图（随时间变化）、第一次缓冲时间细分图、第一次缓冲时间细分图（随时间变化）、已下载组件大小图。借助网页细分图可以分析页面元素是否影响事务响应时间。

（6）系统资源图：要想获得系统资源图，必须预先指定相关的计数器。

五、     分析思路模型

六、     LR 场景运行图分析流程（分析实时监控图）

(1)Step1：分析事物响应时间, 查看transaction response time图表

=》1、哪个事物的响应时间最长，瓶颈就有可能出现在这个事物上；

=》2、哪些事物用的时间超出预定的可接受时间

(2)Step2: 分析网络带宽是否足够,查看throughput图

“ Throughput” 图显示在场景运行期间的每一秒钟， 从 Web Server 上接受到的数据量的值。拿这个值和网络带宽比较， 可以确定目前的网络带宽是否是瓶颈。

如果该图的曲线随着用户数的增加， 没有随着增加， 而是呈比较平的直线， 说明目前的网络速度不能够满足目前的系统流量。

=>1、用户数高，throughput曲线高-----》网络带宽（速度）满足系统流量

=>2、用户数高，throughput曲线直线-----》网络带宽（速度）不满足系统流量

(2)Step3: 硬件和操作系统能否处理高负载？windows resources

“ Windows Resources” 图实时地显示了 Web Server 系统资源的使用情况。 利用该图提供的数据， 可以把瓶颈定位到特定机器的某个部件。

注意：需要提前添加监控对象（web Server等）

七、     LR分析诊断结果图分析流程

LoadRunner性能测试结果分析是个复杂的过程，通常可以从结果摘要、并发数、平均事务响应时间、每秒点击数、业务成功率、系统资源、网页细分图、Web服务器资源、数据库服务器资源等几个方面分析。

1、分析Transaction Summary模块

从分析Summary的事务执行情况入手，Summary主要是判定事务的响应时间与执行情况是否合理。如果发现问题，则需要做进一步分析。通常情况下，如果事务执行情况失败或响应时间过长等，都需要做深入分析。

查看事物概要时候的一些原则，尤其要结合实际情况进行分析：

（1）     用户是否全部运行，最大运行并发用户数（Maximum Running Vusers）是否与场景设计的最大运行并发用户数一致。如果没有，则需要打开与虚拟用户相关的分析图，进一步分析虚拟用户不能正常运行的详细原因；

（2）     事务的平均响应时间、90%事务最大响应时间用户是否可以接受。如果事务响应时间过长，则要打开与事务相关的各类分析图，深入地分析事务的执行情况；

（3）     查看事务是否全部通过。如果有事务失败，则需要深入分析原因。很多时候，事务不能正常执行意味着系统出现了瓶颈；

（4）     如果一切正常，则本次测试没有必要进行深入分析，可以进行加大压力测试；

（5）     如果事务失败过多，则应该降低压力继续进行测试，使结果分析更容易进行；

说明：

Average表明事物平均响应时间：当标准差std比较小的时候，选择事务平均响应时间；

Std. Deviation表明事务的波动情况、稳定性，标准差比较小，则相对比较平稳，标准差比较大时，浮动比较大

90 Percent表明90%的事务的响应时间，波动大的事务查看90%的响应时间较准确；

Fail表示事务失败的个数；

2、查看负载生成器和服务器的系统资源情况

查看分析概要后，接下来要查看负载生成器和待测服务器的系统资源使用情况：查看CPU的利用率和内存使用情况，尤其要注意查看是否存在内存泄露问题。这样做是由于很多时候系统出现瓶颈的直接表现是CPU利用率过高或内存不足。应该保证负载生成器在整个测试过程中其CPU、内存、带宽没有出现瓶颈，否则测试结果无效。

而待测试服务器，则重点分析测试过程中CPU和内存是否出现了瓶颈：CPU需要查看其利用率是否经常达到100%或平均利用率一直高居95%以上；内存需要查看是否够用以及测试过程是否存在溢出现象（对于一些中间件服务器要查看其分配的内存是否够用）。

3、根据Vuser中的用户负载生成图分析（running Vusers）

如果较多用户未通过，说明脚本或场景设置有问题，如果只有一个或者少部分虚拟用户运行正常则有可能脚本出现问题。比如出现用户突然猛的下降等，则不必继续往后分析，需要修改脚本或者场景。

4、查看事务执行情况（ATRS+TPS）

（1）Average Transaction Response Time（平均事务响应时间）

反映随着时间的变化事务响应时间的变化情况，时间越小说明处理的速度越快。如果和用户负载生成图合并，就可以发现用户负载增加对系统事务响应时间的影响规律。

（2）TPS，Tracnsactions per Second（每秒通过事务数）

TPS是考查系统性能的一个重要指标，反映了系统在同一时间内能处理事务的最大能力，这个数据越高，说明系统处理能力越强。

4、查看错误发生情况

（1）     Error per Second(每秒错误数)：

了解在每个时间点上错误产生的数目，数值越小越好。通过统计数据可以了解错误随负载的变化情况，定为何时系统在负载下开始不稳定甚至出错。

（2）     Error statistics（错误统计）: 待确定

通过错误信息可以了解错误产生的时间和错误类型，方便定位产生错误的原因。

查看错误分类统计，作为优化系统的参考。例如对于Web性能测试，当出现瓶颈时往往需要查看服务器的错误统计信息结果：如果“超时错误”占到90％以上，可能需要提高硬件配置；如果较多的“内部服务器错误”，则可能是程序方面存在问题

5、分析web resource(网络资源统计图)

查看Web资源图时，往往结合前面对虚拟用户以及事务响应时间的分析结果，重点分析服务器的稳定性。

1)     首先分析一下Hits Per Second（每秒点击数）：每秒客户端向服务器发送的HTTP请求数，直接反应客户端侧的问题，每一次点击相当于对服务器发出了一次请求，数据越大越好。如果该值比较低，从脚本和网络上分析问题。

2)     分析一下Connections（连接数）：当该值比较低的时候，要对连接数进行调优。当该值比较大，说明服务器连接池越大。

3)     分析一下Connections per Second（每秒连接数）：每秒连接数就是每秒中打开的TCP/IP连接数，统计关闭的连接数和新建的连接数，方便了解每秒对服务器产生的连接数。当随着用户负载的增加连接数而终止，说明系统的连接池已满。需要修改服务器最大连接数的配置来解决问题。

6、查看网页细分（web page Diagnostics）

网页细分图，是显示每个页面及其组件的相关下载时间和大小，主要用来评估页面内容是否影响事务响应时间（只与事务响应时间有关）。通过与不同的事务图关联，可以分析网站下载慢或中断连接等问题的原因，从而确定系统性能问题是出现在网络还是服务器，再进一步而分析是哪个网页、什么因素导致的？

对于网页细分功能则遵循如下原则：

->首先分析从用户发出请求到收到第一个缓冲为止，哪些环节比较耗时；

->其次找出页面哪些组成部分对用户响应时间影响较大；

->当对页面的性能问题定位后，就可以采取相关的解决方案。

（1）     查看第一次缓冲时间细分图（time to first buffer breakdown）

指成功收到从web服务器返回的第一次缓冲之前的这一段时间内，每个页面组件的相关服务器和网络时间（以秒为单位），此图对分析页面的时间很重要，其中，网络时间为从发送第一个HTTP请求那一刻直到收到确认为止所经过的平均时间。服务器时间是指从收到初始HTTP请求确认直到成功收到来自web服务器的第一次缓冲为止所经过的平均时间。

（2）     第一次缓冲时间细分图（随时间变化）（time to first buffer breaddown over time）

第一次缓冲时间细分图（随时间变化）：第一次缓冲时间是在客户端与服务器建立连接后，从服务器发送第一个数据包开始计时，数据经过网络传送到客户端后，再到浏览器收到第一个缓冲数据所用的时间。（图中，用两种颜色来区分服务器和网络各自所用的时间，以确认是服务器问题还是网络问题，此图非常有用！）

（3）     页面下载时间细分图（page download time breakdown）

页面下载时间细分图根据DNS解析时间、连接时间、第一次缓冲时间、SSL握手时间、接收时间、FTP验证时间、客户端时间和错误时间对每个组件进行分析的。它可以确认在网页下载时期，响应时间缓慢是由网络错误引起，还是由服务器错误引起。

（4）web page breakdown for 响应时间超标的事物

如果某个事物时间过长，就可以利用页面分解，它将每个页面分解成

DNS Resolution(DNS解析时间): 浏览器向WebServer发送请求，一般情况下，该请求首先发送大DNS Server,把DNS名字解析成IP地址。解析的过程的时间就是。这个度量时间可以确定DNS 服务器或者DNS 服务器的配置是否有问题。如果DNS Server 运行情况比较好，该值会比较小。

Connection时间：解析出Web Server 的IP地址后，浏览器请求被送到了Web Server，然后浏览器和Web Server 之间需要建立一个初始化HTTP连接，建立该连接的过程就是connection时间。服务器端需要做2件事：一是接收请求，二是分配进程，。这个度量时间可以简单的判断网络情况，也可以判断Web Server 是否能够响应这个请求。如果正常，该值会比较小。

First Buffer时间:建立连接后，从Web Server发出第一个数据包，经过网络传输到客户端，浏览器成功接收到第一个字节的时间就是First Buffer;这个时间不仅可以表示Web server的延迟时间，还可以表示网络的反应时间；

Receive时间：从浏览器接收第一个字节起，直到成功收到最后一个字节，下载完成为止，这段时间就是receive时间，这个度量时间可以判断网络的质量；

SSL Handshaking时间：SSL 握手协议，用到该协议的页面比较少

ClientTime：请求在客户端浏览器延迟的时间，可能是由于客户端浏览器的thinktime 或者客户端其他方面引起的延迟。

Error Time：从发送了一个HTTP 请求，到Web Server发送回一个HTTP 错误信息，需要的时间

7、web服务器资源

可以通过Applications Manager 监控tomcat等，分析CPU、内存、JVM等；

8、数据库服务器资源

通过spotlight on oracle可以监控数据库和数据库所在操作系统的资源；