LoadRunner_性能测试分析

阅读量：3943 次

发布时间：2019-05-24

本文共 4919 字，大约阅读时间需要 16 分钟。

文章目录

1.测试结果分析（三种情况）

性能测试结束后，要对测试结果进行分析。

分为三种情况：

测试结果完全符合需求，不需要分析。

测试结果存在问题（不符合需求，时间超长），直接通过测试报告（Analysis）查找到原因。直接写出报告。（前提：对应Analysis中结果描述非常清楚。）

如果通过测试报告没有得出结果（性能瓶颈），这种情况比较复杂。

2.复杂情况分析:事务响应时间过长

比如发现某些事务响应时间超长（最普遍），该如何处理？

1）通过Analysis报告中几个比较重要的图表进行查看，初步定位问题，再通过网页细分图（网页诊断图）去确定响应时间长在系统的哪个部分。大多数情况下，时间长在服务器端。
（响应时间 = 客户端时间 + 网络时间 + 服务器时间）

2）要进一步确定是哪台服务器（复杂的系统服务器n，甚至几十台–集群）
答案：通过监控服务器的系统资源图，能够很容易地定位出哪台服务器不正常。

3）如果是应用服务器（在企业中也常称为中间件），如Tomcat、JBoss、Weblogic、WebSphere，发生问题，调整服务器配置参数即可。
共性：都是软件，都安装在服务器主机上提供企业级应用的支持。
区别：免费、收费（上百万）
Tomcat: Apache开源组织、免费
Weblogic: BEA公司出品，后来被Oracle收购了
WebSphere: IBM公司应用服务器

4）大部分情况都是数据库服务器出现问题，可以通过专门的数据库监控工具去监控，甚至可以提取到相应有问题的sql语句。可以对sql语句进行分析、调优，进而提升被测系统的性能。

注意：以上的调试流程不适合于每个被测系统，绝大部分的系统可以在前面的某些步骤中即可停止，完成性能分析过程。

3.页面细分图

1）操作：右击Graphs --> Add New Item --> Add New Graphs…

–> 打开 Open a New Graph窗口，在Web Page Diagnostics中进一步查看细分图。

a、Web Page Breakdown
页面中的组件，也叫做页面中的元素。包括组成网页的内容：文字、图片、音频、视频、动画…

b、Page Component Breakdown (Over Time)
页面组件细分图（随时间变化）更细致

c、Page Download Time Breakdown
页面下载时间细分图
响应时间：包括请求后，响应的各个阶段
八项中主要关注前4项：

名称	解释
DNS（Domain Name System）	域名解析时间（好比：根据公司名找到主机号码时间）
Connection	连接时间（好比：公司找一个客服解析接待的时间）
First Buffer	第一次缓冲时间（好比：获取第一个数据包的时间，很重要）
Receive	接收时间（好比：获取到所有数据包的接收时间，从第一个字节开始记录）
SSL握手	只发生在基于Https协议通信的网页上
Client Time	由于客户端引起的延迟
Error Time	系统页面报错时才发生，不是总有
FTP Time	FTP验证时间：当系统中存在FTP(File Transfer Protocol) 文件传输协议，服务器下载操作时才产生该时间

特别说明：First Buffer Time第一次缓冲的时间（第一个数据包）

Client ----> Web Server ----> DB Server

<---- <-----

可以细分为：网络及服务器处理时间 + 数据库时间

客户端（Client）从发送请求到收到第一个缓冲（大小 8K）之间的时间

问题：First Buffer时间和 Receive时间有没有交集?

发送 4K内容，如果First Buffer是8K，则有交集。无需过于区分，因为侧重点不同。

d、First Buffer的时间：细分为网络时间和服务器时间，如果网络（带宽）情况不好，则网络的时间可能会对服务器时间造成影响；如果是内网测试，则基本没有这种问题。
操作：1>打开Time to First Buffer Breakdown 第一次缓冲时间细分图
       看到只对First Buffer进行细分，分为：
      ① Network Time 网络时间
        ② Server Time 服务器时间（占绝大部分）
2>打开Time to First Buffer Breakdown(Over Time)第一次缓冲时间细分图（随时间变化）
      发现细分图条数：元素个数 * 2

f、页面中所有组件（元素）大小的和 = 该页面的大小
操作：打开Download Compoent Size(KB) 已经下载的组件大小图
结合Breakdown Tree 细分树查看

2）看结果分析图时，一定注意：不光看图的走势，还要看图中坐标的单位。要二者结合出结果。

比如：一张图中走势在某处（某个时间范围）很陡峭，但是其下载时间的坐标轴中最高值为0.006，所以该时间没有问题。

现象：First Buffer占的比例较大（与网络和服务器有关），可以进一步细分：网络时间和服务器时间

网络时间：
Client 第一次Http请求开始计时 --> Web Server --> DB Server
<–直到返回服务器的第一个字节为止（收到确认）

服务器时间：
收到请求确认，并处理请求开始计时 -->
<–直到返回第一次缓冲的时间

4.页面诊断图（综合图）

操作

1）右击Graph --> Add New Item --> Add New Graph–> Web Page Diagnostics (第一项)

2）从事务响应时间图中选中某条需要分析的时间，点击右键（页面诊断），直接打开（经常使用，目标明确）

找到Graph --> Average Transaction Response Time --> 找到某条折现 --> 右击 --> show Diagnostics for “xxx” 打开，xxx就是事务的名称，比如"login"。

观察综合图的分布规律

1）左边是细分树 Breakdown Tree

比如login的URL地址，对应右边中间： Select Page to Break Down 中的地址。

2）最上边 Average Download Time 下载细分时间

3）右边中间的组件细分部分（最关心的部分）

具备4个单选钮：

Download Time

Component(Over Time) 组件细分

Download Time(Over Time) 下载时间细分

Time to First Buffer(Over Time) 第一次缓冲时间

关注：Download Time 分为8种颜色对应相应时间

右击条目：

a) 拷贝全路径名到剪切板

b) 在浏览器显示 View page in browser

各种颜色中，蓝色的First Buffer比例最大，想进一步分析First Buffer，单选：Time to First Buffer(Over Time)

又细分为：Network Time 和 Server Time (大部分)

基本线索：找到某组件，单选钮切换是针对该组件看不同相关的图
归纳：

右侧：上中下都有关系

上：显示下载时间图

中：显示URL地址、具体细分图

下：显示该项打钩

页面诊断图（综合图）的分析方式

一般从事务平均响应时间中定位到某个事务产生诊断图。

1）一般情况下，先通过默认页面（Download Time）–> First Buffer，即发现当前页面中某个组件的第一次缓冲时间较长，再到第一次缓冲时间细分图中，确认网络时间还是服务器时间，多半是服务器时间较长，则瓶颈定位到服务器端。

2）选中页面的某一元素，则其后的Sheet页逐一切换，能够自动定位到统一元素。（加亮显示）

分析：如果一个图片0.2M，假如1000用户并发执行某事务，该页面中包含这个图片，则0.2M * 1000 = 200M，如果带宽10MB，则光下载该元素（图片）需要200/10 = 20秒。使用造成性能影响，带来较大压力。（一般页面是3-5-8原则）

5.windows资源监控

1）%Processor time: CPU忙的时间的百分比，当该值的平均值超过80%或者85%时（(yu)阈值），一般怀疑CPU有瓶颈。
—如果CPU的确有瓶颈（处理能力不足），可以添加CPU或者置换性能较高的CPU.
（硬件问题较易解决，软件问题较难解决）

2）Processor Queue Length
a、阈值：单CPU不应大于2；如果是n块CPU，则该值不应大于n+1;
b、双核，则n=2 （虽然双核性能不及2块CPU，但也当做2块CPU处理）

3）注意：在服务器资源中，如果没有特殊说明，则都是值平均值。（最大值和最小值只作为一般参考）

4）如果一个性能测试点（比如login）,其中依次完成单用户登录、50用并发登录、100用户并发登录；则这个测试中%Processor Time的平均值应该呈现递增的趋势。

5）内存重要指标 Memroy
     a、对于Windows系统而言，可用物理内存不要少于1%。
比如：2G内存，如果可用物理内存20M或者更少，则要引起注意，怀疑内存处理能力不足。
    b、观察可用物理内存曲线时，在测试过程中提交的物理内存会在测试结束后慢慢释放回来，则这种系统为正常的内存表现。
    c、系统的内存存在大量软错误（在内存的其它位置找到该资源）的情况下能正常工作，但是如果硬错误（必须重新回磁盘找数据）较多，则会对系统的性能带来影响。
    d、Page Reads/sec (页面读取率)：如果该值持续大于内存的1%（如果2G内存，该值持续大于20M），则怀疑内存不足。
说明：在Windows资源监控中，Memory部分：Page Faults/sec和Pages/sec也要监控。

6）磁盘的重要指标 Physical Disk
    a、Disk Reads(Writes)/sec 磁盘读或写的阈值：
一般不超过几十M
如果发现磁盘的读或写超过过了几十M或者上百M，会严重影响系统性能。怀疑是磁盘的瓶
    b、性能调优的一个重要原则就是：尽量减少磁盘IO
说明：Disk I/O 就是磁盘的in或out 读/写
    c、磁盘的I/O绝对不可避免（磁盘和内存的交互必不可少），但是可以尽量减少。

7）网络重要指标：Bytes Total/sec (重要) 和 Packets/sec
a、Bytes Total/sec: 将该值乘以8，与网络带宽的一半进行比较，如果小于带宽的一般，则一般没有问题。
b、1Byte=8bits
说明：网络商带宽单位一般都用bit，显得数值大。比如100Mbps

8）性能分析——监控服务器资源
    a、客户端在测试时，不需要监控，因为主要对AUT监控，主要是其服务器，为何只监控服务器：测试AUT的性能，只需关注AUT的服务器即可，客户端只需偶尔观察：使用安装LR的测试机（模拟客户端）测试时，偶尔打开本机的任务管理器，点击“性能窗口”，查看，保证正常使用即可。
    b、如何监控服务器的内存泄露？
        首先正常测试（监控正常指标），当发现被测系统的内存曲线不正常时，再去测试三项指标
        正常的情况：物理内存在测试过程中不断被吃进，在测试结束后释放回来。
        三项指标：（两升一降）
        process\private bytes 和 process\working set 计数器升高
        available bytes 的值降低
    c、如何判断应用程序的问题：CPU平均值高，吞吐率整体水平不高甚至有所下降，但是上下文切换很高（正常系统中偶尔的、适当的上下文切换是有必要的，若频繁，则有问题），说明系统应用程序存在设计或代码方面的问题。