精华内容
下载资源
问答
  • LoadRunner压力测试结果分析探讨
  • LoadRunner8.1压力测试结果分析探讨,分析原则,错误提示分析,监控指标数据分析,最大并发用户数应,用系统在当前环境下能承受的最大并发用户数等相关内容
  • 1、使用Assertion对结果进行简单的分类 响应断言:通常是用于对每一个request sampler进行额外验证的工具 ...2、通过jtl结果分析 查看jtl文件,分析结果,可以对结果进行大致的分类分析 设置jtl文件格式:选择某个...

    1、使用Assertion对结果进行简单的分类
    响应断言:通常是用于对每一个request sampler进行额外验证的工具
    响应时间断言:规定请求的响应时间不能超过多少毫秒 1000毫秒=1s
    文件大小断言:单位bytes,可以暂时不用考虑,除非性能过程中有说必须是某个size的范围之内
    2、通过jtl结果分析
    查看jtl文件,分析结果,可以对结果进行大致的分类分析
    设置jtl文件格式:选择某个监听器,点击页面的configure按钮,对结果文件进行配置,建议多勾选如下选项:Sava File Name,Sava Assertion Failure Message.
    从如下这个弹窗去进行选择:
    在这里插入图片描述
    jtl文件也可以用Excel文件打卡查看

    3、查看结果树:
    指定结果存储的jtl文件位置,方便后面对其进行分析
    注意:如果你测试的场景会有很多transaction完成,建议在这个Listener中仅记录出错的transaction就可以了,要做到这样,只需要将Log/Display中的Errors勾中就可以了。

    展开全文
  • LR压力测试结果分析探讨 ZT 压力测试 报告分析 (有兴趣的朋友一起探讨一下压力测试 后的分析!图没有上传,有兴趣的朋友可以发mail给我!) 分析原则: 1.具体问题具体分析(这是由于不同的应用 ...

    文章来源互联网。

    LR压力测试结果分析探讨 ZT

    压力测试 报告分析 (有兴趣的朋友一起探讨一下压力测试 后的分析!图没有上传,有兴趣的朋友可以发mail给我!)

    分析原则:

    1.具体问题具体分析(这是由于不同的应用 系统 ,不同的测试目的,不同的性能关注点)
    2.查找瓶颈时按以下顺序,由易到难。
        服务 硬件瓶颈  网络 瓶颈(对局域网,可以不考虑) 服务 操作系统 瓶颈(参数配置) 中间件瓶颈(参数配置,数据 ,web服务 等) 应用瓶颈(SQL语句、数据 设计业务 逻辑、算法等)
       
    分析的信息来源:
    1 根据场景运行过程中的错误提示信息
    2 根据测试结果收集到的监控指标数据

    一.错误提示分析

    分析实例:
    1.Error: Failed to connect to server “172.17.7.230″: [10060] Connection
    Error: timed out Error: Server “172.17.7.230″ has shut down the connection prematurely

    分析:
    A、应用服务死掉。
    (小用户时:程序上的问题。程序上处理数据库的问题,实际测试中多半是服务器链接的配置问题)

    B、应用服务没有死()
    (应用服务参数设置问题)
            对应的Apache和tomcat的最大链接数需要修改,如果连接时收到connection refused消息,说明应提高相应的服务器最大连接的设置,增加幅度要根据实际情况和服务器硬件的情况来定,建议每次增加25%!

    C、数据库的连接
    (数据库启动的最大连接数 (跟硬件的内存 有关))

    D、我们的应用程序spring控制的最大链接数太低

    2 Error: Page download timeout (120 seconds) has expired

    分析:

    A、应用服务参数设置太大导致服务器的瓶颈
    B、页面中图片太多
    C、在程序处理表的时候检查字段太大多
    D、实际测试时有些资源需要请求外网,而我们的测试环境 是局域网环境
    3 Error  “http://172.17.7.230/Home.do....

    分析:
            A、脚本 设计错误,造成页面异常。服务器有响应!
            B、并发数过大,造成服务器响应延迟。

    4 Error page “text=xxxxx”

    分析:
            A、脚本设计问题,例如,前一脚本修改了某些内容,造成后面的脚本访问异常。
            B、不确定因素,有时候回放正常的脚本,一放到场景中就出现这样的错误。只能反复修改脚本!

    二.监控指标数据分析
    1.Vusers数
            Loadrunner 系统设置的虚拟用户数目。Vuser去实际调用事先制作的脚本文件中的应用。
            每个Vuser产生响应的操作,所有的操作对服务器形成并发。
           
    颜色        比例        度量        图最小值        图平均值         图最大值        图中间值        图SD
            1        Run        0.0        21.25        44        41        21.276

            在实际测试中,Vusers可以根据实际情况的需要,在测试过程中增加或者减少。

    2.最大并发用户数:

    颜色        比例        度量        最小值        平均值        最大值        SD
            100        Apache CPU 使用情况(Apache):172.17.7.210        0.777        0.852        0.93        0.043
            0.01        已发送 KB/秒(Apache):172.17.7.210        6        1430.371        2689.333        327.924
            0.1        点击次数/秒(Apache):172.17.7.210        0.333        114.352        533.667        40.201

    应用系统在当前环境下能承受的最大并发用户数。
        在方案 运行中,如果出现了大批用户的业务操作失败,或出现了服务器shutdown的情况,则说明在当前环境下,系统承受不了当前并发用户的负载压力,那么最大并发用户数就是前一个没有出现这种现象的并发用户数。
            从上图可以看出:在测试运行到4个小时左右的时候,apache的点击数/秒开始迅速增加!

    3.业务操作响应时间:

        使用“事务性能摘要”图,可以确定在方案执行期间响应时间过长的事务。

    颜色        比例        度量
            1        最小值
            1        平均值
            1        最大值
            分析事务的响应情况,要每次详细分析,目前还只能观察到响应时间过长的事务!

    4.每秒点击数
            负载测试 期间每秒内 Vuser 在 Web 服务器上点击的次数。可根据点击次数来估算 Vuser 生成的负载数。


    颜色        比例        度量        图最小值        平均值        图最大值        图中间值        图SD
            1        点击次数        69.908        105.736        130.244        103.666        12.186

            从图中不难看出,在4小时的时候,点技数明显增高。和apache的每秒点击数增大的时间相吻合!

    5.吞吐量
            负载测试期间 Web 服务器上的吞吐量(字节)。吞吐量表示在任何指定秒内 Vuser 从服务器接收到的数据量。此图可估计 Vuser 生成的负载量(服务器吞吐量)。

    颜色        比例        度量        图最小值        平均值        图最大值        图中间值        图SD
            1        Throughput        1257502.795        1375591.372        1525865.047        1372743.691        49130.473

            同样,从图中可以看出,在4个小时的时候,web服务 器的吞吐量开始增高。在图中还可以看到吞吐量的走势图,从开始到进行到4个小时反弹之前呈降低的趋势,这是因为系统在初期调用的资源都是直接来之服务器,运行一段时间后系统的部分资源来自缓存。

    6.下载组件大小
            每个页面的组件大小,且包括组件的标头的大小!


            页面组件大小的分析表格比较复杂,实际分析中可以通过loadrunner的报告分析工具来分析。页面组件大小分析主要是找到页面中比较庞大的组件,如果其影响到了页面的下载速度,则要想办法将其改小!

    7.Apache资源
            显示APACHE web服务器上的资源摘要。前面已经提到过以并发点击数为主。



    颜色        比例        度量        最小值        平均值        最大值        SD
            100        Apache CPU 使用情况(Apache):172.17.7.210        0.777        0.852        0.93        0.043
            0.01        已发送 KB/秒(Apache):172.17.7.210        6        1430.371        2689.333        327.924
            0.1        点击次数/秒(Apache):172.17.7.210        0.333        114.352        533.667        40.201

    三.服务器资源监控指标:
            (目前通过top监察)
    内存:
    Linux资源监控中指标内存页交换速率(Paging rate),如果该值偶尔走高,表明当时有线程竞争内存。如果持续很高,则内存可能是瓶颈。也可能是内存访问命中率低。
            实际测试中,当并发点击数出现突然剧增前后,内存的PR 值则居高25不下。说明目前测试的系统中内存存在瓶颈!
           
    内存资源成为系统性能的瓶颈的征兆:
    很高的换页率(high pageout rate);
    进程进入不活动状态;
    交换区所有磁盘的活动次数可高;
    可高的全局系统CPU利用率;  
    内存不够出错(out of memory errors)

    处理器:

    Linux资源监控中指标CPU占用率持续超过80%(对该值的要求,根据具体应用和机器配置而要求不同,有资料 表明95%),表明瓶颈是CPU。
            实际测试中,当并发点技数出现突然增加前后,cpu的占用率持续保持在86%以上!
    说明,目前系统用应用的cpu也是测试的瓶颈!

    CPU资源成为系统性能的瓶颈的征兆:  
    很慢的响应时间(slow response time)  
    CPU空闲时间为零(zero percent idle CPU)  
    过高的用户占用CPU时间(high percent user CPU)  
    过高的系统占用CPU时间(high percent system CPU)  
    长时间的有很长的运行进程队列(large run queue size sustained over time)

    四.数据库服务器
            数据库服务器目前测试观察,当web服务器点击率增大时,观察mysql 数据库的最大连接数 ,仍未超过系统设置的最大连接数。所以,暂时未发现数据库的瓶颈!


    五.结论
            以上报告分析中的数据、图标均来自同一次测试。是在平时测试中挑出的一次现象比较明显,比较利于观察的作为分析案例。
            根据以上综合分析,当前测试环境下,当应用系统产生最大533.667的并发压力。平均负载压力114.352。根据分析,用户在4个小时的时候,并发数 迅速增加前后的值在400左右!分析结果跟实际测试的硬件环境以及测试脚本有一定关系。同时,测试服务器的硬件配置和实际服务器的配置还有一定的差距!
    展开全文
  • 测试说明:模拟100个用户,对服务器发起总共1000次请求。 测试命令: ab -n 1000 -c 100 https://xxx.xxx.xxx/ 测试报告如下图: apache的版本信息 This is ApacheBench, Version 2.3 <$Revision: 1843412 $>...

    测试说明:模拟100个用户,对服务器发起总共1000次请求。

    测试命令: ab -n 1000 -c 100 https://xxx.xxx.xxx/

    测试报告如下图:

    在这里插入图片描述

    apache的版本信息

    This is ApacheBench, Version 2.3 <$Revision: 1843412 $>
    Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
    Licensed to The Apache Software Foundation, http://www.apache.org/
    

    测试完成度

    Benchmarking xxx.xxx.xxx (be patient)
    Completed 100 requests
    Completed 200 requests
    Completed 300 requests
    Completed 400 requests
    Completed 500 requests
    Completed 600 requests
    Completed 700 requests
    Completed 800 requests
    Completed 900 requests
    Completed 1000 requests
    Finished 1000 requests
    

    服务器所用的软件信息

    Server Software:        nginx/1.15.11
    

    被测主机名

    Server Hostname:        xxx.xxx.xxx
    

    被测主机的服务端口号

    Server Port:            80
    

    请求的具体文件

    Document Path:          /
    

    求的文件大小

    Document Length:         2426 bytes
    

    并发级别,也就是并发数,请求中-c参数指定的数量

    Concurrency Level:      100
    

    本次测试总共花费的时间

    Time taken for tests:   14.708 seconds
    

    表示总请求数量

    Complete requests:      1000
    

    表示失败的请求数量,这里的失败是指请求在连接服务器、发送数据等环节发生异常,以及无响应后超时的情况。如果接收到的HTTP响应数据的头信息中含有2XX以外的状态码,则会在测试结果中显示另一个名为“Non-2xx responses”的统计项,用于统计这部分请求数,这些请求并不算在失败的请求中。

    Failed requests:        848
       (Connect: 0, Receive: 0, Length: 848, Exceptions: 0)
    Non-2xx responses:      848
    

    表示所有请求的响应数据长度总和,包括每个HTTP响应数据的头信息和正文数据的长度。注意这里不包括HTTP请求数据的长度,仅仅为web服务器流向用户PC的应用层数据总长度。

    Total transferred:      814854 bytes
    

    表示所有请求的响应数据中正文数据的总和,也就是减去了Total transferred中HTTP响应数据中的头信息的长度。

    HTML transferred:       492560 bytes
    

    吞吐率,计算公式:Complete requests/Time taken for tests

    Requests per second:    67.99 [#/sec] (mean)
    

    用户平均请求等待时间,计算公式:Time token for tests/(Complete requests/Concurrency Level)。

    Time per request:       1470.800 [ms] (mean)
    

    服务器平均请求等待时间,计算公式:Time taken for tests/Complete requests,正好是吞吐率的倒数。也可以这么统计:Time per request/Concurrency Level。

    Time per request:       14.708 [ms] (mean, across all concurrent requests)
    

    表示这些请求在单位时间内从服务器获取的数据长度,计算公式:Total trnasferred/ Time taken for tests,这个统计很好的说明服务器的处理能力达到极限时,其出口宽带的需求量。

    Transfer rate:          54.10 [Kbytes/sec] received
    

    这几行组成的表格主要是针对响应时间,也就是第一个Time per request进行细分和统计。
    Connect:网络链接
    Processing:系统处理
    Waiting:等待
    min:最小值
    mean:平均值
    [+/-sd]:标准差(Standard Deviation) ,也称均方差(mean square error),表示数据的离散程度,数值越大表示数据越分散,系统响应时间越不稳定。
    median:中位数
    max:最大值

    需要注意的是表中的Total并不等于前三行数据相加,因为前三行的数据并不是在同一个请求中采集到的,可能某个请求的网络延迟最短,但是系统处理时间又是最长的呢。所以Total是从整个请求所需要的时间的角度来统计的。这里可以看到最慢的一个请求花费了7106ms,这个数据可以在下面的表中得到验证。

    Connection Times (ms)
                  min  mean[+/-sd] median   max
    Connect:        0    0   0.6      0      10
    Processing:   237 1271 619.7   1074    7106
    Waiting:      225 1270 619.8   1073    7106
    Total:        237 1271 619.6   1074    7106
    

    这个表第一行表示有50%的请求都是在1074ms内完成的,可以看到这个值是比较接近平均系统响应时间(第一个Time per request: 1470.800 [ms] (mean))

    以此类推,80%的请求是小于等于1179ms的。刚才我们看到响应时间最长的那个请求是7106ms,那么显然所有请求(100%)的时间都是小于等于7106毫秒的,也就是表中最后一行的数据肯定是时间最长的那个请求(longest request)

    Percentage of the requests served within a certain time (ms)
      50%   1074
      66%   1099
      75%   1112
      80%   1179
      90%   1894
      95%   2669
      98%   3344
      99%   4014
     100%   7106 (longest request)
    
    展开全文
  • 做完之后会结果进行统计分析。因为统计的内容比较多,都是通过shell命令行进行操作。于是编写了一个简单的shell脚本。 具体脚本内容如下: #!/bin/bash CASENUM=0 #定义了一个全局变量passnum(){ echo "=========...

    最近工作性质发生了改变,在做操作系统方面的测试。接手的第一个任务是做ltp stress。测试内核稳定性。

    做完之后会结果进行统计分析。因为统计的内容比较多,都是通过shell命令行进行操作。于是编写了一个简单的shell脚本。

    具体脚本内容如下:

    #!/bin/bash

    CASENUM=0 #定义了一个全局变量
    passnum()
    {
    echo "=============="
    pass=`grep PASS /home/ltp/ltp.log | wc -l`#统计执行用例pass的次数。
    echo "pass的用例个数 $pass"
    }
    failnum()
    {
    echo "=============="
    fail=`grep FAIL /home/ltp/ltp.log | wc -l`#统计执行用例fail的次数
    echo "fail的用例个数 $fail"
    }
    casenum()
    {
    echo "=============="
    pass=`grep PASS /home/ltp/ltp.log | wc -l`
    fail=`grep FAIL /home/ltp/ltp.log | wc -l`
    let CASENUM=($pass+$fail)#统计总的执行用例的次数(这里可以进行优化)
    echo "总的用例个数 $CASENUM"
    }
    cpuload()
    {
    echo "==============="
    ldavg1=`(sar -q -f /home/ltp/sar.out| tail -n 1|awk '{print $4}')`
    echo "ladvg_1:$ldavg1"

    ldavg5=`(sar -q -f /home/ltp/sar.out| tail -n 1|awk '{print $5}')`
    echo "ladvg_5 $ldavg5 "

    ldavg15=`(sar -q -f /home/ltp/sar.out|tail -n 1|awk '{print $6}')`
    echo "ldavg_15 $ldavg15"
    }

    cpuuse()
    {
    echo "==============="
    #use=`(sar -u -f /home/ltp/sar.out| sed -n '$p' |awk '{print $3}')`
    use=`sar -u -f /home/ltp/sar.out| tail -n 1|awk '{print $3}'`
    #system=`(sar -u -f /home/ltp/sar.out| sed -n "$p" |awk '{print $5}')`#写sed命令的时候一定得注意用单引号编写,sed -n "$p" 这种写法错误,导致无法找到对应数据。
    system=`(sar -u -f /home/ltp/sar.out| tail -n 1 |awk '{print $5}')`
    cpuuse=`awk 'BEGIN{printf "%.2f%%\n",('$use'+'$system')}'`
    echo "CPU使用率为:$cpuuse"
    }
    memuse()
    {
    echo "==============="
    mem=`(sar -r -f /home/ltp/sar.out| tail -n 1 |awk '{printf "%.2f%%\n", $4}')`
    echo "内存使用率为:$mem"
    }
    swapuse()
    {
    echo "==============="
    swap=`(sar -S -f /home/ltp/sar.out|tail -n 1|awk '{printf "%.2ff%%\n", $4}')`
    echo "swap平均使用率为:$swap"
    }
    success()
    {
    echo "==============="
    pass=`(grep PASS /home/ltp/ltp.log | wc -l)`
    succ=`awk 'BEGIN{printf "%.2f%%\n",('$pass'/'$CASENUM')*100}'`
    echo "成功比率为:$succ"
    }

    failcase()
    {
    echo "==============="
    failcase=`grep FAIL /home/ltp/ltp.log |sort|uniq|wc -l`
    echo "faicase总数为: $failcase"
    grep FAIL /home/ltp/ltp.log |sort|uniq>/home/ltp/failcase.txt
    echo "具体的fail列表在生成的/home/ltp/failcase.txt文件中请查看是否存在重复"

    }

    passnum
    failnum
    casenum
    cpuload
    cpuuse
    memuse
    swapuse
    success
    failcase

    在调试脚本的时候,总结了以下几个小点:

    1.需要的到某个命令的返回值,定义一个变量等于这个命令,但是这边命令必须用``(大键盘数字1左边的那个按钮反单引号)扩住,否则就不执行这个命令

    2.编写一个函数之后,一定要在下边写一下执行函数名称,否则看不到返回结果

    3.写sed命令的时候一定得注意用单引号编写,sed -n "$p" 这种写法,导致无法找到对应数据。应该写为sed -n '$p'也是长知识了,这个经实践发现写成

    sed -n"2,$p"这种格式是提示不对的,然后改成单引号之后就好了,还是sed不熟练。

     

    转载于:https://www.cnblogs.com/superyezi/p/9066026.html

    展开全文
  • LR压力测试结果分析

    2012-03-06 12:10:00
    压力测试报告分析 (有兴趣的朋友一起探讨一下压力测试后的分析!图没有上传,有兴趣的朋友可以发mail给我!)分析原则: 1.具体问题具体分析(这是由于不同的应用系统,不同的测试目的,不同的性能关注点) 2.查找...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 1,120
精华内容 448
关键字:

压力测试结果分析