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

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



性能测试进阶指南: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(打开图所对应的数据 打开图所对应的数据 注释) ·Comments(注释 注释 在图中添加注释,便于说明某些问题。 去掉所有的显示选项) ·Clear Display Options(去掉所有的显示选项 去掉所有的显示选项 该选项可以回到最原始的数据图模式,去掉所有的过滤和显示设置。 显示方式选项) ·Display Options(显示方式选项 显示方式选项 设置图的显示方式,通过这个选项可以将图调整得更加好看,例如将图转化为 3D 模式 或调整线条颜色及背景颜色等。

5.4.1

Merge Graphs (合并图 合并图) 合并图

当得到了相关图形,如何分析图和图之间的关系呢?MergeGraphs 提供了一种将图和图 合并的功能,通过这个功能可以直观地获得一个数据和另外一个数据的相互影响关系。 在 RunningVusers 图中,单击鼠标右键,在菜单中选择 MergeGraphs, 如图 5. 所示。 35 Merge 的方式有 3 种:Overlay、Tile、Correlate,如图 5.36 所示。 这 3 种合并方法可以帮助我们对测试结果进行分析,了解图和图之间的影响关系。 Overlay 基于 Overlay 合并方式,就是将两张图通过 x 轴进行覆盖合并。例如将 RunningVusers 和 AverageTransactionResponseTime 进行 Overlay 合并,如图 5.37 所示。

图 5.35 Merge Graphs

图 5.36

Merge 方式设置

图 5.37 Overlay 的 Merge 方式 通过这张图可以得到用户增长的过程是如何影响事务平均时间的, 从而发现瓶颈出现的 时间。 Tile Tile 的模式和 Overlay 的方式非常接近,只是将两张图的 y 轴分了上下两部分,不做重 叠。 将 Running Vusers 和 Hits per Second 进行 Tile 合并,如图 5.38 所示。

图 5.38 Tile 的 Merge 方式 通过这个合并,可以看到随着用户数量增加每秒点击量的变化过程,从而了解在当前 负载下系统承受的点击量峰值。相对于 Overlay 方式,两张图的线条不会重叠在一起,看起 来更加清楚。 Correlate 这个合并比较复杂,首先将主图的 Y 轴变为 x 轴,而被合并图的 y 轴依然保存为 y 轴, 按照各图原本的时间关系进行合并形成新图。 例如这里将 Running Vusers 和 Transactions per Second 两张图进行 Correlate 合并,如图 5.39 所示。

图 5.39Correlate 的 Merge 方式 系统将 Running Vusers 图的 Y 轴作为新图的 x 轴, Transactions per Second 图的 y 轴作 将 为新图的 y 轴。在通过 Correlate 方式合并后的图中,可以更加清晰地看出用户变化导致处

理能力的变化过程, 斜率越大说明影响越大, 方便快速定位在何种负载下系统响应时间能够 稳定,而在何种负载下响应时间会大幅上升。 通过这几种常见的 Merge 方法,可以将相关计数器得到的图进行合并分析,找出系统 性能的瓶颈。 由于系统瓶颈的定位需要大量的相关知识, 对于一个初级性能测试工程师来说, 并不要求有性能结果分析和性能瓶颈定位的能力。 初级性能测试工程师可以将数据整理后提 交给项目经理、 网络或数据库管理员, 让他们帮助你分析数据, 并确认及完成性能调优工作。

5.4.2

Auto Correlate(自动定位瓶颈 自动定位瓶颈) 自动定位瓶颈

Auto Correlate 提供了自动分析趋势影响的功能,通过它可以方便地找出哪些数据之间 有明显的相互依赖性,通过图和图之间的关系确认系统资源和负载相互影响的关系。 首先找到需要自动关联的图, 右键打开 Auto Correlate 菜单。 例如选择从 Running Vusers 图上做自动关联,如图 5.40 所示。 弹出自动关联窗口,如图 5.41 所示。我们需要进行以下设置。 1.Time Range . 设置关联的时间范围标签。 Suggest Time Range by 提供了自动关联的范围参考,可以选择 Trend 基于趋势或者选择 Feature 基于特征两种方式。这两种方式可以自动选择关联的范围,Trend 完整包含所有值得 注意、 分析的趋势, Feature 则是其间一个单独的片段。 而 例如这里选择 Feature, 如图 5. 42 所示。

图 5.40 Auto Correlate

图 5.41 Auto Correlate 设置

图 5.42 Auto Correlate 设置基于 Feature 特征的时间方式 右侧的竖线就会换到 6 分钟的位置, 因为从 0 分到 6 分是用户负载上升的阶段, 这个阶 段的特征就是增加。通过单击 Next 按钮可以切换到下一个特征,下一个特征是 6 分 40 秒至 7 分 04 秒的负载下降阶段,如图 5.43 所示。

图 5.43 Auto Correlate 设置基于 Feature 特征的时间方式切换 可以通过拖动图中的两根竖线来确定关联的范围或直接修改 From 后的时间来调整关联 的范围。这样就确认了希望关联的时间范围,接着需要设置被关联的对象。 2.Correlation Options . 切换到 Correlation Options 标签,这里列出了所有和当前图可以进行关联的对象,默认 选择了 3 个资源图,用户也可以自行设置需要关联的图,另外可以在 Data Interval 中设置数 据点的间隔和 Output 中的输出情况,如图 5.44 所示。

图 5.44 Auto Correlate 关联选项 Data Interval 是指自动关联的数据间隔,默认为 5 秒钟,也可以手工设定关联的数据间 隔。间隔的时间设置越小得出的关联匹配度越精确。 Output 是对输出关联结果的设置,可以选择设置显示和被关联图匹配值最高的 5 个对 象,也可以设置显示所有和被关联图匹配值大于 50%的对象。 这里修改 Select measurement categories 选择对象为 Hits per Second, 其他选项保持默认 值,确定后得到最终的自动关联结果,如图 5.45 所示。

图 5.45 Auto Correlate 关联结果 在结果中可以看到用户数量增加和每秒点击量的关系, 这和做一个 Run Vuser 和 Hits per Second 计数器的 overlay 型的 Merge 操作没什么区别。但在面的数据中可以看到 Collrelation Match 数据项,这个项目是自动关联独有的。Correlation Match 是指关联匹配度,该值反映

了主数据和被关联数据的近似度。这里 Hits per Second 和被关联图 Running Vuser 的近似度 为 95%,也就是说这两个数据变化的规律非常接近。 通过单击右上角的 Settings 按钮可以重新设置自动关联选项。通过设置 Correlation Options 下的 Data Interval 和 Output 来改变自动关联的结果,找到和被关联对象波动接近的 对象,进一步分析各个数据问的影响关系,从而确认瓶颈产生的原因。 AutoCorrelation 与 Merge 的区别在于:Merge 不能“选定特定的时间进行切片” ,所以 可先用 Merge 看整体趋势、分析全局。找到恰当的位置后,再使用 AutoCorrelation 切片, 进一步分析。Merge 的输出没有 CorrelationMatch 这个值(即使使用了 Merge 的 Correlate 选 项), 也没有 Correlation 值来说明两个数据间的关系。 Merge 一次只能对一张图做合并操作, 而 AutoCorrelation 可以一次对多张图做合并。

5.5

Transaction Report(事务报告 事务报告) 事务报告

这 里 提 供 了 对 每 个 事 务 进 行 更 加 精 细 分 析 的 功 能 , 通 过 打 开 菜 单 Reports 下 的 AnalyzeTransaction 选项或者单击工具栏上的鲤按钮,添加对事务的分析报告,如图 5.46 所示。

图 5.46 Transaction Report 系统提供了事务响应时间、带宽和每秒点击量的合并选项,通过这个功能,可以比以前 更 加 方 便 地 完 成 事 务 响 应 时 间 和 相 关 计 数 器 的 Merge 和 AutoCorrelate 操 作 。 单 击 Generatedreport 按 钮 后 就 可 以 生 成 对 应 的 transaction 报 告 , 如 下 所 示 。

A snapshot of the selected transaction and time range

在报告中会给出所有和事务平均响应时间相关的计数器, 并且自动计算各个合并图中相 似度较高的计数器,而这些相似度较高的计数器就是系统可能存在的瓶颈。

5.6

SLA Report(系统阈值监控报告 系统阈值监控报告) 系统阈值监控报告
场景中设置的 SLA 信息转化为报告,可以得到各个 SLA 阈值是否能够达到,或者在每

个时间段上哪些时间能够达到预订的指标,哪些不行。报告分为以下两大段: ·基于指标型的 SLA 监控 系统的某一项数据能否达到预设的目标,达到即提示成功,否则提示失败。 ·基于时间段上的 SLA 监控 给出系统在各个时间段上是否满足预设的目标。

这里可以看到平均带宽吞吐量的目标为 5000B/s,而系统实际吞吐量为 196098B/s, 完全能够达到 SLA 的目标,所以 SLA 状态为通过。

而在 Transaction response time 报告中可以发现在有些时间上 sLA 指标无法通过,而在 另外一些时间上 SLA 却是 PASS 状态,这是由于定义目标导致的,下面是制定目标。

在这里定义的目标如下: ·lO 个用户以下:响应时间 1 秒内 ·10~20 个用户:响应时间 2 秒内 ·20~30 个用户:响应时间 3 秒内 ·30 个用户:响应时间 5 秒内 最后可以知道在各个时间段上哪些是达到了这个阶段的响应时间目标,哪些没有。 使用 Tools 菜单下的 ConfigureSLARules 命令可以对场景中定义的 SLA 监控进行新增和修 改。修改后,所有报告中的数据都会重新运算。

5.7

External Monitor(外部监控数据导入 外部监控数据导入) 外部监控数据导入

虽然 Controller 支持绝大多数应用的计数器监控,但如果遇到无法监控的内容,Analysis 的分析效果就会大打折扣,而这个问题惠普公司也意识到了,通过 External Monitor 功能, 就可以导入白行定义的计数器监控结果,来实现统一的性能测试分析。 打开 Tools 菜单下的 External Monitor 功能,选择 Import Data,如图 5.47 所示。 Analysis 支持 6 种默认格式的外部监控数据, 还提供了自定义的文件格式(Windows 2008

为自定义文件格式)。这里添加服务器上生成的监控文件(如何生成监控文件将在 6.1.4 节中 详细介绍),如图 5.48 所示。

图 5.47 导入数据窗口

图 5.48 添加需要导入的数据

由于在生成监控时使用 Windows 2003 的.CSV 格式,所以这里选择 Win2K Performance Monitor(*.csv)格式, 然后单击 Next 按钮。 接着选择该数据所属的计数器类型, 选择 Windows Resources 后单击 Finish 按钮,如图 5.49 所示。稍等片刻后即可看到添加成功的信息,如 图 5.50 所示。

图 5.49 设置导入数据存放在哪类计数器内

图 5.50 导入数据成功

如何区分导入 Windows Resources 和 Controller 添加的 Windows Resources 呢?在 Analysis 中是通过机器名来区分的。 选择添加图,找到 WindowsResources,注意在右侧的 HostName 中会出现选项,可以选

择将所有的计数器添加到图中,也可以单独选择某一台主机资源信息,如图 5.51 所示。 这样就可以将各个主机在负载下的资源信息添加到 Analysis 里, 即便没有相关监控计数 器的 License(对于 Linux 下的某些服务监控特别有效)。

图 5.51 导入数据 Host Name 过滤

5.8

Cross with result(跨脚本横向比较 跨脚本横向比较) 跨脚本横向比较

当性能测试数据生成后, 如何去做基准和配置测试呢?File 菜单下的 Crosswithresult 命令 提供了多场景结果组合分析的功能,如图 5.52 所示。 通过这个功能, 可以得到同一个性能测试在不同情况下运行的对比, 直观地获得性能调 优结果。Analysis 会将两份或者多份场景结论数据整合在一起通过一张图来共同显示。 例如:在第 21 次性能测试中发现系统的每秒点击量偏低,平均只有 40 出头,在相关工 程师的帮助下对系统进行了一次服务器调优,随后重新执行了一次相同的性能测试(行为相 同, 负载相同), 得出了第 22 次性能测试的结果, 通过 CrossResult 功能将两次结论进行对比。 在图 5. 中可以发现 res22 的数据明显会比 res21 好很多, 53 说明第 22 次调优的结果优 于前一个版本,在每秒点击量的平均处理能力上有 5 倍以上的提升。

图 5.52 Cross Result

图 5.53 Cross Result 对比 Hits per Second 数据

5.9

生成测试报告

Analysis 提供了导出测试报告的功能,支持 Word 格式或 HTML 格式,将相关的计数器 图整理定位后,就可以直接生成测试报告,为性能测试画上最后的一笔。

5.9.1

创建 HTML 报告

打开 Report 菜单下的 HTMLReport 命令,设置报告保存的地址,确认后就会得到 HTML 版本的性能测试报告,如图 5.54 所示。

图 5.54 HTML Report

5.9.2

创建 Word 报告

Word 报告提供了更好的修改基础,一般生成的报告都选择 Word 格式的,打开 Report 菜单下的 Microsoft Word Report 命令新建一个 Word 报告。 这里可以先设置一下报告中的内容、 文档的作者信息还有图的先后顺序, 设置完成后单 击确定按钮就可以得到最终的 Word 报告。测试报告使用了.dot 模板的形式,可以自定义 模板来形成自己的性能测试报告风格,或者中文版的性能测试报告。 提示:有时生成报告会提示错误,一般都是由于生成 Word 报告的临时目录文件错误导 致的,删除该目录下的文件即可。 除了 Word 和 HTML 格式的报告外,Analysis 还提供了 Crystal 报表的功能,即提供一些 更细节的场景负载数据报表。

5.9.3

创建水晶报表

打开 Report 菜单下的 CrystalReport 命令,这里提供了 Activityreports(活动报告)和 Performancereports(性能报告)两种类型。 Activity reports(活动报告 活动报告) 活动报告 活动报告提供关于虚拟用户和场景运行的信息,包括开始时间、结束时间等详细信息。 活动报告又有 Scenario Execution(场景执行)、 Failed Transaction(失败的交易)和 Failed Vusers(失 败的虚拟用户)三种。 ·Scenario Execution(场景执行 场景执行) 场景执行 该报告会给出场景中每个虚拟用户运行在哪台负载生成器上及其启动时间、结束时间、 持续时间、结束状态,便于了解负载生成中的虚拟用户状态,如图 5.55 所示。

图 5.55 水晶报表 Scenario Execution 失败的交易) ·Failed Transaction(失败的交易 失败的交易 该报告给出所有事务失败的记录, 包括该事务的失败是哪个虚拟用户执行的、 该事务执

行的开始时间、结束时间、持续时间。如果没有失败事务就不提供该报表。 失败的虚拟用户) ·Failed Vusers(失败的虚拟用户 失败的虚拟用户 当虚拟用户出现失败时,该报表会记录相关内容。Performancereports(性能报告)性能报 告 可 以 分 析 每 个 Transaction( 事 务 ) 所 用 的 时 间 , 其 中 有 DataPoint( 数 据 点 ) 、 Detailed Transactions(详细事务)和 Transactions Performance By User(事务性能)三种报告。 数据点) ·Data Point(数据点 数据点 当有白定义的数据点时, 可以在这里看到相关的数据分析内容, 通过 lr_user_data_point 函数完成对白定义数据点的添加。 详细事务) ·Detailed transactions(详细事务 详细事务 这里会给出每个场景中的虚拟用户所执行的事务名、开始时间、结束时间、持续时间、 思考时间、浪费时间、最终状态、事务编号,如图 5.56 所示。

图 5.56 水晶报表 Detailed transactions 事务性能) ·transactions performance by user(事务性能 事务性能 这里会给出每个用户执行的事务数据分析,该用户通过的事务数、事务时间的最小值、 最大值、平均值以及标准方差值,如图 5.57 所示。

图 5.57 水晶报表 transactions performance by user

小结
到这里为止,我们完成了对 Analysis 的介绍。Analysis 是一个十分优秀的数据收集和整 理维护工具,本章只是简单地介绍了 Analysis 的一些常见操作,大家可以进一步研究如何对 图进行一些显示和注释的设置, 加强测试报告数据的可读性和美观性。 性能瓶颈的定位和分 析是一个非常复杂的过程, 首先需要明白每个数据的含义才能进一步发现数据间的关系, 最 终定位系统的短板,在修复短板后再次进行性能测试,寻找下一块短板,如此往复。 在介绍完整个 LoadRunner 的三大组成部分 VuGen、Controller、Analysis 后,读者只是了 解了工具如何使用,而如何在项目中应用 LoadRunner 进行性能测试我们将在下一章中细细 道来。 本章需要掌握的重点: ·AnalysisSummary 报告中的事务摘要含义 ·各种图的含义以及可能出现的瓶颈状态 ·常见监控资源计数器的名称和含义 ·图的三种 Merge 方式及其含义 ·AutoCorrelate 的原理及含义 ·SLA 报告的设计与分析 ·CrosswithResult 多场景数据分析的应用



点击搜索更多“性能测试进阶指南:Loadrunner实战9.1”相关的内容
下载《性能测试进阶指南:Loadrunner实战9.1》

猜你喜欢