性能测试场景分析VIP

录制脚本 录制参数设置 脚本录制 回放和调试脚本 用这按钮进行编译 编译通过后 点击运行按钮即可运行脚本 只有在脚本运行正确 后 才能进入 Controller 中来创建测试场景 脚本录制的原则 充分考虑脚本的执行效率 录制重要的用户业务 选择你所需要的进行录制 修改脚本 参数化功能 步骤 1 步骤 2 步骤 3 参数类型有多种 Date Time 需要输入日期的地方 可以用 Date Time 类型来替代 Group Name 使用虚拟用户组的名称来替代参数 Load Generator Name 使用虚拟用户所在的 LoadGenerator 机器名来替代参数 Lteration Number 测试脚本当前循环的次数来生成参数 Random Number 随机数 Unique Number 唯一的数 一般使用递增的数 Vuser ID 使用虚拟用户的 ID 来替代参数 ID 是由 Controller 来控制的 File 在属性中可以指定文件或数据库中提取数据 User Definde Function 从用户开发的 dll 文件中提取数据 这里的重点是 file 类型 在我们工作中最常用的是 Unique 唯一的 和 Each iteration 下一条数据 的组合 比如我们设计一个场景 要求 10 个虚拟用户都需要进行 10 次迭代 那编号 为 1 的用户取前 10 行数据 编号为 2 的用户取 11 20 行数据 以此类推 那完成整个 场景就需要数据表里至少要有 100 条数据 否则在 Controller 运行过程中会返回一个 错误 深入集合点 就是并发点 使用集合点可以控制各个 Vuser 以便在同一时刻执行任务 原理是 当某个 Vuser 到 达该集合点时 Controller 会将其保留 直到参与该集合点的 Vuser 都到达 满足了集合条 件时 Controller 将释放 Vuser 这样就产生了密集的同一类用户操作或请求 Vuser 从集 合释放后 将执行脚本中的下一个任务 需要注意的是 集合点一般会创建在用户事务的开始标志前 集合点只能加在 action 部分 而不是 init 或 end 部分 比如我们想在登录时创建一个集合点 我们可以这样安排 巧用检查点 Loadrunner 的检查点有三种 Web find Web reg find 和 Web image check 至 于为什么要用检查点可以用个小例子做个测试 例如一个登陆脚本登陆的账号为 123456 密码为 123456 可以正确登陆 当把账号或密码改掉再执行 发现脚本并没 有报错 也顺利执行下来了 原因是什么呢 Loadrunner 以用户角色向服务器发送一 个登陆请求 却不会判断请求的返回消息是什么 只要有返回 即使这是个拒绝登陆 的返回 Loadrunner 也认为登陆成功了 所以在登录或者其他有重要页面跳转的地方 很有必要做检查点 Web find 和 Web image check 两个函数如果在脚本里面增加 需要在设置中打开 图像和文本检查 功能 该功能默认是不打开的 如果手工在脚本里面添加检查点 系统会有提示 Action c 43 Verification checks not enabled web find is skipped See the Run time settings Preferences Checks MsgId MMSG 27197 Web reg find 是注册类型函数 它本身并不执行 不能通过它的返回值来作为事 务的判断条件 因为 web reg find 的返回值 0 和 1 表示 web reg find 是否注册成功 并不代表查找的内容是否存在 也就是说无论查找的文本内容是否存在 都返回 0 它是从返回的缓冲区扫描而不是在接收的页面中查找 这是比 web find 更高效的一个 函数 关联 所谓的关联 correlation 就是把脚本中某些写死的 hard coded 资料 转变成 是摘取自服务器所送的 动态的 每次都不一样的资料 关于检查点和关联的内容 可以参见我们的案例 01 checkproperties 另外 我们可以在中配置脚本运行时的设置 运行逻辑 我们可以设置 ACTION 的迭代次数 思考时间 我们一般忽略思考时间 以得到更大的压力 其 他 我们可以选择错误的处理方式 还可以选择线程方式运行脚本以得到 更大的压力 最后的选项一般默认就行了 速度模拟 默认使用最大带宽 我们也可以模拟一些特殊的接入方式 首 选 项 需要特别注意的是 如果脚本中使用了文本检查点或图片检查点的时 候 此项一定要勾选中 默认是没有勾选的 如果是使用 web reg find 则不要求勾选 其他的项我们一般都使用默认值即可 创建测试场景 场景类型 我们在 VuGen 中完成虚拟用户脚本的调试后 就进入 Controller 中进行用例场景 的设计与执行 在 Controller 中 提供了两种类型的测试场景 手动测试场景和面向目标的测试 场景 在场景运行后 Controller 会在不同的负载生成器上 根据用户的设定进行分析 手动场景 或 自动分析 面向目标场景 生成一定数量的虚拟用户 通过这些虚拟 用户的并发执行以及及时间的运行 来模拟真实情况下服务器承受的压力 在场景运 行的过程中 Controller 可以提供对服务器资源 虚拟用户执行情况 事务响应时间等 方面的监控 帮助测试人员实时的分析系统 并在运行完成后给出结果数据以便进行 下一步的分析 手动场景 在 Controller 中 新建场景时 我们选择上面的手动场景 也可以再选择使用百 分比 不过不重要 我们可以在后面的这个菜单对其更改 手动场景是以用户定义虚拟用户数量来进行测试的 面向目标场景 在面向目标的测试场景中 可以定义希望达到的目标 比如最大虚拟用户数量或 每秒事务数等 Controller 将根据定义的目标自动构建测试场景 并评估能否达到测试 目标 在这个下拉菜单中 我们可以定义虚拟用户数 每秒点击数 每秒事务数 每分钟页 面数和事务响应时间 5 种类型的目标 在这个图的下半部分 可以看到有两个标签页面 场景设置 和 加载行为 这两 个标签页用来设置一些场景的参数 主要用在负载和压力测试的设定 测试场景设计 配置测试测试脚本 在虚拟用户脚本加载后的界面上 选中需要配置的脚本后 点击右侧的 可以查看和修改脚本 需要注意的是 修改后就好重新载入 不 然会使用修改前的脚本 虚拟用户数目和每组用户所在的负载生成器可以直接在此界面中输入 配置 Generator 负载生成器 使用 Generator 可以使用多台安装了负载生成器的主机产生压力 点击 点击 配置 Schedule 计划计划生成器 点击 可以配置计划生成器 计划是场景配置的重要组成部分 主要用于配置用户的行为方式 这里有两种类 型 按场景计划和按用户计划 按场景计划 Schedule by Scenario 按场景计划有三个选项卡 加压 持续时间 减压 加压中 第一个是同时加载所有用户 第二个是每隔一段时间加载一定的虚拟用 户 持续时间中 第一个是照脚本的设置进行 直到运行完成 这种方式主要用在检 测特定功能的实现上 比如在并发时 程序会不会出现一些功能缺陷 第二 个是按照指定的时间运行 如果选择此项 迭代次数的设置会被忽略 每个 虚拟用户都不断的进行迭代 直到指定时间为止 这种方式主要用在指定时 间的性能测试 第三个是一直运行 直到人工干预为止 这种方式主要用来 测试系统的极限 减压中 必须选中持续时间选项卡中的第二项 按照时间运行 才能操作减压选 项卡 指定场景如何结束 这里对于加压 也是两种减压方式 按用户计划 Schedule by Group 按用户计划有四个选项卡 后面三个和场景计划中是一样的 注意在图左边的窗口中 有用户组的选择 可以对每个组进行独立的开始时间 加压 减压和持续时间 特别是一组用户需要使用另一组用户的操作结果时 就必须使用按用户 计划方式配置场景了 我们重点讲解一下开始时间选项卡 场景开始时运行 场景开始后一段时间再开始 这里可以指定具体时间 在某些特定的用户组运行结束后再开始 需要注意的是 也是一个选项 里面的第二和第三项一般是在运 行时间很长 需要放到下班后执行时 我们可以选中它们 配置集合点 我们之前讲过集合点 这里会具体配置集合点 以现实一定数量的并发 主要用来测 试系统某个功能点的并发负载性能 上面表示在 03 checkproperties 脚本中包含了一个集合点 maipiao 通过策略按钮 我们可以配置它 这里有三种方式 当 Vu 中全部指定百分比的虚拟用户到达集合点时释放 当一定比例处于运行状态的虚拟用户到达集合点时释放 当一定数量的虚拟用户到达集合点时释放 最后一项是超时配置 如果在设定时间内都没有新虚拟用户到达集体点 Controller 就 会自动释放到达集合点的用户 配 置 IP Spoofer 现在一些服务器会对同一 IP 访问进行限制 这时我们可以通过 IP Spoofer IP 欺骗 进行配置 以达到我们的测试目的 我们只需要选择开始菜单中的 IP Wizard 进入配置界面 第二步需要选择网卡 之后再在 Controller 中的菜单里 启用 IP 欺骗器就可以了 注意的是 必须在连接到 负载生成器之前选择该选项 再在工具菜单内选中专家模式 进入选项中的常规 就可以根据需要来配置了 测试果设置 为了更好的管理我们越来越多的测试结果 可以在菜单中的设置结果目录 对其进行 管理 通用参数设置 在菜单的选项中 值得注意的是 超时 选项卡 其他选项一般不用修改 在超时选 项卡中 可以对负载生成器的连接 断开以及每个虚拟用户的初始化 运行 暂停和停止 操作的超时时间进行设置 一旦超过设定 则会给出一条错误提示 执行测试场景 启动测试场景 在场景的 运行 界面中有多个窗口 可以观查到场景组 场景状态 多个视图及它们 的统计数据 控制用户与用户组 在场景运行过程中 可以通过 来对用户和用 户组进行管理 包括添加 删除用户和用户组 控制虚拟用户运行状态等 界面如下 查看场景与用户状态 通过场景状态区域的数据 我们可以监控场景与用户状态 在测试过程中就可以直接 点击链接进行观看 控制集合点 在场景的运行中 我们也可以像前面配置集合点一样的查看和控制集合点的状态 即 可以停止集合点和用户 也可以释放或重置集合点 查看运行数据图 在 Controller 中 我们可以添加多种数据图进行查看 在右边的小窗口中 我们可以 添加多种数据视图 监控系统资源 在性能测试中 最重要的一项就是监控系统资源 需要监控这几个方面 操作系统 数据库 中间件服务器等 其中 操作系统的性能表现关系着整个应该系统的性能 属于 基础的系统资源数据 需要注意的是 监控系统是一项消耗资源的操作 所以 测试过程 一定要考虑具体监控什么 以免影响测试结果的准确性 在监控系统之前 我们还需要做一些准备工作 打上监控主机上的 Network DDE Remote Procedure Call RPC Remote Registry Net Logon 等服务 以系统管理员身份从 Controller 登录待监控主机 在监控图中可以添加计算机 输入 IP 地址后 点击 OK 就行了 在添架计算机的下面 我们再加入需要监控的计数器 如果看到数据就是正常 否则检查服务和防火墙有无问题 Windows 监控的主要参数有 CPU 占用率 可用内存容量 服务线程占用的 CPU 资源等 下面列出一些我们常用的计数器 System 系统 Total Processor Time CPU 占用率 系统上所有处理器非空闲线程的平均时间比 它反映了 用于作业上的时间比率 如果该值的数值持续超过 90 则说明整个系统面临这 处理器方面的瓶颈 需要增加处理器来提高性能 System 系统 File Data Operations sec 文件读写操作 当前系统中磁盘文件读写的频繁程度 通过观察该计数 器跟其他性能指标的变化趋势 通常能够判断磁盘文件 操作是否是性能瓶颈 类似的计数器还有 Network Interface Bytes total sec System 系统 Processor Queue Length 处理队列长度 线程单元中处理器队列的即时长度 此值为即时值 一 般不超过 2 否则表示处理器堵塞 System 系统 Total Interrupts sec 中断频繁度 所有处理器花费在处理中断上的时间的总和 表示周边 硬件设备的繁忙程度 Processor 处理器 Processor Time CPU 占用率 提供了一个用 100 减去 CPU 什么也不做的时间的衡量标 准 系统可以更容易地衡量空闲线程运行的频率 Processor 处理器 User Time 用户操作时间 处理线程用于执行使用用户模式的代码的时间的百分比 用户模式是为应用程序 环境分系统和整数分系统设计 的有限处理模式 Memory 内存 Available Mbytes 可用内存 用于描述系统可用内存的直接指标 在对系统进行操作 系统级别的内存分析时 首先应通过该值建立一个初步 的印象 了解性能系统测试过程中 系统是否仍然有足 够的内存可用 如果该指标的数据比较小 系统可能出 现了内存方面的问题 此时需要进一步分析 Memory 内存 Page Faults sec 每秒错误页面 每秒发生页面失效的次数 页面失效次数越多 说明操 作系统向内存中读取的次数越多 此时还需要查看 Pages Read sec 计数器 该计数器阀值为 5 如果超过 5 则可以判定存在内存方面的问题 Memory 内存 Pool Nonpaged Byted 非分页池字节数 指在非分页池中的字节数 非分页池是指系统内存 操作 系统使用的物理内存 中可供对象 指那些在不处于使用 时不可以写入磁盘上 而且只要分派过就必须保留在物理 内存中的对象 使用的一个区域 Memory 内存 Pages sec 页数 秒 为解析内存对页面的引用而从硬盘读取的页数或定稿磁 盘的页数 如果担心内存压力过大 这里需要考虑 性能测试结果分析 如何分析测试结果 在 Controller 中的执行的测试场景结束后 首先要判断采集的结果数据是否真实有效 多数场景都需要迭代执行 因此很多测试结果本身就不能反映真实问题 那我们一般按照 以下几个步骤进行判断结果的有效性 1 测试环境是否正常 如果在测试场景的过程中出现过异常 则结果往往不准确 无须进行分析 如 CPU100 网络断开 2 测试场景设置是否正常 合理 测试场景的设置不合理会测试出现异常 这时需要对场景设置进行分析修正 如 同时在一台 PC 上加载全部 Vu 太多的 Vu 可能会造成客户端不能正常初始化 而造成很多 Vu 不能初始化而失败 这样的失败和我们要测试的服务器根本没有 关系 这时我们可以改为逐步加压 3 测试结果是否直接暴露出系统的一些问题 性能测试的目的是分析出系统在压力下存在的问题 所以我们主要是对出现错误 的结果进行分析 测试结果直接暴露的问题有很多 如 一些用户事务响应时间过长 系统支持最大的并发用户数过低 服务器 CPU 利用率过高 内存不足 测试人员针对这些结果 用 Analysis 对其进行深入分析 以发现在一些潜在的性 能问题 性能分析基础知识 在性能测试中 我们都遵循一个普遍的原则 由外而内 由表及里 层层深入 性能下降最直接的现象就是系统响应时间变长 所以我们都是以系统响应时间作为性 能测试的切入点 而现在的 IT 系统架构复杂 任何一个环节都可能出现瓶颈 要准确的判 断出瓶颈在什么地方 是一个比较头痛的问题 我们分析问题的方法是 任何系统都是由 网络和服务器构成的 所以我们先确定问题是出现在网络还是服务器上的 借助 LR 的 Analysis 组件 可以很容易分析 如下图中 我们可以很容易的看出 在 整个事务时间中 网络时间和服务器时间所占的多少 也可以很容易确定出问题主要现在 在哪一个环节 在实际的工作中 我们不能光发现问题 还要定位问题 并给出一个解决方案 或调 优方案 即使有了正确的测试结果 也不一定能对问题进行正确的定位 比如说我们在工 作中会经常遇到 CPU 占用率过高 我们可能还会发现磁盘 IO 过于频繁 我们一般会认为 是服务器内存不足 但也可能是因为程序内部的编写不严密 资源没有释放而造成的 也 可能是因为程序内部有内存泄漏 解决工作实际问题不但要靠经验 也需要靠对系统的深 入了解 所以说起码的编程能力还是很必要的 Analysis 基本功能 LR 在 Controller 中运行场景 采集了 Vu 操作系统 应用服务器等各种运行数据 当场景运行结束后 我们就可以用过 LR 专用的分析组件 Analysis 进行分析了 当我们打开 Analysis 通常是下面这样的一个界面 在右边添加新图处 我们再进行打开新图的界面 这里还有很多的分析图 这里可以看到系统资源这些都是黑色 不是蓝色链接 说时这里没有采集到数据 我们需要在 Controller 中 场景运行之前开启相应的采集 这里先简要介绍一下名类分析图的含义及用途 虚拟用户 Vusers 图 虚拟用户图里分为运行的虚拟用户图 虚拟用户概要和集合点 3 类 主要用 来查看场景与会话的虚拟用户行为 错误 Errors 图 主要有错误统计 每秒错误数量两类 用来查看服务器什么时间发生错误以 及错误的统计信息 可以发现服务器的处理能力 事务 Transactions 图 描述和事务相关的分析图 事务综述图 事务平均响应时间图 每秒通过事 务数图 每秒通过事务总数图 事务性能摘要图 事务响应时间与负载分析 图 事务响应时间百分比图 事务响应时间分布图等 通过这些分析图 我 们可以分析应用系统事务的执行情况 Web 资源 Web Resources 图 描述 Web 服务器的吞吐率图 点击率图 返回的 HTTP 状态代码图 每秒 HTTP 响应数图 每秒重试次数图 重试概述图 服务器连接数概要图 服 务器每秒建立的连接数量图 借助 Web 资源图 我们可以深入分析服务器性 能 网页细节 Web Page Breakdown 图 网页细分需要在 Controller 中启动 Controller 菜单中诊断中的配置里面 激 活 网页诊断 在网页细分图中主要有 页面分解总图 页面组件细分图 页面组件细分 随时间变化 图 页面下载时间细分图 页面下载时间细分 随时间变化 图 第一次缓冲时间细分图 第一次缓冲时间细分 随时间 变化 图 已下载组件大小图 借助网页细分图 我们可以分析页面元素是 否影响事务响应时间 系统资源 System Resources 图 系统资源图描述在场景运行期间 由联机监控获得的系统资源使用情况 要获得系统 资源情况 必须在 Controller 里预先指定相关的计数器 如何看 Analysis 图 我们使用 Analysis 分析 一般按以下几步来处理 第一页 首先从摘要开始 第一页 首先从摘要开始 摘要主要是判定事务的响应时间与执行情况是否合理 如果发现问题 则需要做进一 步的分析 这里一般需要重视的是事务执行失败和响应时间过长等 下面是查看分析摘要时的一些原则 用户是否全部运行 最大运行并发用户数是否与场景设计的最大运行并发数一致 如 果没有 则需要打开与虚拟用户相关的分析图 进一步分析虚拟用户不能正常运行的详细 原因 事务平均响应时间 90 事务最大响应时间用户是否能接受 如果事务响应时间过长 则要打开与事务相关的各类分析图 进行深入分析 查看事务是否全部通过 如果有失败的情况 则需要深入分析原因 很多时候 执行 失败就说明系统有瓶颈 如果一切正常 则本次测试没有必要进行深入分析 重新加大压力进行测试 如果事务失败过多 则应该降低压力进行测试 使结果容易分析 第二 查看负载发生器和服务器的系统资源情况 第二 查看负载发生器和服务器的系统资源情况 查看分析概要后 接下来要查看负载发生器和待测服务器的系统资源使用情况 查看 CPU 的利用率和内存使用情况 尤其要注意查看是否存在内存泄漏问题 这样做是由于很 多时候系统出现瓶颈的最直接表现就是 CPU 占用率过高和内存不足 这个测试应保存证负载发生器在整个测试过程中 CPU 内存 带宽没有出现瓶颈 否 则测试结果无效 如果硬件上都有瓶颈则不能表现出程序中的问题来 第三 查看虚拟用户与事务的详细执行情况 第三 查看虚拟用户与事务的详细执行情况 在前两步确定了测试场景的执行情况基本正常后 接下要查看虚拟用户与事务执行情 况 对于虚拟用户 主要看看在整个测试过程中是否运行正常 如果有较多用户不能正常 运行 则需要重新设计场影或调整 init 和 end 内容重新测试 对于事务 主要看整个过程的事务响应时间是否逐渐变长以及是否存在不能正常执行 的事务 下面是虚拟用户与事务分析的常用准则 虚拟用户如有失败 则要查明原因 在整个测试过程中 所有的虚拟用户是否一直稳定运行并成功执行全部事务 如果仅有一个用户或部分用户能够正常运行 则说明测试脚本可能存在问题 对于失败的事务首先要分析其失败原因 接着要查看事务的失败是否导致用 户失败 判断用户是否可以接受事务平均响应时间值以及 90 用户的最大响应时间值 查看整个测试过程的事务平均响应时间是否逐渐变长 正常情况下 事务平 均响应时间的变化应该是一条接近平行于 X 轴的直线 事务响应时间是否在整个测试过程中随着用户的增加而线性变短 正常情况 应该是当一定范围内的用户并发时 事务响应时间应不会有太大变化 服务器每秒通过的事务总数 某一事务每秒通过数是否稳定 如果整个测试 过程基本不变 则要分析是服务器达到了处理上限还是 Generator 产生的压力 达到了上限 按照迭代次数来运行的场景 要分析通过的事务总数是否与设定一致 如果 不一致 则可能脚本有问题 也可能是程序存在功能错误 应调整后再测 Analysis 对虚拟用户和事务提供了非常强大的跟踪功能 可以跟踪每一个用户及 其相关事务的执行情况 这些内容可以在菜单 报告 中的 crystal 报告 里找到 第一步 查看错误发生情况 整个测试过程的错误发生情况是分析的重点 下面是错误发生情况的常用准则 查看错误发生曲线在整个测试过程中是否有规律变化 如果有 则意味程序 在并发处理方面存在一定的缺陷 如果没有规律 则可以将步调调慢一点 达到更好的测试效果 或可能是脚本有问题 查看错误分类统计 作为优化系统的参考 比如 超时错误 达到 90 以上 可能需要硬件上提高配置了 再比如出现较多的 内部服务器错误 则可能 是程序方面存在问题 第二步 查看 Web 资源与细分网页 现在的系统多是 Web 广域网系统 所以需要很多的重视 Web 性能的测试 查看 Web 图时 往往需要结合前而对虚拟用户以及事务响应时间的分析结果 重点分析服 务器的稳定性 对于网页细分功能则应遵循如下原则 分析从用户发出请求到收到第一个缓冲为止 哪些环节比较耗时 找出页面中哪些组成部分对用户响应时间影响较大 找到页面性能问题后 提出调优方案 测试调优后的性能能否达到要求 在性能测试中 我们除了要使用 Analysis 分析外 还要借助其他分析工具 比如 Oracle WebLogic 等软件都有自己的监控和分析工具 以达到更好的测试效果 细述分析图 虚拟用户图 虚拟用户图显示 Vuser 状态 完成脚本的 Vuser 数量以及集合点的统计信息 虚 拟用户图主要有三类 正在运行的虚拟用户 Running Vuser 图 虚拟用户概要 Vuser Summary 图 集合点 Rendezvou 图 正在运行的虚拟用户 Running Vuser 图 正在运行的虚拟用户图一般会和一些事务响应合并起来一起分析 下图我们把用 户和 windows 资源及事务图一并结合起来 可以看到用户对事务和资源的影响 虚拟用户概要 Vuser Summary 图 查看各个虚拟用户的成功比例 集合点 Rendezvou 图 主要查看集合点的执行情况 事务图 Analysis 和事务相关的分析图有 事务摘要图 事务平均响应时间图 每秒通过 事务总数图 事务性能摘要图 事务响应时间与负载分析图 事务响应时间 百分比 图 事务响应时间分布图 通过这些图可以很容易分析整个测试过程的事务执行情况 事务摘要 Transaction Summary 图 这里有两组不同压力测试的事务图 可以很明确的看到压力大的时候 系统出错 的情况更严重 特别是 maipiao 这一事务进而影响到 action 事务 因为我们在 maipiao 事务前设置了一个集合点 说明了系统在并发上存在一定的性能瓶颈 事务平均响应时间 Average Transaction Response Time 图 事务平均响应时间图是在测试场景运行过程中的每一秒内 执行各个事务所用的 平均时间 通过它可以分析测试场景运行过程应用系统的性能走向 一般来说一个性能稳定的系统应该是一条基本平等于 X 轴的线条 这里紫色的起 伏较大的线条是包含集合点 maipiao 的 action 事务 如果说系统存在内存泄漏的问 题 那就是一起向右上逐渐倾斜的线条 每秒通过事务数 Transactions per Second 图 描述在场景运行的每一秒中 每个事务通过 失败以及停止的数量 是考查系统 性能的一个重要参数 通过它可以确定系统在任何给定时刻的实际事务负载 通过分 析单位时间内通过的事务数 可以看出系统的性能变化赵势 当压力增大时 每秒通过事务数 TPS 图以及稍后介绍的点击率图的曲线如果 变化缓慢或比较平坦 那服务器很可能存在瓶颈 所以 分析每秒通过事务数图主要 是看曲线的走向 每秒通过事务总数 Total Transactions per Second 图 每秒通过事务总数图是场景在运行时每一秒通过的事务总数 失败的事务总数以 及停止的事务总数 在系统性能稳定的情况下 应该是接近一条直线 而不是逐渐倾 斜 事务性能摘要 Transaction Performance Summary 图 事务性能摘要图显示了场景中所有事务的最大 最小和平均执行时间 可以直接 判断响应时间是否符合用户的要求 在此图中 我们可以单击右键 选择 Show Transaction Breakdown Tree 显示所选事务细分树图 如果双击图中较为关注的子事 务 将会显示对应事务的最大 最小和平均执行时间 事务响应时间与负载分析 Transaction Response Time Under Load 图 此图是正在运行的虚拟用户图和事务平均响应时间的组合 通过它可以看出任一 时间点事务响应时间与用户数目的关系 从而掌握系统在用户并发方面的性能数据 事务响应时间 百分比 Transaction Response Time Percentile 图 此图是根据测试结果进行分析而得到的综合分析图 假设期望 Action 事务在 50 秒内完成 在下图看来 有 90 的用户达到这一目标 如果是期望 maipiao 事 务在 10 秒内完成 目前看到 100 的用户都达到了这一目标 事务响应时间分布 Transaction Response Time Distribution 图 对此图进行分析 主要看其是否有强烈的延续 如果有 则说明存在很多响应时 间过长的事务 在下图中 Action 事务有很强的延续性 说明有很多事务响应时间过 多了 在这里 可能是因为有集合点 因为 Action 中 maipiao 事务的响应时间很短 而 Action 事务中只有一个 maipiao 的事务 所以可能是有集合点的原因 也可能是脚 本的问题 如果排除这两个问题 还可能是并发的问题了 事务图总结 分析用户事务的执行情况是性能分析的第一步 通过深入分析用户事务的响应时 间是否合理 可以判断系统性能是否合符用户的要求 如果通过用户事务分析发现有 问题 那么要 Web 资源进行分析 Web 资源图 Analysis 中的 Web 资源图主要通过点击率 吞吐率 每秒 HTTP 响应数 每秒连 接数等测试来分析 Web 服务器的性能 通过多次不同压力下各种 Web 资源的结果数 据对比 可以知道系统的性能走向和性能瓶颈 点击率 Hits per Second 图 点击率图是指在场景运行中虚拟用户每秒向 Web 服务器提交的 HTTP 请求数 既 可以依据点击次数来评估虚拟用户产生的负载量 也可将其与事务平均响应时间图进 行比较 可以看到点击次数对事务性能的影响 从这里可以看到 在 3 分 44 秒的时候 出现了第一个压力高峰 每秒 23 次的点 击 这里出现了一个响应的瓶颈 图表右半部分反应来看 系统还是比较稳定的 出 现较大的规律的波动的原因是什么呢 提示 注意点击率和事务执行情况对比来看 吞吐率 Throughput 图 吞吐率图是指在场景运行过程中服务器每秒的吞吐量 单位 字节 它描述的是 每秒虚拟用户从服务器获得的数据量 根据吞吐量可以评估虚拟用户产生的负载量 吞吐量和点击率的形状是基本相似的 如果吞吐量和点击率图都出现与事务无关 的左高右低 则说明服务器性能有下降的趋势 此图中的左高右低的原因和前面点击 率的情况是一样的 所以此处的左高右低并不能说明服务器性能有所下降 每秒 HTTP 响应次数 HTTP Responses per Second 图 此图是指场景运行过程中每秒从 Web 服务器返回的不同 HTTP 状态代码的数量 其按照状态代码分组 这里需要说明的是 LR 只把返回状态代码为 200 的认为是正常 其他都认为是错 误 下面列出常见的状态代码的含义 1xx 信息提示信息提示 这些状态代码表示临时的响应 客户端在收到常规响应之前 应准备接收一个或 多个 1xx 响应 100 继续 101 切换协议 2xx 成功成功 这类状态代码表明服务器成功地接受了客户端请求 200 确定 客户端请求已成功 201 已创建 202 已接受 203 非权威性信息 204 无内容 205 重置内容 206 部分内容 3xx 重定向重定向 客户端浏览器必须采取更多操作来实现请求 例如 浏览器可能不得不请求服务 器上的不同的页面 或通过代理服务器重复该请求 302 对象已移动 304 未修改 307 临时重定向 4xx 客户端错误客户端错误 发生错误 客户端似乎有问题 例如 客户端请求不存在的页面 客户端未提供 有效的身份验证信息 400 错误的请求 401 访问被拒绝 IIS 定义了许多不同的 401 错误 它们指明更为具体的错误原 这些具体的错误代码在浏览器中显示 但不在 IIS 日志中显示 401 1 登录失败 401 2 服务器配置导致登录失败 401 3 由于 ACL 对资源的限制而未获得授权 401 4 筛选器授权失败 401 5 ISAPI CGI 应用程序授权失败 401 7 访问被 Web 服务器上的 URL 授权策略拒绝 这个错误代码为 IIS 6 0 所专用 403 禁止访问 IIS 定义了许多不同的 403 错误 它们指明更为具体的错误原因 403 1 执行访问被禁止 403 2 读访问被禁止 403 3 写访问被禁止 403 4 要求 SSL 403 5 要求 SSL 128 403 6 IP 地址被拒绝 403 7 要求客户端证书 403 8 站点访问被拒绝 403 9 用户数过多 403 10 配置无效 403 11 密码更改 403 12 拒绝访问映射表 403 13 客户端证书被吊销 403 14 拒绝目录列表 403 15 超出客户端访问许可 403 16 客户端证书不受信任或无效 403 17 客户端证书已过期或尚未生效 403 18 在当前的应用程序池中不能执行所请求的 URL 这个错误代码 IIS 6 0 所专用 403 19 不能为这个应用程序池中的客户端执行 CGI 这个错误代码为 IIS 6 0 所专用 403 20 Passport 登录失败 这个错误代码为 IIS 6 0 所专用 404 未找到 404 0 无 没有找到文件或目录 404 1 无法在所请求的端口上访问 Web 站点 404 2 Web 服务扩展锁定策略阻止本请求 404 3 MIME 映射策略阻止本请求 405 用来访问本页面的 HTTP 谓词不被允许 方法不被允许 406 客户端浏览器不接受所请求页面的 MIME 类型 407 要求进行代理身份验证 412 前提条件失败 413 请求实体太大 414 请求 URI 太长 415 不支持的媒体类型 416 所请求的范围无法满足 417 执行失败 423 锁定的错误 5xx 服务器错误服务器错误 服务器由于遇到错误而不能完成该请求 500 内部服务器错误 500 12 应用程序正忙于在 Web 服务器上重新启动 500 13 Web 服务器太忙 500 15 不允许直接请求 Global asa 500 16 UNC 授权凭据不正确 这个错误代码为 IIS 6 0 所专用 500 18 URL 授权存储不能打开 这个错误代码为 IIS 6 0 所专用 500 100 内部 ASP 错误 501 页眉值指定了未实现的配置 502 Web 服务器用作网关或代理服务器时收到了无效响应 502 1 CGI 应用 程序超时 502 2 CGI 应用程序出错 503 服务不可用 这个错误代码为 IIS 6 0 所专用 504 网关超时 505 HTTP 版本不受支持 每秒连接数 Connections per Second 图 此图是描述场景在运行中每秒新建的 TCP IP 连接数 新连接数应该是每秒点击次 数的一小部分 因为就系统资源来说 新的 TCP IP 连接非常耗费资源 下面上看 服务的性能有不太明显的性能下降 因为连接断开和新连接的数量都 在逐渐下降 如果说连接断开和新连接数都下降为 0 了 说明系统崩溃 有严重性能 问题 很不稳定 不能投产 网页细分图 网页细分图主要用来评估页面内容是否影响事务响应时间 通过它可以深入分析 网站上哪些下载很慢的图像或中断的链接等有问题的元素 可以方便的对问题进行比 较精确的定位 网页细分图多用于分析在事务性能摘要图和事务平均响应时间图中检 测到的问题 可以将网页细分图中的数据和事务性能摘要图和事务平均响应时间图中 的数据关联起来 综合分析性能出现的是网络问题还是服务器问题 网页细分图主要有 页面分解总图 页面组件细分图 页面组件分解 随时间变 化 图 页面下载时间细分图 页面下载时间细分 随时间变化 图 第一次缓冲时 间细分图 第一次缓冲时间细分 随时间变化 图 已下载组件大小图 页面分解总 Web Page Breakdown 图 此图描述某一具体事务在测试过程中的响应情况 进而分析相关的事务是否运行 正常 上图针对于 Action 和 maipiao 事务进行查看 Action 响应时间有变长的趋势 maipiao 事务有细微的起伏 总的来说是比较稳定的 页面分解总图有四种方式细分 1 下载时间细分 在下载时间细分图中 不但要分别显示网页中不同元素的下载时间 同时还要按 照下载过程将时间进行分解 用不同的颜色来显示 DNS 解析时间 建立连接时间 第 一次缓冲时间等各自所占的比例 通过下载时间细分图可以很容易看出各个元素所用的时间长短 以及下载过程对 时间进行的分解 为调整程序提供依据 2 组件细分 随时间变化 组件细分 随时间变化 图是指选定网页的页面组件随时间变化细分图 在此图 中 可以选择不同的元素以查看测试过程中其下载时间的变化曲线 发现不稳定的元 素 需要在客户端下载控件较多的页面要特别重视此图 3 下载时间细分 随时间变化 下载时间细分 随时间变化 图显示选定网页的页面元素下载时间细分时间变化 的情况 它非常清晰的显示了页面中各个元素在压力负载下的下戴情况 对比图 压力更小 上面的图中连接的响应时间变长了不少 接收时间也变长了 说明系统在压力加 大的情况下有延迟 如果延迟的时间是客户可以接受的范围内 系统也是可以接受的 4 第一次缓冲时间细分 随时间变化 显示选定网页的第一次缓冲时间细分 随时间变化 情况 分析第一次缓冲时间 细分 随时间变化 图 首先要理解什么是第一次缓冲时间 它是指客户端与服务器 建立连接后 从服务器发送第一个数据包开始计时 数据经过网络传送到客户端后 到浏览器接收到第一个缓冲所用的时间 第一次缓冲时间细分图主要显示页面不同元素在传输过程中的响应时间 并用两 种颜色进行区别 这样 我们就非常直观的看到整个过程中网络时