当前位置:首页 >> IT/计算机 >>

性能测试进阶指南:Loadrunner实战9.1


目录
第 5 章 数据收集分析 Analysis..................................................................................................... 2 5.1 新建 Analysis 分析........................................

................................................................... 2 5.2 Analysis Summary ............................................................................................................ 2 5.2.1 Analysis Summary(场景的摘要) ........................................................................... 3 5.2.2 Statistics Summary(场景状态的统计说明) .......................................................... 3 5.2.3 5Worst Transaction(SLA 失败事务) ...................................................................... 4 5.2.4 Scenario Behavior Over Time(场景行为综述)...................................................... 5 5.2.5 Transaction Summary(事务摘要) ......................................................................... 5 5.2.6 Service Level Agreement Legend(SLA 图标说明) ................................................. 7 5.2.7 HTTP Responses Summary(HTTP 响应摘要) ........................................................ 7 5.3 Graphs(数据图)................................................................................................................ 8 5.3 .1 Vusers(虚拟用户状态)....................................................................................... 10 5.3.2 Errors(错误统计)................................................................................................. 11 5.3.3 Transactions(事务) .............................................................................................. 11 5.3.4 WebResources(网页资源信息) .......................................................................... 15 5.3.5 Web Page Diagnostics(网页分析) ....................................................................... 17 5.3.6 Network Monitor(网络监控) .............................................................................. 22 5.3.7 Resources(资源监控) .......................................................................................... 23 5.4 图设置与操作................................................................................................................ 34 5.4.1 Merge Graphs (合并图) ...................................................................................... 34 5.4.2 Auto Correlate(自动定位瓶颈)........................................................................... 37 5.5 Transaction Report(事务报告) ....................................................................................... 40 5.6 SLA Report(系统阈值监控报告).................................................................................... 42 5.7 External Monitor(外部监控数据导入) .......................................................................... 43 5.8 Cross with result(跨脚本横向比较) .............................................................................. 45 5.9 生成测试报告................................................................................................................ 46 5.9.1 创建 HTML 报告 ................................................................................................. 46 5.9.2 创建 Word 报告 .................................................................................................. 47 5.9.3 创建水晶报表..................................................................................................... 47 小结......................................................................................................................................... 49

第5章

数据收集分析 Analysis

通过场景完成负载后, 我们完成了性能测试的执行过程, 接着就是通过负载的结果来发 现和定位性能瓶颈。在这里 Analysis 就好比一个数据分析中心或数据仓库,它将场景运行中 所能得到的数据都整合在一起, 能够对测试结果数据进行整理, 并提供了一些方法可以进一 步对结果数据进行分析,从而找出系统的性能指标和可能的瓶颈,最终生成报告。 可以把 Analysis 看作一个股票分析软件,将股票的数据收集分析后生成 K 线图,而具体 说明了什么,还要依赖于分析者自身。使用 Analysis 进行性能测试结果的分析流程如图 5.1 所示。

图 5.1 Analysis 结果分析流程

5.1

新建 Analysis 分析

导入场景数据生成 Analysis 报告的方式有以下三种: 1. 当场景运行结束后在场景直接运行 Results 菜单下的 Analyze Results 命令进入 Analysis。 2.在 Analysis 中打开新建菜单,然后进入场景运行结束后的场景结果 res 目录,接着 Analysis 会对整个场景数据进行整理,给出简明报告及相关图表。 3.在场景结果目录中直接双击 Mercury LoadRunner Result(.lrr)文件。

5.2

Analysis Summary

当 Analysis 导入场景数据后,首先映入眼帘的是统计表格 Analysis Summary 场景摘要, 提供了对整个场景数据的简单报告。下面介绍一下该报告的各个组成部分。

5.2.1

Analysis Summary(场景的摘要 场景的摘要) 场景的摘要

这里给出了场景的摘要(Analysis Summary),包括以下内容: ·Period:场景运行的起止时间 ·Scenario Name:场景名称 ·Resultsin Session:场景运行的结果目录 ·Duration:场景运行的时间 通过场景摘要可以了解场景执行的基础信息。

5.2.2

Statistics Summary(场景状态的统计说明 场景状态的统计说明) 场景状态的统计说明

场景状态的统计说明(Statistics Summary)包含以下内容: ·Maximum Running Vusers:场景最大用户数 ·Total Throughput(bytes):总带宽流量 ·Average Throughput(bytes/second):平均每秒带宽流量 ·Total Hits:总点击数 ·Average Hits per Second:平均每秒点击数 单击 View HTTP Responses Summary 选项可以切换到报告的最下端查看 HTTP 请求的统 计。 在每项数据标题和数据中, 还会看到一个小的球形图标囊, 单击后会进入 SLA 分析报告。

5.2.3

5Worst Transaction(SLA 失败事务 失败事务)

这里列出了对 5 大失败事务的统计,只有当在 Controller 或 Analysis 中定义了 SLA status determined at time intervals over a timeline 监控时才会出现该报告。 ·Transaction Name(事务名)。 ·Failure Ratio[%](exceeded time/transaction duration)失败率(超标次数/事务持续时间)。 该值反映了在所有事务中有百分之多少的事务是无法达到 SLA 基准值。 ·Failure Value[%](response time/SLA)失败率(响应时间/SLA)。 该值反映了在整个场景运行下,SLA 的定义标准值与实际事务值超标的平均百分比,也 就是说平均算下来真实的响应时间和定义的阈值误差百分比。 通过这行报告, 我们可以清晰地了解该事务有多少是无法达到 SLA 标准的, 以及无法达 到标准的事务与 SLA 的误差范围是多少。 单击事务名前的加号还能列出该事务在 SLA 定义的持续时间下平均误差比例和最大误 差比例。Analysis 会根据 SLA 中的定义分析事务的通过率,在这个场景结果中,所有的事务 响应时间都在 SLA 监控值以外,所以结果为 Infinity 全部超标。 分析的失败事务数可以在 Tools 菜单下 Options 的 General 标签中进行设置,默认为 5 个事务,如图 5.2 所示。

图 5.2 SummaryReport 设置

5.2.4

Scenario Behavior Over Time(场景行为综述 场景行为综述) 场景行为综述

这里列出了在场景中定义的事务在各个时间点上的 SLA 情况, 背景中的 x 表示在这个时 间点上事务没有达到 SLA 的指标。而上面的 Application Under Test Errors 显示了在每个时间 段上的错误数目。

5.2.5

Transaction Summary(事务摘要 事务摘要) 事务摘要

这里首先给出的是场景中所有事务的情况说明: ·TotalPassed(事务的总通过数) ·TotalFailed(事务的总失败数) ·TotalStopped(事务的总停止数) Average Response Time 是一个链接,可以打开事务平均响应时间图表。

下面给出每个具体事务的情况列表,可以看到以下数据项: ·Transaction Name(事务名) ·SLA Status(SLA 状态):在 SLA 的指标测试中最终结果是通过还是失败 ·Minimum(事务最小时间) ·Average(事务平均时间) ·Maximum(事务最大时间) ·Std.Deviation(标准方差) 标准方差,这个数据是描述采样数据离散状态很重要的指标,它又分为以下两种: 1.给定样本标准方差,它是估算给定样本而不是整个样本的标准方差(也就是样本中的 一部分),计算公式如下:

其中 X 代表平均值, 代表取样个数。n-1 是统计学上的常用做法,主要考虑到采样量 ,n 越大,越能反映真实的情况。 2.总体样本标准方差,它是估算整个采样样本的标准方差(注意是整个采样数据而不是 部分),计算公式如下:

当采样数据足够大的时候,上述两种计算方式得出的偏差相差很小。 标准方差相对于平均值越大,说明数据越离散,则分布状态相对于平均值波动很大;标 准方差相对于平均值越小,说明数据分布越集中,曲线也越平稳。在采样值服从正态分布的 条件下通过上面的指标结合平均值、最大值、最小值,可以比较清楚地知道采样数据的分布 状态及其是否有较大的波动。 ·90Percent(用户感受百分比) 这个值说明的采样数据中有 90%的数据比它小,有 10%的数据比它大,举例如下: 假设有一组数据(1、3、4、6、5、7、8、2、9、10),从小到大排序之后为(1、2、3、4、 5、6、7、8、9、10),在这 10 个数字中第九大的数字是 9,所以 90 Percent 的结果就是 9。 它的主要作用就是来了解在某个响应时间内有百分之多少的用户。当然这个 90%是可调整

的,在 Analysis 中通过 View 菜单中 SummaryFilter 下的 Transaction Percentile 选项来调整。 ·Pass(事务通过数) ·Fail(事务失败数) ·Stop(事务停止数)

5.2.6

Service Level Agreement Legend(SLA 图标说明) 图标说明

图标为灰色带减号的 据;图标为红色带叉的

为 No Data,说明在 SLA 中未对这个数据项进行监控,没有数 为 Fail,说明在 SLA 中定义了该项的数据监控,但该数据未能达 为 Pass,说明在 SLA 中定义了该项的数据监控,该数

到期望的阈值;图片为绿色带钩的 据达到了的期望阈值。

5.2.7

HTTP Responses Summary(HTTP 响应摘要 响应摘要)

这里给出了服务器返回的状态。 ·服务器返回 HTTP 请求状态(HTTP Responses,具体的服务器返回状态码见附录 A) ·HTTP 请求返回次数(Total) ·每秒请求数(Per second) 通过 Analysis Summary 可以对整个性能测试的结果有一个直观的介绍,特别是通过 SLA 的数据可以直观地了解在整个负载中系统的性能指标是否满足阈值, 除此以外设置的事务响 应时间数据也会显示。 Analysis 保存后会生成 Mercury LoadRunner Analysis Session(. lra)文件。 通过 File 菜单下的 Session Information 功能可以了解该 Session 文件的属性, File 菜单下的 而 View Scenario RunTime Settings 功能可以查看该报告场景的运行设置。当粗略了解了整个场 景的情况后,根据场景执行前的目标,可以对整个系统的性能有一定的了解,接着需要对关 心的数据进行进一步的了解和分析。

5.3

Graphs(数据图 数据图) 数据图

在场景运行时可以看到一些图, 这些图将场景中的数据转化为折线图, 方便我们了解当 前该数据的状态。在默认情况下,Analysis 会自动打开如图 5.3 所示的几张图。 这是系统最基本的几个图, 这些图反映了在不同时间段相关计数器的数据变化情况, 可 以通过在 Graphs 上右键菜单中的 Add New Graphs 命令完成添加图的操作,添加后弹出 Graphs 管理器,如图 5.4 所示。 在 Open a NewGraph 窗口中, 可以得到所有能添加的计数器图形, 勾选左下角的 Display only graphs containing data 选项可以隐藏没有数据的计数器,有数据的计数器则会以蓝色显 示在左侧区域。而选中具体的图,在右侧的 Graph Description 中会有更加详细的介绍。在 Graph Properties 中还可以对生成的图表进行一定的属性设置,例如生成的图是使用整个场 景的时间还是其中的某一部分时间。

图 5.3 默认情况下系统打开的 Graphs

图 5.4 数据图管理器

对于任意一张图,都可以在右侧看到有 2 个功能:User Notes 和 Raw Data。UserNotes 提供对某张图进行文字描述的功能;Raw Data 是将生成该图的数据列出。 在 RawData 中单击 Click to retrieve raw data,会弹出 Raw Data 窗口,设置场景持续的时 间,确认后可以得到该时间段内组成该图的所有数据,如图 5.5 所示。

图 5.5 RawData 数据表 这里可以将数据另存为 Excel 文件,再通过第三方工具进行分析。例如将导出的场景数 据使用 SPSS 工具进行进一步的数学分析。在图的下方,Legend 窗口会显示图中对象说明信 息以及相关数据,如图 5.6 所示。 通过对显示对象的一些设置,可以得到更好的显示效果。在 Legend 窗口中单击鼠标右 键,弹出菜单如图 5.7 所示。

图 5.6Legend 图中对象数据说明

图 5.7Legend 设置选项菜单 可以通过 Show/Hide/Show only selected/Show all 命令设置所需要选的项目, 也可以通过 Configure measurements/Show measurement description 命令设置线条的颜色及显示方式。 Animate selected line 选项可以在切换线条时获得更加明显的动画效果,Auto Correlate 提供 了对所选对象的自动关联操作(参考 5. 2 节), 4. 而在 Configure columns 中可以设置在 Legend 中显示哪些属性名。 每张图都代表了场景运行中监控到的数据变化趋势, 所以看懂每一张图的含义是性能分 析的第一步,接着我们来介绍一些常见图的含义。

5.3 .1

Vusers(虚拟用户状态 虚拟用户状态) 虚拟用户状态

Vusers 用户状态计数器组提供了产生负载的虚拟用户运行状态的相关信息, 可以帮助我 们了解负载生成的过程。 Running Vusers(负载过程中的虚拟用户运行情况 负载过程中的虚拟用户运行情况) 负载过程中的虚拟用户运行情况 该图可以反映系统形成负载的过程,随着时间的推移,虚拟用户数是如何变化的。 在图 5. 中可以看到用户在 9 分钟左右到达了负载峰值 50 个虚拟用户, 8 负载的生成是 大约每分钟增加 5 个用户,峰值负载持续 1 分 30 秒。

图 5.8 Running Vusers Rendezvous(负载过程中集合点下的虚拟用户数 负载过程中集合点下的虚拟用户数) 负载过程中集合点下的虚拟用户数 当场景中设置了集合点后会出现这张图, 该图反映了随着时间的推移各个时间点上并发 用户的数目,方便我们了解并发用户数的变化情况。在图 5.9 中可以看到刚开始的 7 分钟 内,负载的并发用户都是 1 个,而后面变化为 2 个用户并发。

图 5.9 Rendezvous

5.3.2

Errors(错误统计 错误统计) 错误统计

当场景在运行中出现错误时,错误信息将会被保存在该计数器组中,通过 Error 信息可 以了解错误产生的时间和错误的类型,帮助我们定位产生错误的原因。 Errors per Second(每秒错误数 每秒错误数) 每秒错误数 通过每秒错误数可以了解在每个时间点上错误产生的数目, 该数据越小越好。 通过这个 图可以了解错误随负载的变化情况, 定位何时系统在负载下开始不稳定甚至出错, 配合系统 日志可以定位产生错误的原因。 在图 5.10 中可以看到场景在 37 秒的时候出现了一次错误。

图 5.10 Errors per Second

5.3.3

Transactions(事务 事务) 事务

这里给出了所有和事务相关的数据统计, 方便了解被测系统业务处理的响应时间和吞吐 量,在 3.9 节中介绍了系统事务默认有 3 种状态 PASS、FAIL、STOP,如果是手工事务那么 状态会有 PASS 和 FAIL 两种。 Average Transaction Response Time(平均事务响应时间 平均事务响应时间) 平均事务响应时间 这是我们比较关心的数据之一, 反映随着时间的变化事务响应时间的变化情况, 时间越 小说明处理的速度越快。 如果和前面的用户负载生成图合并在一起看, 就可以发现用户负载 增加对系统事务响应时间的影响规律。 在图 5.11 中可以看到响应时间是如何增长的,随着时间的推移响应时间逐渐变长,并 且在不到 8 分钟的时候突然出现响应时间大幅下降的情况。

图 5。11 Average Transaction Response Time 另外事务的响应时间也不应该超过用户的最大接受范围, 否则会出现系统响应过慢的问 题。 Transactions per Second(每秒事务数 每秒事务数) 每秒事务数 另一个关键数据是 TPS 吞吐量, 该数据反映了系统在同一时间内能处理业务的最大能力, 这个数据越高,说明系统处理能力越强。 在图 5.12 中上面的线是通过的事务,下面的线是失败的事务,这里可以看到系统的 TPS 随着时间的变化逐渐变大, 而在不到 10 分钟的时候系统每秒可以处理 1.9 个事务。 这里 的最高值并不一定代表系统的最大处理能力,TPS 会受到负载的影响,也会随着负载的增加 而逐渐增加,当系统进入繁忙期后,TPS 会有所下降。而在 4 分钟以后开始出现少量的失败 事务。

图 5.12 Transactions per Second TransactionSummary(事务概要说明 事务概要说明) 事务概要说明 该说明给出事务的 Pass 个数和 Fail 个数,了解负载的事务完成情况。通过的事务数越 多,说明系统的处理能力越强;失败的事务越少,说明系统越可靠。 在图 5.13 中可以看出,对于 reg 注册操作一共有 613 次操作成功,有 6 次失败。可以 考虑结合前面的每秒错误数进一步分析为什么会出现 6 个注册错误, 以及错误发生的时间和 该时间产生错误的原因。

图 5.13 Transaction Summary Transaction PerformanceS ummary(事务性能概要 事务性能概要) 事务性能概要 这里会给出事务的平均时间、最大时间、最小时间柱状图,方便分析事务响应时间的情 况。在图 5.14 中可以看到 reg 这个事务最大时间为 3.897s,最小时间为 2.555s,平均时间为 2.924s。柱状图的落差越小说明响应时间的波动较小,如果落差很大,那么说明系统不够稳 定。

图 5.14 Transaction Performance Summary Transaction Response Time Under Load(在用户负载下事务响应时间 在用户负载下事务响应时间) 在用户负载下事务响应时间 这里给出了在负载用户增长的过程中响应时间的变化情况,其实这张图也是将 Vusers 和 Average Transaction Response Time 图做了一个 Correlate Merge 得到的,该图的线条越平 稳,说明系统越稳定。在图 5.15 中可以看出在负载逐渐增加到 5 个用户时,事务的响应时 间基本没有变化。 而用户增加到 15 个开始, 随着用户负载的增加响应时间也有较大的波动。

图 5.15 Transaction Response Time Under Load Transaction Response Time(Percentile)(事务响应时间的百分比 事务响应时间的百分比) 事务响应时间的百分比 这里给出的是不同百分比下的事务响应时间范围, 通过这个图可以了解有多少比例的事 务发生在某个时间内, 也可以发现响应时间的分布规律, 数据越平稳说明响应时间变化越小。 在图 5.16 中可以看到 60%的事务是在 3 秒内。

图 5.16 Transaction Response Time(Percentile) Transaction Response Time(Distribution)(每个时间段上的事务数 每个时间段上的事务数) 每个时间段上的事务数 该图给出的是在每个时间段上的事务个数,响应时间较小的分类下的事务数越多越好。 从图 5.17 中可以看到在所有的事务中,有 391 个事务的响应时间最接近 2 秒,而有 222 个 事务的响应时间最接近 3 秒。

图 5.17 Transaction Response Time(Distribution)

5.3.4

WebResources(网页资源信息 网页资源信息) 网页资源信息

这里给出的是对于 Web 操作的一些基本信息,这些信息在服务器端也能获得。当 Controller 的 RunTime Setting 中 Preferences 下的 Generated Web performance graphs 选项处 于开启状态时,该图表才会出现。 Hits per Second(每秒点击数 每秒点击数) 每秒点击数 每秒点击数提供了当前负载中对系统所产生的点击量记录。 每一次点击相当于对服务器 发出了一次请求,一般点击数会随着负载的增加而增加,该数据越大越好。 在图 5.18 中可以看出随着时间的增加,每秒点击数在上升,最高达到 78 次/s。

图 5.18 Hits per Second Throughput(带宽使用 带宽使用) 带宽使用 这里给出了在当前系统负载下所使用的带宽, 该数据越小说明系统的带宽依赖越小, 通 过这个数据能确定是否出现了网络带宽的瓶颈(注意这里使用的单位是字节)。 在图 5.19 中可以得到最高的带宽峰值是 355000B, 远远低于 100Mb 的局域网带宽上限, 所以系统不存在带宽瓶颈。

图 5.19 Throughput

HTTP Responses per Second(每秒 HTTP 响应数 响应数) 每秒 这里给出了每秒钟服务器返回各种状态的数目, 该数值一般和每秒点击量相同。 点击量 是指客户端发出的请求数,而 HTTP 响应数是指服务器返回的响应数。如果服务器返回的响 应数小于客户端发出的点击数,那么说明服务器无法应答超出负载的连接请求。在图 5.20 中可以看到最高峰时服务器每秒能返回接近 75 个 HTTP 200 OK 的状态。

图 5.20 HTTP responses per Second 这个数据和前面的每秒点击数吻合,说明服务器能够对每一个客户端请求进行应答。 Connections Per Second(每秒连接数 每秒连接数 每秒连接数) 这里会给出两种不同状态的连接数, 即中断的连接和新建的连接, 方便用户了解当前每 秒对服务器产生连接的数量。 在图 5.21 中可以看到随着时间的推移,系统的连接数逐步上升,最高达到每秒 4 个连 接。

图 5.21 Connections Per Second 同时的连接数越多,说明服务器的连接池越大,当连接数随着负载上升而停止上升时, 说明系统的连接池已满,无法连接更多的用户,通常这个时候服务器会返回 504 错误。可以 通过修改服务器的最大连接数来解决该问题。

5.3.5

Web Page Diagnostics(网页分析 网页分析) 网页分析

当在场景中打开 Diagnostics 菜单下的 Web Page Diagnostics 功能,就能得到网页分析组 图。通过这个图,可以对事务的组成进行抽丝剥茧的分析,得到组成这个页面的每一个请求 时间分析,进一步了解响应时间中有关网络和服务器处理时间的分配关系。通过这个功能, 可以实现对网站的前端性能分析,明确系统响应时间较长是由服务器端(后端)处理能力不足 还是客户端连接到服务器的网络(前端)消耗导致的。更多内容参考 6.1.5 节中的前端性能分 析。 Web Page Diagnostics(网页分析 网页分析) 网页分析 添加该图先会得到整个场景运行后虚拟用户访问的 Page 列表,也就是所有页面下载时 间列表。这里对 Discuz.Net 论坛的注册用户事务进行分析。在图 5.22 中可以看到整个负载 由 3 个页面请求组成,其中有一个请求始终在 0.8 秒以内,而另外 2 个请求时间较长并且有 上升趋势。

图 5.22 Web Page Diagnostics 然后通过 Select Page to Break Down 命令选择具体的 Page 来获得每个请求的相关详细信 息。这里选择创建用户的“172.168…x?createuser=1”请求进行分析。稍后可以在图 5.23 中 看到创建用户响应时间的变化,随着时间的增长响应时间从 2.6 秒上升到了 3.9 秒,并且在 7 分 30 秒时大幅下滑,回到 2.6 秒左右。

图 5.23 Web Page Diagnostics 对用户注册页面细分

在 Diagnostics options 选项中提供了以下 4 大块功能。 下载时间分析) ·Download Time(下载时间分析 下载时间分析 这里可以得到组成页面的每个请求下载时间。 在图 5.24 中可以看到创建用户的操作由 4 个请求组成, 其中导致注册用户较慢的主要原因是注册完成后需要等待两秒钟再刷新至论坛 首页,而非注册用户本身需要消耗的时间。首页刷新慢也只是因为 Client(客户端)需要消耗 较多时间,同时 Receive(接收)的时间也有一定的影响。

图 5.24 Web Page Diagnostics Download Time 各模块的时间变化) ·Component(Over time)(各模块的时间变化 各模块的时间变化 这里列出组成页面的每个元素, 以及随着时间的变化所带来的响应时间变化。 通过这个 功能可以分析响应时间变长是因为页面生成慢,还是因为图片资源下载慢。在图 5.25 中可 以发现随着时间的增加, 首页的处理时间(最上面的一根线)从 0.5 秒上升到了最大值 1. 秒, 6 而注册用户响应时间几乎没有上升。

图 5.25 Web Page Diagnostics Component(Over Time) 模块下载时间) ·Download Time(Over time)(模块下载时间 模块下载时间 这里提供了针对每个组成页面元素的时间组成部分分析, 方便确认该元素的处理时间组 成部分。在图 5.26 中可以发现首页请求的下载时间主要消耗在 Client 上,而 7 分 30 秒之 前 Recevie 所消耗的时间在逐渐变长。

图 5.26 Web Page Diagnostics Download Time(Over Time).

模块时间分类) ·Time to First Buffer(Over time)(模块时间分类 模块时间分类 这里会列出该元素所使用的时间分配比例, 是受 Network Time 影响的多还是 ServerTime 影响的多。在图 5.27 中可以看出,对于首页刷新的响应时间来说,主要是 NetworkTime 网 络上消耗的时间,而 Server Time 服务器端的处理是非常优秀的。ServerTime 是指服务器对 该页面的处理时间;Network Time 是指网络上的时间开销。

图 5.27 WebPage Diagnostics Time to First Buffer(Over time) 通过这 4 个分析图, 我们可以了解到对于事务的响应时间来说, 服务器的处理时间并不 是组成响应时间的主要部分,而网络问题通常会占用超过 70%的时间,通过 Web Page Diagnostics 可以准确分析响应时间, 避免由于网络延迟或者带宽问题而影响对响应时间的分 析和瓶颈定位。

在 LoadRunner 的安装目录下找到 LRAnalysis80.ini 文件,在其中的[WPB]下添加 SURLSize=255, 另外还需要修改 loader2.mdb 文件, 将其中 Breakdown-map 表中的 EventName 的属性长度从 50 修改为 255,在以后场景运行结果的报告中就可以显示最长为 255 字符的 路径名称了。 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 加密握手的时间。而 Analysis 在这里会分析得到页面请求的组成比例图,便于分析 页面时间浪费在哪些过程中。在图 5.28 中可以看到各个页面请求的响应时间组成情况,相 对于 172.168.0.200 的首页请求,时间主要浪费在 Client 上。

图 5.28 Page Download Time Breakdown Page Download Time Breakdown(Over Time)(页面组成部分时间 页面组成部分时间) 页面组成部分时间 这里提供了随着时间的变化所有请求的响应时间变化过程。 这里会将整个负载过程中每 个页面的每个时间组成部分都做成单独的时间线, 以便分析在不同的时间点上组成该页面的 各个请求时间是如何变化的。在图 5.29 中可以看到大多数页面的响应时间是比较稳定的, 其中首页刷新变动较大。

图 5.29 Page Download Time Breakdown(Over Time)

首先找到变化最明显或者响应时间最高的页面, 随后再针对这个页面进行进一步的分析 了解时间偏长或者变化较快的原因。 Time to First Buffer Breakdown(页面请求组成时间 页面请求组成时间) 页面请求组成时间 这里提供了组成页面时间请求的比例说明(客户端时间/服务器时间), 通过这个图, 我们 可以直观地了解到整个页面的处理是在服务器端消耗的时间长, 还是在客户端消耗的时间长, 从而分析得到系统的性能问题是在前端还是在后端。 在图 5.30 中可以看出对于整个负载来说,网络或客户端的时间开销占了绝大多数。 Time to First Buffer Breakdown(Over Time)(基于时间的页面请求组成分析 基于时间的页面请求组成分析) 基于时间的页面请求组成分析 和图 5. 不同的是, 30 这里给出了在整个负载过程中, 每一个请求的 Server Time 和 Client Time 随着时间变化的趋势,可以方便定位响应时间随着时间变化的原因到底是由于客户端 变化导致的还是由于服务器端变化导致的。

图 5.30 Time to First Buffer Breakdown 在图 5. 中可以看到对于用户注册操作, 31 网络上的时间变化比服务器上的时间变化要剧烈。

图 5.31 Time to First Buffer Breakdown(Over Time)

5.3.6

Network Monitor(网络监控 网络监控) 网络监控

如果在 Controller 中添加了 Network Delay Time 监控后会出现该数据图。这个功能很好 但并不是非常直观和方便,建议使用第三方专门的路由分析工具进行网络延迟和路径分析。 Network Delay Time 这里会给出从监控机至目标主机的平均网络延迟变化情况。 在图 5. 中可以看到网络 32 延迟从 240 毫秒逐渐减少到 26 毫秒,最后上升到 340 毫秒。

图 5.32 Network Delay Time Network Sub-Path Time 这里给出从监控机至目标机各个网络路径的平均时间。 当客户端在连接一个远程服务器 时, 路径并不是唯一的, 受到路由器的路由选择, 可能会选择不同的路径最终访问到服务器。 在图 5. 中列出了从监控服务器至目标服务器所经历的路径, 33 以及每个路径上的网络延迟。

图 5.33 Network Sub-Path time

Network Segment Delay Time 这里给出各个路径上的各个节点网络延迟情况。和图 5.33 不同的地方在于,这里给出 的是路由器和路由器之间的网络延迟情况,针对连接而不是路径。 图 5. 中给出了路由器和路由器之间的网络延迟变化情况, 34 以便于分析影响整个网络 时间的原因及节点。

图 5.34 Network Segment Delay Time

5.3.7

Resources(资源监控 资源监控) 资源监控

资源包括很多种,在 Analysis 中监控的都是各种系统的计数器,这些计数器反映了系统 中硬件或者软件的运行情况,通过它可以发现系统瓶颈。 System Resources(系统资源 系统资源) 系统资源 这里给出了对操作系统计数器的监控, 列出了在负载过程中系统的各种资源数据是如何 变化的,该图需要在场景中设置了对应系统的监控后才出现。 Database Server Resources(数据库资源 数据库资源) 数据库资源 这里给出了数据库的相关资源在负载过程中的变化情况。 Web Server Resources(Web 服务器资源 服务器资源) 这里给出了 Web 服务器资源在负载过程中的变化情况。对于各种资源类的图来说,最 困难的是理解各个计数器的含义。 好比体检时会涉及血液化验, 当一张血液化验单放在你面

前时, 普通用户是无法理解化验结果数据所反映的含义, 现在通常会在化验报告单上简单介 绍各个检查项目的含义,红细胞一般是在什么范围内,如果少了说明贫血。当进行性能瓶颈 定位时,必须掌握常见各种计数器的含义和可能导致该结果的原因。 计数器分析 接着介绍一下各种在性能测试中需要监控的常见计数器名称及其含义和出现瓶颈的特 征,供大家参考,更为具体的内容请参考各种应用的专用调优手册和计数器手册。 如何获得硬件计数器瓶颈或者各种计数器瓶颈数据? 可以先通过第三方工具对系统进行负载,监控在该负载下各个计数器的最高值是多少。 当用 LoadRunner 进行负载时,如果该计数器达到该数据,则可以说明这个计数器出现了瓶 颈。例如:通过磁盘工具对物理磁盘进行压力测试,在这个过程中可以监控到物理磁盘的读 写速度计数器峰值为 x。当我们用 LoadRunner 进行负载时,如果物理磁盘读写计数器数据 逐步变大且最终达到 X,就可以说明物理磁盘出现读写瓶颈。 CPU 监控常用的计数器及含义如表 5.1 所示。 表 5.1 CPU 常用计数器

内存监控常用的计数器及含义如表 5.2 所示。

表 5.2 内存常用计数器

物理磁盘监控常用的计数器及含义如表 5_3 所示。 表 5.3 物理磁盘常用计数器

线程监控常用的计数器及含义如表 5.4 所示。 表 5.4 线程常用计数器

进程监控常用的计数器及含义如表 5.5 所示。 表 5.5 进程常用计数器

SQL Server 监控常用的计数器及含义如表 5.6 所示。 表 5.6 SQL Server 常用计数器

Web Service Cache 服务缓存监控常用的计数器及含义如表 5.7 所示。 表 5.7 服务缓存常用计数

IIS 监控常用的计数器及含义如表 5.8 所示。 表 5.811$常用计数器

网络监控常用的计数器及含义如表 5.9 所示。 表 5.9 网络常用计数器

ASP.NET 监控常用的计数器及含义如表 5.10 所示。 表 5.10 ASP.NET 常用计数器

Apache 监控常用的计数器及含义如表 5.11 所示。 表 5.11Apache 常用计数器

MySQL 监控常用的计数器及含义如表 5.12 所示。

表 5.12 MySQL 常用计数器

Oracle 监控常用的计数器及含义如表 5.13 所示。 表 5.13 Oracle 常用计数器

WebLogic 监控常用的计数器及含义如表 5.14 所示。 表 5.14 WebLogic 常用计数器

5.4

图设置与操作

在 Analysis 中经常需要和各种图打交道,那么我们需要对图的常见功能设置有所了解, 在图上可以单击鼠标右键打开设置菜单,对图形进行一定的设置。 图的过滤规则设置) ·SetFilter/GroupBy(图的过滤规则设置 / 图的过滤规则设置 不同图的设置是不同的,主要是根据某些属性进行一定的过滤,来方便显示。 图的采样点间距) ·SetGranularity(图的采样点间距 图的采样点间距 Analysis 会自动根据场景运行的时间来设置数据采样点的间距, 单位为秒。 采样点越小, 越能反映数据微小的变化;而采样点越大,则能反映系统在大趋势上的表现。 打开鼠标指针) ·View Cursor(打开鼠标指针 打开鼠标指针 为鼠标在图中添加横向和纵向的标尺,方便了解鼠标所在位置的横坐标和纵坐标。 打开图所对应的数据) ·View Raw Data(打开图所对应的