zoukankan      html  css  js  c++  java
  • 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可以监控数据库和数据库所在操作系统的资源;

     

  • 相关阅读:
    prototype.js超强的javascript类库
    MySQL Server Architecture
    Know more about RBA redo block address
    MySQL无处不在
    利用Oracle Enterprise Manager Cloud Control 12c创建DataGuard Standby
    LAMP Stack
    9i中DG remote archive可能导致Primary Database挂起
    Oracle数据库升级与补丁
    Oracle为何会发生归档日志archivelog大小远小于联机重做日志online redo log size的情况?
    Oracle Ksplice如何工作?How does Ksplice work?
  • 原文地址:https://www.cnblogs.com/littlecat15/p/9455289.html
Copyright © 2011-2022 走看看