LoadRunner性能测试详细操作演示过程

LoadRunner性能测试演示过程

目录

1.LoadRunner11基础 ...................................................................................................................... 2

1.1术语 .................................................................................................................................... 3 1.2组件与测试流程 ................................................................................................................ 3 2.测试计划....................................................................................................................................... 4

2.1测试环境 ............................................................................................................................. 4 2.2应用程序要求 .................................................................................................................... 4 2.3测试人员和时间 ................................................................................................................ 5 3使用LoadRunner进行负载/压力测试 ........................................................................................ 5

3.1录制基本的用户脚本 ........................................................................................................ 5 3.2 完善测试脚本 ................................................................................................................... 7

3.2.1 插入事务 ............................................................................................................... 7 3.2.2 插入集合点 ........................................................................................................... 8 3.2.3 插入注释 ............................................................................................................. 10 3.2.4 参数化输入 ......................................................................................................... 10 3.3 单机运行测试脚本 ......................................................................................................... 15 4实施测试...................................................................................................................................... 15

4.1 选择脚本，创建虚拟用户 ............................................................................................. 15 4.2 添加windows资源监视窗口 ......................................................................................... 19 4.3 添加windows性能计数器 ............................................................................................. 19 4.4 执行脚本 ......................................................................................................................... 21

4.4.1 生成结果 ............................................................................................................. 21

5 分析以及监视场景 ..................................................................................................................... 22

5.1 Memory相关 .................................................................................................................... 22 5.2 Processor相关 .............................................................................................................. 25 5.3 网络吞吐量以及带宽 ..................................................................................................... 28 5.4 磁盘相关 ......................................................................................................................... 29 5.5 Web应用程序 .................................................................................................................. 30 5.6 SQL Server ..................................................................................................................... 31 5.7 Network Delay ............................................................................................................... 31 6 分析实时监视图表 ..................................................................................................................... 32 7 分析原则..................................................................................................................................... 32

7.1、错误提示分析 ............................................................................................................... 33 7.2、监控指标数据分析 ....................................................................................................... 33 8．测试结果 ................................................................................................................................... 35

1.LoadRunner11基础

LoadRunner 是一种预测系统行为和性能的工业标准级负载测试工具。通过以模拟上 千万用户实施并发负载及实时性能监测的方式来确认和查找问题，LoadRunner 能够对整个 企业架构进行测试。通过使用LoadRunner ， 企业能最大限度地缩短测试时间， 优化性能和加速应用系统的发布周期。目前企业的网络应用环境都必须支持大量用户，网络体系架构中含各类应用环境且由不同供应商提供软件和硬件产品。难以预知的用户负载和愈来愈复杂的应用环境使公司时时担心会发生用户响应速度过慢， 系统崩溃等问题。这些都不可避免地导致公司收益的损失。Mercury Interactive 的 LoadRunner 能让企业保护自己的收入来源， 无需购置额外硬件而最大限度地利用现有的IT 资源， 并确保终端用户在应用系统的各个环节中对其测试应用的质量， 可靠性和可扩展性都有良好的评价。LoadRunner 是一种适用于各种体系架构的自动负载测试工具， 它能预测系统行为并优化系统性能。LoadRunner 的测试对象是整个企业的系统， 它通过模拟实际用户的操作行为和实行实时性能监测， 来帮助您更快的查找和发现问题。此外，LoadRunner 能支持广范的协议和技术， 为您的特殊环境提供特殊的解决方案。

1.1术语

?场景：场景是一种文件，用于根据性能要求定义在每一个测试会话运行期间发生的事件。

?Vuser：在场景中，LoadRunner 用虚拟用户或Vuser 代替实际用户。Vuser 模拟实际用 户的操作来使用应用程序。一个场景可以包含几十、几百甚至几千个 Vuser。

?Vuser脚本：Vuser 脚本用于描述 Vuser 在场景中执行的操作。

?事务：要度量服务器的性能，需要定义事务。事务表示要度量的最终用户业务流程。 1.2组件与测试流程

LoadRunner 包含下列组件： ?虚拟用户生成器：用于捕获最终用户业务流程和创建自动性能测试脚本（也称为虚拟用户脚本）。

?Controller：用于组织、驱动、管理和监控负载测试。 ?负载生成器：用于通过运行虚拟用户生成负载。 ?Analysis：有助于查看、分析和比较性能结果。

?Launcher：为访问所有 LoadRunner 组件的统一界面。

负载测试通常由五个阶段组成：计划、脚本创建、场景定义、场景执行和结果分析。 ?计划负载测试：定义性能测试要求，例如并发用户的数量、典型业务流程和所需响应时间。

?创建 Vuser 脚本：将最终用户活动捕获到自动脚本中。

?定义场景：使用LoadRunner Controller 设置负载测试环境。

?运行场景：通过LoadRunner Controller 驱动、管理和监控负载测试。 ?分析结果：使用LoadRunner Analysis 创建图和报告并评估性能。

2.测试计划

2.1测试环境

硬件环境:

CPU：Intel G630 2x2.7G 内存:2G

硬盘：500G 软件环境：

测试工具：Loadrunner11 英文版

系统结构：B/S结构 操作系统：windowsXP 浏览器：IE6 带宽：4m/bps 服务器：自带的虚拟服务器

2.2应用程序要求

应用程序 Mercury LoadRunner11自带的基于 Web 的旅行代理系统Mercury Tours。用户可以连接到 Web 服务器、搜索航班、预订航班并查看航班路线。

1.确保示例 Web 服务器正在运行。安装和重新启动 LoadRunner 后，Web 服务器将自动启动。如果该服务器没有运行，请依次选择“开始”> “程序”> “Mercury LoadRunner”>“示例”>“Web”>启动 Web 服务器”。

2.打开 Mercury Tours 应用程序。选择“开始”>“程序”> “Mercury LoadRunner”> “示例”> “Web”> “Mercury Web Tours 应用程序”。将打开浏览器，其中显示 Mercury Tours 的起始页。

3.登录到 Mercury Tours。

申请帐号为用户名：jojo，密码：bean ；用户名：jojo1，密码：123456 假设您是负责验证应用程序是否满足业务需求的性能工程师。项目经理向您提出了一些条件：

1 Mercury Tours 必须在不超过 90 秒的响应时间内，处理 10 起并发航班预订业务。 2 Mercury Tours 必须在不超过 120 秒的响应时间内，处理 10 起并发的旅行代理要求的航线检查业务。

3 Mercury Tours 必须在不超过 10 秒的响应时间内，处理 10 起代理要求的登录和注销系统任务。、

本教程将完成建立负载测试的整个流程，以验证应用程序是否满足每项业务要求，从而决定是否可以发行该应用程序。

计划了负载测试之后，下面开始创建脚本。

2.3测试人员和时间

测试人员：刘清

时间：2012.10.11-2012.10.12

3使用LoadRunner进行负载/压力测试

3.1录制基本的用户脚本

创建用户脚本需要用到VuGen。提示： 运行VuGen 最好在1024*768 的分辨率下， 否则有些工具栏会看不到。

启动Visual User Generator 后， 通过菜单新建一个用户脚本， 选择系统通讯的协议。

这里我们需要测试的是Web 应用，同时考虑到测试的目标所以我们需要选择Web(HTTP/HTML)协议协议，确定后， 进入主窗体。通过菜单来启动录制脚本的命令。

●在URL 中添入要测试的Web 站点地址.http://127.0.0.1:1080/WebTours/.。 ●选择要把录制的脚本放到哪一个部分， 默认情况下是“Action”。

这里简单说明一下：VuGen 中的脚本分为三部分：vuser_init、vuser_end 和Action。其 中vuser_init 和vuser_end 都只能存在一个， 不能再分割， 而Action 还可以分成无数多个部分（ 通过点击New 按钮， 新建ActionXXX）。在录制需要登陆的系统时， 我们把登陆部分放到vuser_init 中， 把登陆后的操作部分放到Action 中， 把注销关闭登陆部分放到vuser_end 中。（ 如果需要在登陆操作设集合点， 那么登陆操作也要放到Action 中， 因为vuser_init 中不能添加集合点） 在其他情况下， 我们只要把操作部分放到Action 中即可。注意： 在重复执行测试脚本时，vuser_init 和vuser_end 中的内容只会执行一次， 重复执行的只是Action 中的部分。

图2.1

●点“ 选项 ”按钮， 进入录制的设置窗体， 这里一般情况下不需要改动。 ●然后点“OK” 后，VuGen 开始录制脚本。

登陆网站，输入用户名jojo,密码bean。登陆后点击左边的Fights，打开Find Flight页面，将Departure City 改为London,将Arrival City 改为Paris，右下的的Type of Seat选择Bussiness（商务仓），点击Continue，接下来的页面继续Continue，在接下来的Payment Dentails页面，输入Credit Card：12345678，Exp Date：11/27,单击Continue继续，显示预定完成页面。

4.单击左边的“Itinerary”查看路线。

5.点击“Sigin off”退出系统。点击悬浮条上的停止按钮。

以上即完成了一次登录、预定航班、检查路线、注销的事物流程。。

在录制过程中， 不要使用浏览器的“ 后退” 功能，LoadRunner 支持不太好！ 录制过程中， 在屏幕上会有一个工具条出现。录制的过程和WinRunner 有些类似， 不再多介绍。录制完成后， 按下“ 结束录制” 按钮，VuGen 自动生成用户脚本， 退出录制过程。 选择菜单栏View中的Tree View 和Script View都可以查看录制好的脚本

3.2 完善测试脚本

当录制完一个基本的用户脚本后， 在正式使用前我们还需要完善测试脚本， 增强脚本的 灵活性。一般情况下， 我们通过以下几种方法来完善测试脚本。插入事务、插入结合点、插入注解、参数化输入。这里只举例介绍参数化如何设置，其它只作简单介绍。

3.2.1 插入事务

事务（Transaction）： 为了衡量服务器的性能， 我们需要定义事务。比如： 我们在脚本

中有一个数据查询操作， 为了衡量服务器执行查询操作的性能， 我们把这个操作定义为一个事务， 这样在运行测试脚本时，LoadRunner 运行到该事务的开始点时，LoadRunner 就会开始计时， 直到运行到该事务的结束点， 计时结束。这个事务的运行时间在结果中会有反映。

插入事务操作可以在录制过程中进行， 也可以在录制结束后进行。LoadRunner 运行在 脚本中插入不限数量的事务。

具体的操作方法如下： 在需要定义事务的操作前面， 通过菜单或者工具栏插入。输入该事务的名称。注意： 事务的名称最好要有意义， 能够清楚的说明该事务完成的动作。插入事务的开始点后， 下面需要在需要定义事务的操作后面插入事务的“ 结束点”。同样可以通过菜单或者工具栏插入。默认情况下， 事务的名称列出最近的一个事务名称。一般情况下， 事务名称不用修改。事务的状态默认情况下是LR_AUTO。一般情况下， 我们也不需要修改， 除非在手工编写代码时， 有可能需要手动设置事务的状态。

3.2.2 插入集合点

插入集合点是为了衡量在加重负载的情况下服务器的性能情况。在测试计划中， 可能会 要求系统能够承受1000 人同时提交数据，在LoadRunner 中可以通过在提交数据操作前面加入集合点， 这样当虚拟用户运行到提交数据的集合点时，LoadRunner 就会检查同时有多少用户运行到集合点，如果不到1000 人，LoadRunner 就会命令已经到集合点的用户在此等待， 当在集合点等待的用户达到1000 人时，LoadRunner 命令1000 人同时去提交数据， 从而达到测试计划中的需求。

首先在树形菜单中选择需要插入检查点的项目，单击鼠标右键，选择将检查点插入进去。如果在该操作执行前检查，则选择\，在该操作执行后检查则选择\After\，如图所示。

然后系统将弹出对话框，选择\（这里以Text检查点为例说明）。单击\按钮后，会出现\对话框，如图所示

单击\确定\后，即可完成添加\检查点\的任务。

注意： 集合点经常和事务结合起来使用。集合点只能插入到Action 部分，vuser_init 和vuser_end 中不能插入集合点。具体的操作方法如下： 在需要插入集合点的前面， 通

过菜单或者工具栏操作输入该集合点的名称。注意： 集合点的名称最好要有意义， 能够清楚的说明该集合点完成的动作。

3.2.3 插入注释

注释的作用就不多说了， 不过插入注释最好是在录制过程中。具体的操作方法如下： 在需要插入注释的前面， 通过菜单或者工具栏操作

3.2.4 参数化输入

如果用户在录制脚本过程中， 填写提交了一些数据， 比如要增加数据库记录。这些操作 都被记录到了脚本中。当多个虚拟用户运行脚本时， 都会提交相同的记录， 这样不符合实际的运行情况， 而且有可能引起冲突。为了更加真实的模拟实际环境， 需要各种各样的输入。参数化输入是一种不错的方法。 用参数表示用户的脚本有两个优点： ① 可以使脚本的长度变短。

② 可以使用不同的数值来测试你的脚本。例如， 如果你企图搜索不同名称的图书， 你 仅仅需要写提交函数一次。在回放的过程中， 你可以使用不同的参数值， 而不只搜索一 个特定名称的值。

参数化包含以下两项任务： ① 在脚本中用参数取代常量值。 ② 设置参数的属性以及数据源。

参数化仅可以用于一个函数中的参量。你不能用参数表示非函数参数的字符串。 另外， 不是所有的函数都可以参数化的。

参数化输入的讲解， 我们采用一个例子的方式来进行。

在本例中我们参数化用户的登陆名、密码、出发地、到达地、出发时间、到达时间： 点击Open Parameter List功能按钮，弹出对话框，选择“替换为新参数”弹出对话框，此时参数名输入：username，参数类型选择File，如图

点“属性”按钮， 出现以下窗口

注意： 参数的文件名不要使用con.dat、pm.dat 或者lpt*.dat 等系统装置名 “选择下一行 ” 有以下几种选择：

●Sequential： 按照顺序一行行的读取。每一个虚拟用户都会按照相同的顺序读取 ●Random： 在每次循环里随机的读取一个， 但是在循环中一直保持不变

●Unique ： 唯一的数。注意： 使用该类型必须注意数据表有足够多的数。比如Controller 中设定20 个虚拟用户进行5 次循环， 那么编号为1 的虚拟用户取前5 个数， 编号为2 的虚拟用户取6-10 的数， 依次类推， 这样数据表中至少要有100 个数据， 否则Controller

运行过程中会返回一个错误。

“按编号”指选择列表中的那一列数据，从左到右分别是1、2、3依次

通常用在有关联性的数据上面。我们这里取值Sequential 即可。完成设置关闭即可

下面我们再介绍用数据库中的用户名来参数化登陆用户名。 从数据表中选择用户名。点“数据向导” 按钮，显示如图

使用第2 项， 选择“使用手动指定SQL语句”点下一步，出现如图窗口

添入连接字符串， 点“创建” 按钮，选择事先配置好的ODBC连接。在SQL语句里输入select

查询语句

提醒： 在参数数据显示区， 最多只能看到100 行， 如果数据超过100 行， 只能点“编辑” 按钮， 进入记事本看。

准备所需要的参数化的数据后，

然后看如下脚本，通过脚本录制找到用户登陆部分，如图

框选住登陆名，点鼠标右键，弹出对话框，选择“替换为新参数”弹出对话框

参数名随意取，建议取通俗易懂的名字，下面我们重点介绍一下参数的类型。

●DateTime： 很简单， 在需要输入日期/时间的地方， 可以用DateTime 类型来替代。 其属性设置也很简单， 选择一种格式即可。当然也可以定制格式。

.●Group Name：暂时不知道何处能用到，但设置比较简单。在实际运行中，LoadRunner 使用该虚拟用户所在的Vuser Group 来代替。但是在VuGen 中运行时，Group Name 将会是None

.●Load Generator Name： 在实际运行中，LoadRunner 使用该虚拟用户所在Load Generator 的机器名来代替。

.●Iteration Number： 在实际运行中，LoadRunner 使用该测试脚本当前循环的次数来 代替。

.●Random Number： 随机数。很简单。在属性设置中可以设置产生随机数的范围 .●Unique Number：唯一的数。在属性设置中可以设置第一个数以及递增的数的大小。 注意： 使用该参数类型必须注意可以接受的最大数。例如： 某个文本框能接受的 最大数为99。当使用该参数类型时， 设置第一个数为1， 递增的数为1， 但100 个 虚拟用户同时运行时，第100 个虚拟用户输入的将是100，这样脚本运行将会出错。 注意： 这里说的递增意思是各个用户取第一个值的递增数， 每个用户相邻的两次循 环之间的差值为1。举例说明： 假如起始数为1， 递增为5， 那么第一个用户第一 次循环取值1， 第二次循环取值2； 第二个用户第一次循环取值为6， 第二次为7； 依次类推。

●Vuser ID： 设置比较简单。在实际运行中，LoadRunner 使用该虚拟用户的ID 来代 替，该ID 是由Controller 来控制的。但是在VuGen 中运行时，Vuser ID 将会是–1。 File： 需要在属性设置中编辑文件，添加内容，也可以从现成的数据库中取数据（ 下 面我们将会介绍）

●User Defined Function： 从用户开发的dll 文件提取数据。就目前我认为， 这种方式 没有必要。VuGen 支持C 语言的语法，在VuGen 中重新编写类似的函数应该不难。 上面的例子中， 我们取随机数即可。点“Properties? ..” 按钮， 进行属性设置窗口 添入随机数的取值范围为（1-50）， 选择一种数据格式。在“属性” 中有以下几 个选项：

◆Each Occurrence：在运行时， 每遇到一次该参数， 便会取一个新的值 ◆Each iteration：运行时， 在每一次循环中都取相同的值 ◆Once：运行时， 在每次循环中， 该参数只取一次值 这里我们用的是随机数， 选择Each Occurrence 非常合适。

3.3 单机运行测试脚本

经过以上的各个步骤后， 脚本就可以运行了。运行脚本可以通过菜单或者工具栏来操作。 执行“ 运行” 命令后，VuGen 先编译脚本， 检查是否有语法等错误。如果有错误，VuGen 将会提示错误。双击错误提示，VuGen 能够定位到出现错误的那一行。为了验证脚本的正 确性， 我们还可以调试脚本， 比如在脚本中加断点等， 操作和在VC 中完全一样， 相信大家谁都不会感到陌生。如果编译通过， 就会开始运行。然后会出现运行结果。

4实施测试

4.1 选择脚本，创建虚拟用户 启用“controller”弹出如图窗口

选择刚才录制并保存好的脚本，添加到方案中，点“确定”出现如图

根据需要修改虚拟用户数量，场景设计，取不同数字

点“编辑计划”细化方案，计划名里选择计划种类：缓慢加压，运行持续时间、缓慢减压 ? 缓慢加压：并发总用户10vuser，每15秒启动2个vuser 持续时间15秒

? 运行持续时间：持续运行5分钟

? 缓慢减压：：每30秒减少5个vuser 持续时间10分种

场景设计如图所示

然后点击添加虚拟机功能按钮，添加IP地址为192.168.9.173

点击Connerct,状态显示连接成功

然后点击“开始方案”功能按钮启动运行，出现如图窗口

打开可用图中目录树，选择系统资源找到windows资源 Windows资源监视窗口

4.2 添加windows资源监视窗口

loadruner默认性能监视窗口四个，分别是“运行vuser“、”事务响应时间“、

“每秒点击次数”最后一个可以根据用户自己选择现实什么窗口。打开可用图中目录树， 选择系统资源，找到windows资源双击，则windows资源监视窗口便自动替换原窗口如上图。当然loadrunner也可以同时显示1－16个窗口，方法是点右键，在弹出菜单中选择“查看图”选择显示的图数，也可以自定义数字。 4.3 添加windows性能计数器

鼠标选择windows资源监视窗口，点击右键弹出菜单中选择“ADD Measurements..”弹出如图窗口

点“添加”把监视的服务器ip地址输入，点确定，如图

如果可以正常联机到服务器，则在资源度量中会显示全部计数器，此时如果点“确定”则系统默认全部选中，在监视窗口中会显示所有性能曲线，无法单独过滤显示某条曲线，如果选中某个计数器后点“添加”则弹出该项目下的其它性能指标，选择需要的计数器后点“添加”

此时要注意，你登陆客户端（也就是你装有loadrunner机器）的用户应该是管理员身份，同时还要保证该用户在被监视的服务器上也是管理员身份。这样选择虽然监视窗口中仍会显示所有性能曲线，但是可以通过鼠标右键弹出菜单，选中你指定的某条曲线单独显示。方法是双击监视窗口放大显示，然后右键选择“仅显示指定图”监视窗口还可以互相叠加等操作，功能强大，通过右键菜单选择可以进行复杂显示操作。常用的还有web程序服务器图、数据库服务器资源图等，添加方法雷同。计数器有那些，有什么含义，理想值是多少

4.4 执行脚本

此时设置完毕后，那就简单了，点击“开始方案”注意观察吧。 点一下，ok！

4.4.1 生成结果

脚本执行完毕后，loadrunner会自动分析结果，生成分析结果图或表，方法是点导航栏

“结果”选现，在弹出窗口中选择“分析结果”

5 分析以及监视场景

在运行过程中， 可以监视各个服务器的运行情况（DataBase Server、Web Server 等）。 监视场景通过添加性能计数器来实现。这一章非常的重要， 确定系统瓶颈全靠它了。 下面重点讲讲需要添加那些计数器， 以及那些计数器代表什么意思。由于Win2000 Professional、Server 以及Advanced Server 提供的计数器不完全相同， 这里我们讨论将以Server 为基准。监视场景需要在Run 视图中设置然后， 出现添加计数器的对话框其他的操作就和控制面板“ 性能” 中添加性能计数器的操作一样， 这里不再详细说明。主要说明一下各个系统计数器的含义（ 数据库的计数器不做重点， 只是拿SQL Server2000 作为例子进行说明。因为数据库各个版本之间差异比较大， 请参考您使用的数据库系统的帮助）。

5.1 Memory相关

内存是第一个监视对象， 确定系统瓶颈的第一个步骤就是排除内存问题。内存短缺的问题可能会引起各种各样的问题。 Object（ 对象） Counters Description（ 描述） 参考值

Memory Available MBytes 物理内存的可用数（ 单位 至少要有Mbytes）。默认情况下IIS5.0 使用10% 的物理 50%的可用物理内存， 作为IIS 的文件缓存（file cache）。IIS 基本占用 2.5 MB，每个附加连接将在此基础上占用 10 KB 左右 物理内存的可用数（ 单位 Mbytes）。默认情况下IIS5.0 使用50%的可用物理内存， 作为IIS 的文件缓存（file cache）。IIS 基本占用 2.5 MB，每个附加连接将在此基础上占用 10 KB 左右。至少要有10% 的物理内存值当处理器向内存指定的位置请求一页（ 可能是数据或代码） 出现错误时， 这就构成一个Page Fault。如果该页在内存的其他位置， 该错误被称为软错误（ 用Transition Fault/sec 数器衡量）； 如果该页必须从硬盘上重新读取时， 被称为硬错误。许多处理器可以在有大软错误的情况下继续操作。但是， 硬错误可以导致明显的拖延。Page Faults/sec 是处理器每秒钟处理的错误页（ 包括软错误和硬错误）。Pages Input/sec 是为了解决硬错误页， 从硬盘上读取的页数， 而Page Reads/sec 是为了解决硬错误， 从硬盘读取的次数。如果 Page Reads/Sec 比率持续保持为 5， 表示可能内存不足。Pages/sec 是指为解析硬页错误从磁盘 读取或写入磁盘的页数。 Page/sec 推荐00-20（ 如果服务器没有足够的内存处理其工作负荷， 此数值将一直很高。如果大于80，表示有问题）。这些计数器的值比较低， 说明Web服务器响应请求比较快， 否则可能是服务器系统内存短缺引起（ 也可能是缓存太大， 导致系统内存太少）。Page Input/sec 的值可以衡量出硬错误页发生的速率， 通常它的值会于或者等于Page Reads/sec。Memory Cache Bytes Memory Page/sec Page Faults/sec Pages Input/sec Pages Input/sec Page Reads/sec Transition Faults/sec Memory Cache Bytes 文件系统缓存（File System Cache） 默默认情况下认情况下为50%的可用物理内存。如为50%的

可IIS5.0 运行内存不够时， 它会自动整理用物理内存缓存。需要关注该计数器的趋势变化 Internet File Cache Hits % File Cache Hits %是文件缓存命中 全部（ 对于一个Information File Cache 缓存需求的比例， 反映了IIS 的文件缓大部分是静Services Flushes 存设置的工作情况。而File Cache Hits 态网页组成 Global File Cache Hits 是文件缓存命中的具体值，File Cache 的网站）File Flushes 是自服务器启动之后文件缓存Cache Hits% 刷新次数， 如果刷新太慢， 会浪费内存； 如果刷新太快， 缓存中的对象会太频繁属于非常好！ 的丢弃生成， 起不到缓存的作用。通过File Cache Hits 和File Cache Flushes 可以得到一个适当的刷新值（ 参考IIS 的设置ObjectTTL 、MemCacheSize 、MaxCacheFileSize） Pool Paged Bytes Pool Nonpaged Bytes 这两个计数器监视服务器上各个进程的分页池字节数和非分页池字节数。 在访问数比较固定的情况下， Pool Nonpaged Bytes 是比较定的， 如果访问数逐步增加， 该值会缓慢的增加 Memory PoolPaged BytesPool Nonpaged Bytes Process Virtual Bytes Virtual Bytes( 实Virtual Bytes Working Set 数器监视IIS5.0 保留的例计数器 inetinfo 、虚地址空间的数量， 实例化为inetinfo dllhost) Working Set（ 实例进程(IIS 运行的核心)

和Dllhost 进程（ 隔离/ 连接池的应用程序必需的）。inetinfo 、dllhost） Working Set 计数器反映了每个进程使Dllhost#n 进程都用的内存页的数量。系统的内存页（pool 要添加计数器Page） 只能由操作系统的核心模块直接访问， 用户进程不能访问。运行IIS5.0 的服务器上， 负责web 连接的线程以及它需要的一些对象都保存在未分页的池中（nonpaged pool）， 比如文件句柄和socket 连接 Process Memory Private Bytes 指这个处理不能与其他处理共享的、已分配的当前字节数 Committed Bytes 是指以字节表示的确认虚拟内存。(确认内存是指为磁盘分 页文件在磁盘上保留的空间以便在需推荐不超过物理内存的75% 要将其写回磁盘时使用) 推荐部超过物理内存的75％ 内存问题主要检查应用程序是否存在内存泄漏。如果发生了内存泄漏，Process\\Private Bytes 计数器和Process\\Working Set 计数器的值往往会升高， 同时Available Bytes 的值会降低。内存泄漏应该通过一个长时间的， 用来研究分析当所有内存都耗尽时， 应用程序反应情况的测试来检验。

5.2 Processor相关

Object（ 对象） Sytem Counters Processor Queue Length Description（ 描述） 参考值 Processor Queue Length 是指处理列队中的线程数。即使在有多个处理器的计算机上处理器时间也会有一个单列队。不象磁盘计数器， 这个计数器仅计数就绪的线程， 而不计数运行中的线程。如果处理小于2。显示在由 Web 服务器所有处理器共享的队列中等待执行的线程数。处理器瓶颈会导致该值持续大于2

器列队中总是有两个以上的线程通常表示处理器堵塞 Processor %Processor Time CPU 使用率。这是查看处理器饱和状况的最佳计数器。显示所有 CPU 的线程处理时间。如果一个或多个处理器的该数值持续超过 90%，则表示此测试的负 载对于目前的硬件过于沉重。为多处理器服务器添加该计数器的 0 到 x 个实例 Context Switches/sec 指计算机上的所有处理器全都从一个线程转换到另一个线程的综合速率。当正在运行的线程自动放弃处理器时出现上下文转换， 由一个有更高优先就绪的线程占先或在用户模式和特权(内核)模式之间转换以使用执行或分系统服务。它是在计算机上的所有处理器上运行的所有线程的Thread: Context Switches/sec 的总数并且用转换数量衡量。在系统和线程对象上有上下文转换计数器 小于75%。排除内存因素， 如果该计数器的值比较大， 而同时网卡和硬盘的值比较低， 那么可以定CPU 瓶颈 System Context Switches/sec 如果切换次数到5000*CPU个数和10000*CPU 个数中， 说明它忙于切换线程而不是 处理ASP 脚本 Processo %Privileged Time % Privileged Time 是在特权模式下处理线程执行代码所花时间的百分比。当调用 Windows 系统服务时， 此服务经常在特权模式运行， 以便获

取对系统专有数据的访问。在用户模式执行的线程无法访问这些数据。对系统的调用可以是直接的(explicit)或间接的(implicit)， 例如页面错误或中断。不像某些早期的操作系统，Windows 除了使用用户和特权模式的传统保护模式之外， 还使用处理边界作为分系统保护。某些由Windows 为您的应用程序所做的操作除了出现在处理的特权时间内， 还可能在其他子系统处理出现 Time Switches/sec （ 实例化inetinfo 和dllhost 如果你决定要增加线程字节池的大小，你应该监视这三个计数器（ 包括上面的一个）。增加线数可能会增加上下文切换次数， 这样性能不会上升反而会下降。如果十个实例的上下文切换值非常高， 就应该减小线程字节池的大小 Time 这两个计数器能够反映处理器用在处理中断以及推迟处理调用的时间。如果处理器使用率超过Interrupts/sec 指处理器每秒钟接收并维90% 且 硬件中断的平均值。正常的线程操作在中断时悬停。大多数的系统时钟每Interrupt Time 大于隔 10 毫秒中断 Processor Interrupts/sec %DPC Time 如果处理器使用率超过90％，且Interrupts/sec time大于15％则处理器可能负载过重，并发生中断

处理器一次， 形成了间15%， 则处理隔活动的后台 Processor Interrupts/sec %DPC Time 这两个计数器能够反映处理器用在处理中断以及推迟处理调用的时间。如果处理器使用率超过Interrupts/sec 指处理器每秒钟接收并维90% 且 硬件中断的平均值。正常的线程操作在中断时悬停。大多数的系统时钟每Interrupt Time 大于隔 10 毫秒中断处理器一次， 形成了间15%， 则处理隔活动的后台。器可能负荷过重， 并发生中断。判断应用程序是否存在处理器瓶颈的方法： 如果Processor Queue Length 显示的队列长度保持不变（>=2） 个并且处理器的利用率%Processor Time 超过90%， 那么很有可能存在处理器瓶颈。

如果发现Processor Queue Length 显示的队列长度超过2， 而处理器的利用率却一直很 低， 那么或许更应该去解决处理器阻塞问题， 这里处理器一般不是瓶颈。如果系统由于应用程序代码效率低下或者系统结构设计有缺陷而导致大量的上下文切换（Context Switches/sec 显示的上下文切换次数比较大）， 那么就会占用大量的系统资源。如果系统的吞吐量降低并且CPU 的使用率很高，并且此现象发生时切换水平在15000 以上， 那么意味着上下文切换次数过高同时还可以比较Context Switches/sec 和%Privileged Time 来判断上下文切换是否过量。如果后者的值超过40%， 且上下文切换的速率也很高， 那么应该检查为什么会产生这样高的上下文切换。

5.3 网络吞吐量以及带宽

Object Network Interface Counter Bytes Total/se Description Bytes Total/sec 为发送和接收字节的速率， 包括帧字符在内。判断网络连接速该计数器的值和目前网度是否是瓶颈， 可以用该计数器的值和络的带宽相目前网络的带宽比较 参考值 改计数器的值和目前网络带宽相除，结果应该小于50% Web Servic Maximum Maximum Maximum Maximum Connections Connections ：“ 最大连接数” Attempts Total Connection Attempts ：“ 连接尝

试总数” 是从服务启动时利用 Web 服务尝试连接的总数。该计数器应用于全部所列的实例。 5.4 磁盘相关

Object（ 对象） Counters（ 计数器名称） Description（ 描述） 参考值 Object Network Counters Bytes Total/sec Description Bytes Total/sec 为发送和接收字节的速Interface 率， 包括帧字符在内。判断网络连接速度是否是瓶颈， 可以用该计数器的值和目前网络的带宽比较 参考值 Processo %Processor Time % Privileged Time CPU 使用率该计数器 对应于处理器执行Windows. 2000 内核命令（ 如处理SQL Server I/O 请求） 所用时间的百分比。如果 Physical Disk 计数器的值很高时该计数器的值也一直很高， 则考虑使用速度更快或效率更高的磁盘子系统。 % Disk Time 指所选 磁盘驱动器忙于为读或写入请求提供服务所用的时间的百分比。如果三个计数器都比较大， 那 么硬盘不是瓶颈。如果只有%Disk Time 比较大， 另外两个都比较适中， 硬盘可能PhysicalDisk %Disk Time

会是瓶颈。在记录该计数器之前， 请 在 Windows 2000 的命令行窗口中运行 diskperf -yD 。若数值持续超过 80%， 则可能内存泄漏。 PhysicalDisk AverageDisk Queue Length 指读取和写入请求(为所选磁盘在实例间隔中列队的)的平均数。 指在此盘上读取操作的速率 指在此盘上写入操作的速率 PhysicalDisk PhysicalDisk PhysicalDisk Disk Writes/sec 判断磁盘瓶颈的方法是通过以下公式来计算：

每磁盘的I/O 数 = [读次数 + （4 * 写次数）] / 磁盘个数

如果计算出的每磁盘的I/O 数大于磁盘的处理能力， 那么磁盘存在瓶颈。

5.5 Web应用程序

这里以ASP.NET 开发的Web 应用程序为例进行说明。 Object ASP.NET Applications Counters Request/Sec Request Executing Description 参考值 每秒执行的请求数。 如果Request/Sec ApplicationsRequest Executing 当前执行的请求数。的值比较小， 你 的Web 程序可能 是瓶颈 ASP.NET ASP.NETRequestWait 最近的请求在队列中 Time 等待的毫秒数。执行Request Executing 最近的请求所用的毫Time 秒数。Queued 在理想 状况下应该接近0， Request Queued 等候处理的请求数。该计数器应保持接近 0。超过 IIS 队列长

度会出如果这两个值太大， 那么需要重现“服务器太忙”错误 5.6 SQL Server

这里针对SQL Server2000， 而且只是列出比较关键的几个。更加详细的信息可以参考SQL Server 的联机文档。 SQL Server: Buffer Manager Page Reads/sec 每秒发出的物理数据库页读取数。这一统计信息显示的是在所有数据 库间的物理页读取总数。由于物理I/O 的开销大， 可以通过使用更大 的数据高速缓存、智能索引、更高效的查询或者改变数据库设计等方法， 使开销减到最小。 每秒为数据库启动的事务数 SQL Server:Databases Transactions/sec 这里针对SQL Server2000， 而且只是列出比较关键的几个。更加详细的信息可以参考SQL Server 的联机文档。

5.7 Network Delay

如果要监视的两台计算机在同一个局域网络内， 建议不要使用Network Delay Monitor。 因为在同一局域网内，Network Delay 会非常的小， 网络监视器会有足够的时间在每秒钟内发送成百上千的请求， 这样会导致源计算机（source machine） 的CPU 和内存超负荷工作。

默认情况下“Enable display of network nodes by DNS names” 选择是没有选中的，

因为

选中它会明显的降低该监视器的速度。

6 分析实时监视图表

这一章仅仅介绍几个最重要的图表。

Q1 事务响应时间是否在可接受的时间内？ 哪个事务用的时间最长？

看Transaction Response Time 图， 可以判断每个事务完成用的时间， 从而可以判断出那个事务用的时间最长， 那些事务用的时间超出预定的可接受时间。 Q2 网络带宽是否足够?

“Throughput”图显示在场景运行期间的每一秒钟， 从Web Server 上接受到的数据量的值。

拿这个值和网络带宽比较， 可以确定目前的网络带宽是否是瓶颈。

如果该图的曲线随着用户数的增加， 没有随着增加， 而是呈比较平的直线， 说明目前的 网络速度不能够满足目前的系统流量。 Q3 硬件和操作系统能否处理高负载?

“Windows Resources” 图实时地显示了Web Server 系统资源的使用情况。利用该图提供的数据， 可以把瓶颈定位到特定机器的某个部件。

7 分析原则

● 具体问题具体分析（这是由于不同的应用系统，不同的测试目的，不同的性能关注点）

● 查找瓶颈时按以下顺序，由易到难。

服务器硬件瓶颈-〉网络瓶颈（对局域网，可以不考虑）-〉服务器操作系统瓶颈（参数配置）-〉中间件瓶颈（参数配置，数据库，web服务器等）-〉应用瓶颈（SQL语句、数据库设计、业务逻辑、算法等）

注：以上过程并不是每个分析中都需要的，要根据测试目的和要求来确定分析的深度。对一些要求低的，我们分析到应用系统在将来大的负载压力（并发用户数、数据量）下，系统的硬件瓶颈在哪儿就够了。

● 分段排除法 很有效 分析的信息来源：

● 根据场景运行过程中的错误提示信息 ● 根据测试结果收集到的监控指标数据 7.1、错误提示分析 分析实例：

1、Error: Failed to connect toserver“payment.baihe.com″: [10060] Connection Error: timed out Error:Server“user.baihe.com″has shut down the connection prematurely 分析：

A、应用服务死掉。

（小用户时：程序上的问题。程序上处理数据库的问题） B、应用服务没有死 （应用服务参数设置问题）

例：在许多客户端连接Weblogic应用服务器被拒绝，而在服务器端没有错误显示，则有可能是Weblogic中的server元素的AcceptBacklog属性值设得过低。如果连接时收到connection refused消息，说明应提高该值，每次增加25％ C、数据库的连接

在应用服务的性能参数可能太小了或者数据库启动的最大连接数（跟硬件的内存有关） 2、Error: Page download timeout (120 seconds) has expired 分析：可能是以下原因造成

A、应用服务参数设置太大导致服务器的瓶颈 B、页面中图片太多

C、在程序处理表的时候检查字段太大多 7.2、监控指标数据分析 1、最大并发用户数

应用系统在当前环境（硬件环境、网络环境、软件环境（参数配置））下能承受的最大

并发用户数。

在方案运行中，如果出现了大于3个用户的业务操作失败，或出现了服务器shutdown的情况，则说明在当前环境下，系统承受不了当前并发用户的负载压力，那么最大并发用户数就是前一个没有出现这种现象的并发用户数。

如果测得的最大并发用户数到达了性能要求，且各服务器资源情况良好，业务操作响应时间也达到了用户要求，那么OK。否则，再根据各服务器的资源情况和业务操作响应时间进一步分析原因所在。 2、业务操作响应时间

● 分析方案运行情况应从平均事务响应时间图和事务性能摘要图开始。使用“事务性能摘要”图，可以确定在方案执行期间响应时间过长的事务。

● 细分事务并分析每个页面组件的性能。查看过长的事务响应时间是由哪些页面组件引起的？问题是否与网络或服务器有关？

● 如果服务器耗时过长，请使用相应的服务器图确定有问题的服务器度量并查明服务器性能下降的原因。如果网络耗时过长，请使用“网络监视器”图确定导致性能瓶颈的网络问题

2-5-10原则：简单说，就是当用户能够在2秒以内得到响应时，会感觉系统的响应很快；当用户在2-5秒之间得到响应时，会感觉系统的响应速度还可以；当用户在5-10秒以内得到响应时，会感觉系统的响应速度很慢，但是还可以接受；而当用户在超过10秒后仍然无法得到响应时，会感觉系统糟透了，或者认为系统已经失去响应，而选择离开这个Web站点，或者发起第二次请求。

8．测试结果

配置脚本后进行测试得到如下结果 总报告reports

用户数Running Vusers:

每秒点击率Hits per Second

本文来源：https://www.bwwdw.com/article/0yn6.html