LR数据收集分析 Analysis 名词解释

来源:互联网 发布:微视频 软件 编辑:程序博客网 时间:2024/05/16 09:30
AnalysisSummary:场景摘要


Period:场景运行的起止时间。


ScenarioName:场景名称


ResultsSession:场景运行的结果目录


Duration:场景运行的时间


 


StatisticsSummary:场景状态的统计说明


MaximunRunning Vusers:场景最大用户数


TotalThroughput(bytes):总带宽流量


AverageThroughput(bytes/second):平均每秒带宽流量


Total Hits:总点击数


 


AverageHits per Second:平均每秒点击量


Transaction Summary:事务摘要


Total Passed:事务的总通过数


Total Failed:事务的总失败数


TotalStopped:事务的总停止数


Tips:LR11中事务时间已经自动不包含 lr_think_time 时间


 


HTTPResponses Summary:HTTP响应摘要


Total:HTTP请求返回数


Per second:每秒请求数


 


Vusers:虚拟用户状态


反映系统形成负载的过程,随着时间推移,虚拟用户数是如何变化的。


 


Rendezvous:负载过程中集合点下的虚拟用户数


 


Errors:错误统计


 


Errorsper Second:每秒错误数


每秒错误数可以了解在每个时间点上错误产生的数目,该数据越小越好,该图可以了解错误随负载的变化情况,到定为何时系统在负载下开始不稳定甚至出错,配合系统统日志可以定为产生错误的原因。


 


Transactions(事务)


AverageTransaction Response Time(平均事务响应时间)


反映随着时间的变化事务响应时间的变化情况,时间越小说明处理的速度越快. 


和用户用户负载生产图合并一起看, 就可以发现用户负载增加对系统事务响应时间的影响规律.增长趋势斜率越低、越稳定越好.



Transactions per Second(每秒事务数)            

另一个关键数据是 TPS 吞吐量,该数据反映了系统在同一时间内能处理业务的最大能力,这个数据越高越好,说明系统处理能力强

这里的最高值并不一定代表系统的最大处理能力, TPS 会受到负载的影响,也会随着负载的增加而逐渐增加,当系统进入繁忙期后,TPS 

会有所下降。




TransactionSummary(事务概要说明)


Transaction Summary 说明给出事务的 Pass 个数和 Fail 个数,了解负载的事务完成情况。


通过的越多,说明系统的处理能力强,失败的事务越少,说明系统越可靠。


Tips:结合每秒错误数进一步分析错误事务原因,及错误发生的时间和该时间产生错误的原因。
 


TransactionPerformance Summay(事务性能概要)


       事务的平均时间、最大时间、最小时间柱状图,方便分析事务响应时间情况。


       柱状图的落差越小说明响应时间的波动较小,如果落差很大,那么说明系统不够稳定。
 


TransactionResponse Time Under Load(在用户负载下事务响应时间)


       在负载用户增长的过程中响应时间的变化情况,该图的线条越平稳,说明系统越稳定。
 


TransactionResponse Time (Percentile) 事务响应时间的百分比


       给出的是不同百分比下的事务响应时间范围,可以了解多少比例的事务发生在某个时间内,也可以发


       现响应时间的分布规律,数据越平稳说明响应时间变化越小。
 


TransactionResponse Time (Distribution) 每个时间段上的事务总数


       给出每个时间段上的事务个数,响应时间较小的分类下的事务数越多越好。


 


WebResources(网页资源信息)


Tips:当 Controller 的 RunTime Setting 中 Preferences 下的 Generated Web performancegraphs选项处于开启状态时,该图才会表现。
 


Hits per Second(每秒点击数)


每秒点击数提供了当前负载中对系统所产生的点击量记录,每一次点击相当于对服务器发出了一次请求,一般点击数会随着负载的增加而增加,该数据越大越好。


是指在一秒钟能做到的点击请求数目, 即客户端产生的每秒请求数(正常情况下每秒点击数等同于服务器请求相应数). 


Throughput(宽带使用)


在当前系统负载下所使用的宽带,该数据越小说明系统的宽带依赖越少,通过这个数据能确定是否出现了网络带宽瓶颈。
 


HTTPResponses per Second(每秒HTTP响应数)


每秒服务器返回各种状态的数目,该数值一般和每秒点击量相同。

点击量是指客户端发出的请求,而 HTTP 响应数是指服务器返回的响应数,如果服务器返回的响应数小于客户端发出的点击数,那么说明服务器无法应答超出负载

的连接请求。

这个数据和每秒点击数吻合,说明服务器能够对每一个客户端请求进行应答。
 


RetriesPer Second(每秒重连接)


       主要反映服务器端主动关闭的连接情况,该数据越低越好,说明服务器端的连接释放越长。
 


Connectionsper Second(每秒连接数)


两种不同状态的连接数,即中断的连接和新建连接,了解当前每秒对服务器产生连接的数量。

同时的连接数越多,说明服务器的连接池越大,当连接数随着负载上升而停止上升时,说明系统的连接池已满,无法连接更多的用户,通常这个时候服务器会返回504 

错误。可修改服务器的最大连接数来解决该问题。


Web Page Diagnostics(网页分析)
当场景中打开 Diagnostics 菜单下 Web Page Diagnostics 功能后, 才能得到网页分析组图。
通过该图, 可以对事务的组成进行抽丝剥茧的分析, 得到组成这个页面的每一个请求的时间分析, 进一步了解响应时间中有关网络和服务器处理时间的分配关系。
可以实现对网站的前端性能分析, 明确系统响应时间较长是由服务器端处理能力不足还是客户端链接到服务器的网络消耗导致的。


1.1 Web Page Diagnostics(网页分析)
该图先会得到整个场景运行后虚拟用户访问 Page 列表, 也就是所有页面下载时间列表。
通过:选择需要细分的页面 选择需要细分的页面 URL

诊断选项(Diagnostics Options) 选项中提供 4 大块功能

1.1.1 Download Time(下载时间)
可以得到组成页面的每个请求下载时间
可以看到某个操作, 如登录操作由几个请求组成, 可以看到各请求之间的情况.

1.1.2 Component(Over time): 组件(随时间变化)
列出组成页面的每个元素, 以及随着时间的变化所带来的响应时间变化.
通过该功能可以分析响应时间变长是因为页面生成慢, 还是因为图片资源下载慢.

1.1.3 Download Time(Over Time): 下载时间(随时间变化)
提供了针对每个组成页面元素的时间组成部分分析, 方便确认该元素的处理时间组成部分.

1.1.4 Time To First Buffer(Over Time): 第一次缓冲时间(随时间变化)
列出元素所使用的时间分配比例, 是受 NetWork Time 影响多还是 Server Time 影响多.

Tips:在以上图中发现 URL 地址全称经常会被省略号填写, 由于场景数据收集默认设置生成的地址长度为 50个字符。
在 LoadRunner 安装目录下找到 LRAnalysis80.ini 文件, 在其中的 [WPB] 下添加 SURLSize=255, 另外还需修改 loader2.mdb 文件, 将其中 Breakdown_map 表中的 EventName 的属性长从 50 修改为 255.

2. Page Download Time Breakdown(页面下载时间细分)
显示每个页面响应时间的组成分析. 一个页面的响应时间包括:
Client Time:客户端浏览器接收所需要使用的时间, 可以不用考虑.

Connections Time:连接服务器所需要的时间, 越小越好.

DNS Resolution Time:通过 DNS 服务器解析域名所需要的时间, 解析受到 DNS 服务器的影响, 越小越好.

ERROR Time:服务器反回错误响应时间, 这个时间反映了服务器处理错误的速度, 一般是 Web 服务器直接反回的, 包含了网络时间和 Web 服务器返回错误的时间, 该时间越小越好.

First Buffer Time:连接到服务器, 服务器返回第一字节所需要的时间, 反映了系统对于正常请求的处理时间开销, 包含网络时间和服务器正常处理的时间, 该时间越小越好.

FTP Authentication Time:FTP 认证时间, 这是进行 FTP 登录等操作所需要消耗的认证时间, 越短越好.

Receive Time:接收数据的时间, 这个时间反映了宽带的大小, 带宽越大, 下载时间越短.

SSL Handshaking Time:SSL加密握手时间.

3. Page Download Time Breakdown(Over Time): 页面下载时间细分(随时间变化)
提供了随着时间的变化所有请求的响应时间变化过程. 将整个负载过程中每个页面的每个时间组成部分做成单独的时间线, 以便分析在不同的时间点上组成该页面的各个请求时间是如何变化的.

Tips:首先找到变化最明显或者响应时间最高的页面, 随后再针对这个页面进行进一步的分析了解时间偏长或者变化较快的原因.

4. Time To First Buffer Berakdown(第一次缓冲时间细分)
提供了组成页面时间请求的比例说明,通过这个图可以直观的了解整个页面的处理是在服务器端消耗的时间长, 还是在客户端消耗的时间长, 从而分析得到系统的性能问题是在前端还是后端.

5. Time To First Buffer Berakdown(Over Time):第一次缓冲时间细分(随时间变化)
提供了整个负载过程中, 每一个请求的 Server Time 和 Client Time 随着时间变化的趋势, 可以方便定位响应时间随着时间变化的原因到底是由于客户端变化导致还是由于服务器端变化导致的.


6. Network Monitor(网络监控)
需要在场景中添加 Network Delay Time 监控后才会得到以下 3 张图.

6.1 Network Delay Time(网络延迟时间)
给出从监控机到目标主机的平均网络延迟变化情况.

6.2 Network sub-Path Time
给出从监控机至目标机各个网络路径的平均时间. 当客户端在连接一个远程服务器时, 路径并不是唯一的, 受到路由器的路由选择, 可能选择不同的路径最终访问到服务器.
提供从监控服务器至目标服务器所经历的路径, 以及每个路径上网络延迟.

6.3 Network Segment Delay Time
给出各个路径上的各个结点网络延迟情况, 这里给出的是路由器和路由器之间的网络延迟情况, 针对连接而不是路径, Network sub-Path Time 针对的是路径.
提供了路由器和路由器之间的网络延迟变化情况, 以便于分析影响整个网络时间的原因及结点.



 

0 0
原创粉丝点击