性能测试进阶指南：Loadrunner实战9.1-第5章-数据收集分析

目录目录 第 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 代表取样个数 n 1 是统计学上的常用做法 主要考虑到采样 量越大 越能反映真实的情况 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 4 2 节 而在 Configure columns 中可以设置在 Legend 中显示哪些属性名 每张图都代表了场景运行中监控到的数据变化趋势 所以看懂每一张图的含义是性能 分析的第一步 接着我们来介绍一些常见图的含义 5 3 1 Vusers 虚拟用户状态虚拟用户状态 Vusers 用户状态计数器组提供了产生负载的虚拟用户运行状态的相关信息 可以帮助 我们了解负载生成的过程 Running Vusers 负载过程中的虚拟用户运行情况负载过程中的虚拟用户运行情况 该图可以反映系统形成负载的过程 随着时间的推移 虚拟用户数是如何变化的 在图 5 8 中可以看到用户在 9 分钟左右到达了负载峰值 50 个虚拟用户 负载的生成 是大约每分钟增加 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 中可以得到最高的带宽峰值是 B 远远低于 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 数据项 这个项目是自动关