事务是在脚本中定义的某个操作，而点击是在测试中产生的http请求。

例如，我定义了一个提交form的事务，我关心的也就是这个提交操作的数量与分值及响应时间的关系。而实际上这个form提交可能产生多个http请求。首先提交form本身有一次http请求，如果此请求被服务器端接受，则要转向到结果页面的第一个页面，又是一次http请求，如果这个页面中含有图片的话，那么每个图片都需要通过一个http连接来下载。

所以：

平均每个事务产生的点击数

 ＝ 事务的数量＋事务的数量×事务成功概率＋事务的数量×事务成功概率×平均每个页面中含有的图片数

 ＝ 事务的数量×（1＋平均事务成功概率×（1＋平均每个页面含有的图片数））

发现现在有相当一部分使用LoadRunner的朋友面对LoadRunner的一大堆测试结果常常无所适从，不知道如何把这些测试结果真正利用起来。因此我把我个人学习LoadRunner的一些笔记和心得贴在这里，它到目前为止还是一堆很杂乱的东西，并没有形成一个系统的东西，而且其中可能会存在很多错误，希望各位测试同行能多多批评指教。

　　一、 Web Page Breakdown

　　DNS 解析时间： 显示使用最近的 DNS 服务器将 DNS 名称解析为 IP 地址所需的时间； DNS 查找度量是指示 DNS 解析问题或 DNS 服务器问题的一个很好的指示器；

　　Connect 时间： 显示与包含指定 URL 的 Web 服务器建立初始连接所需的时间； Connect 度量是一个很好的网络问题指示器；它还可表明服务器是否对请求做出响应；

　　First buffer 时间： 显示从初始 HTTP 请求到成功收回来自 WEB 服务器的第一次缓冲时为止所经过的时间； First buffer 度量是很好的 Web 服务器延迟和网络滞后指示器；

　　SSL Handshaking time ： 显示建立 SSL 连接所用的时间

　　Receive Time ： 显示从服务器收到最后一个字节并完成下载之前经过的时间；接收度量是很好的网络质量指示器；

　　FTP 验证时间： 显示验证客户端所用的时间。

　　Client Time ： 显示因浏览器思考时间或其他与客户端有关的延迟而使客户机上的请求发生延迟时，所经过的时间。

　　Error 时间： 显示从发出 HTTP 请求到返回错误消息这期间所经过的平均时间

　　二、 关于 TPS （ Transactions per Second ）： 每秒处理事务数

　　这个值可以说明系统在特定的负载情况下，每秒可以处理多少个客户端请求，这是一个衡量服务器端性能的重要指标，相信各位在进行性能测试的时候经常会用到这个指标。但是一直以来我都有一个疑问，到底这个值是怎么算出来的。既然是每秒事务数，那算法自然是“事务数 / 时间”。事务数很好理解，执行了多少就是多少，关键是这个时间。是整个场景执行的时间，还是仅仅是在服务器端执行的时间？因为我们知道，这两个时间肯定是有区别的，前者还包括 thinktime 的时间、 pacing 的时间以及在网络上耗费的时间等等。

　　为了弄明白这个问题，我今天特地查了一下帮助文档，看到上面是这么说的：“每秒事务数图显示在场景或会话步骤运行的每一秒中，每个事务通过、失败以及停止的次数。”如果按照这句话去理解，那么上面那个问题的答案应该是后者，也就是说，在 Transaactions per Second 这张图中， LoadRunner 是针对场景运行过程中的每一个时间点取样一次，显示在这个时间点上每个事务的通过、失败以及停止的个数。

　　另外，我还在 Analysis 里面找了一下，发现图表的时间显示粒度也是可以设置的。具体方法为：在图表上点击右键 -> 选择“ Set Granularity ”或者直接按 Ctrl+G 。我试着把时间粒度调成以毫秒为单位，结果 LoadRunner 提示当前不支持以毫秒为显示粒度，由此我推断 LoadRunner 对于 Transactions per Second 这张图，最小的取样粒度为 1 秒。

　　三、 事务响应时间（百分比）图

　　这个图显示的是事务响应时间范围的分布情况。在场景的执行中，每个定义的事务可能会不止被处理一次（因为设置了持续时间或者迭代次数）， LoadRunner 会为每个事务实例的处理分别记录响应时间。在 Summary Report 中， LoadRunner 会针对每个事务的响应时间数据集合，分别取它的最大值、最小值和平均值，通常我们会关注响应时间的平均值。然而很多时候，单单是平均响应时间可能是不够的，因为一旦最大值和最小值出现较大的偏差，即便平均响应时间处在可以接受的范围内，但并不意味着整个系统的性能就是可以接受的，我们有必要再借助其它的分析报表来进一步分析，此时事务响应时间（百分比）图就派上用场了。

　　事务响应时间（百分比）给出的是每个事务的响应时间按百分比的分布情况，它告诉我们本次测试有多少个事务的平均响应时间是落在我们可以接受的时间范围之内。如果最大响应时间非常长，但是绝大多数事务（通常情况下以 95% 为参考）的响应时间具有可以接受的响应时间，则我们认为整个系统的性能还是可以接受的。

　　注意： Analysis 将对每个可用事务百分比的事务响应时间取近似值。因此 Y 轴的值可能并不准确。

　　四、 事务响应时间（负载下）图

　　这个图显示的是事务响应时间随着场景中虚拟用户的逐渐增长的变化趋势图，该图可以帮助我们查看 Vuser 负载对性能问题的影响。当我们需要了解某个事务的响应时间随着虚拟用户的增加而产生的变化时，可以通过在控制台中设置一个渐变负载的场景的方式来实现。例如每 5 分钟加载 10 个用户等，然后考察得到的这张图表，就能够对此有一个比较好的理解。

性能测试工程师基本上都能够掌握利用测试工具来作负载、压力测试，但多数人对怎样去分析工具收集到的测试结果感到无从下手，下面我就把个人工作中的体会和收集到的有关资料整理出来，希望能对大家分析测试结果有所帮助。 分析原则：
1. 具体问题具体分析（这是由于不同的应用系统，不同的测试目的，不同的性能关注点）
2. 查找瓶颈时按以下顺序，由易到难。
    服务器硬件瓶颈-〉网络瓶颈（对局域网，可以不考虑）-〉服务器操作系统瓶颈（参数配置）-〉中间件瓶颈（参数配置，数据库，web服务器等）-〉应用瓶颈（SQL语句、数据库设计、业务逻辑、算法等）
    注：以上过程并不是每个分析中都需要的，要根据测试目的和要求来确定分析的深度。对一些要求低的，我们分析到应用系统在将来大的负载压力（并发用户数、数据量）下，系统的硬件瓶颈在哪儿就够了。
3 分段排除法 很有效
分析的信息来源：
1 根据场景运行过程中的错误提示信息
2 根据测试结果收集到的监控指标数据
一．错误提示分析
分析实例：
1 Error: Failed to connect to server “10.10.10.30:8080″: [10060] Connection
  Error: timed out Error: Server “10.10.10.30″ has shut down the connection prematurely
分析：
 A、应用服务死掉。
（小用户时：程序上的问题。程序上处理数据库的问题）
 B、应用服务没有死
（应用服务参数设置问题）
    例：在许多客户端连接Weblogic应用服务器被拒绝，而在服务器端没有错误显示，则有可能是Weblogic中的server元素的AcceptBacklog属性值设得过低。如果连接时收到connection refused消息，说明应提高该值，每次增加25％
 C、数据库的连接
(1、在应用服务的性能参数可能太小了 2、数据库启动的最大连接数（跟硬件的内存有关）)
2 Error: Page download timeout (120 seconds) has expired
分析：可能是以下原因造成
 A、应用服务参数设置太大导致服务器的瓶颈
 B、页面中图片太多
 C、在程序处理表的时候检查字段太大多
二．监控指标数据分析
1．最大并发用户数：
应用系统在当前环境（硬件环境、网络环境、软件环境（参数配置））下能承受的最大并发用户数。
    在方案运行中，如果出现了大于3个用
户的业务操作失败，或出现了服务器shutdown的情况，则说明在当前环境下，系统承受不了当前并发用户的负载压力，那么最大并发用户数就是前一个没有出现这种现象的并发用户数。
    如果测得的最大并发用户数到达了性能要求，且各服务器资源情况良好，业务操作响应时间也达到了用户要求，那么OK。否则，再根据各服务器的资源情况和业务操作响应时间进一步分析原因所在。
2．业务操作响应时间：
     分析方案运行情况应从平均事务响应时间图和事务性能摘要图开始。使用“事务性能摘要”图，可以确定在方案执行期间响应时间过长的事务。
    细分事务并分析每个页面组件的性能。查看过长的事务响应时间是由哪些页面组件引起的？问题是否与网络或服务器有关？
  如果服务器耗时过长，请使用相应的服务器图确定有问题的服务器度量并查明服务器性能下降的原因。如果网络耗时过长，请使用“网络监视器”图确定导致性能瓶颈的网络问题
3．服务器资源监控指标：
内存：
1 UNIX资源监控中指标内存页交换速率（Paging rate），如果该值偶尔走高，表明当时有线程竞争内存。如果持续很高，则内存可能是瓶颈。也可能是内存访问命中率低。
2 Windows资源监控中，如果Process\Private Bytes计数器和Process\Working Set计数器的值在长时间内持续升高，同时Memory\Available bytes计数器的值持续降低，则很可能存在内存泄漏。
内存资源成为系统性能的瓶颈的征兆:
很高的换页率(high pageout rate);
进程进入不活动状态;
交换区所有磁盘的活动次数可高;
可高的全局系统CPU利用率; 
内存不够出错(out of memory errors)
处理器：
1 UNIX资源监控（Windows操作系统同理）中指标CPU占用率（CPU utilization），如果该值持续超过95%，表明瓶颈是CPU。可以考虑增加一个处理器或换一个更快的处理器。如果服务器专用于SQL Server,可接受的最大上限是80-85% 
合理使用的范围在60%至70%。
2 Windows资源监控中，如果System\Processor Queue Length大于2，而处理器利用率（Processor Time）一直很低，则存在着处理器阻塞。
CPU资源成为系统性能的瓶颈的征兆: 
很慢的响应时间(slow response time) 
CPU空闲时间为零(zero percent idle CPU) 
过高的用户占用CPU时间(high percent user CPU) 
过高的系统占用CPU时间(high percent system CPU) 
长时间的有很长的运行进程队列(large run queue size sustained over time)
磁盘I/O：
1 UNIX资源监控（Windows操作系统同理）中指标磁盘交换率（Disk rate），如果该参数值一直很高，表明I/O有问题。可考虑更换更快的硬盘系统。
2 Windows资源监控中，如果 Disk Time和Avg.Disk Queue Length的值很高，而Page Reads/sec页面读取操作速率很低，则可能存在磁盘瓶径。
I/O资源成为系统性能的瓶颈的征兆 :
过高的磁盘利用率(high disk utilization) 
太长的磁盘等待队列(large disk queue length) 
等待磁盘I/O的时间所占的百分率太高(large percentage of time waiting for disk I/O) 
太高的物理I/O速率:large physical I/O rate(not sufficient in itself) 
过低的缓存命中率(low buffer cache hit ratio(not sufficient in itself)) 
太长的运行进程队列，但CPU却空闲(large run queue with idle CPU)
4．数据库服务器：
SQL Server数据库：
1 SQLServer资源监控中指标缓存点击率（Cache Hit Ratio），该值越高越好。如果持续低于80%，应考虑增加内存。
2 如果Full Scans/sec（全表扫描/秒）计数器显示的值比1或2高，则应分析你的查询以确定是否确实需要全表扫描，以及SQL查询是否可以被优化。 
3 Number of Deadlocks/sec(死锁的数量/秒)：死锁对应用程序的可伸缩性非常有害，并且会导致恶劣的用户体验。该计数器的值必须为0。
4 Lock Requests/sec(锁请求/秒)，通过优化查询来减少读取次数，可以减少该计数器的值。
Oracle数据库：
1 如果自由内存接近于0而且库快存或数据字典快存的命中率小于0.90，那么需要增加SHARED_POOL_SIZE的大小。
快存（共享SQL区）和数据字典快存的命中率： 
select(sum(pins-reloads))/sum(pins) from v$librarycache; 
select(sum(gets-getmisses))/sum(gets) from v$rowcache; 
自由内存： select * from v$sgastat where name=’free memory’; 
2 如果数据的缓存命中率小于0.90，那么需要加大DB_BLOCK_BUFFERS参数的值（单位：块）。
缓冲区高速缓存命中率：
select name,value from v$sysstat where name in (’db block gets’,
‘consistent gets’,'physical reads’) ;
Hit Ratio = 1-(physical reads / ( db block gets + consistent gets))
3 如果日志缓冲区申请的值较大，则应加大LOG_BUFFER参数的值。
日志缓冲区的申请情况 ：
select name,value from v$sysstat where name = ‘redo log space requests’ ;
4 如果内存排序命中率小于0.95，则应加大SORT_AREA_SIZE以避免磁盘排序 。
内存排序命中率 ：
select round((100*b.value)/decode((a.value+b.value), 0, 1, (a.value+b.value)), 2)from v$sysstat a, v$sysstat b where a.name=’sorts (disk)’ and b.name=’sorts (memory)’
注：上述SQL Server和Oracle数据库分析，只是一些简单、基本的分析，特别是Oracle数据库的分析和优化，是一门专门的技术，进一步的分析可查相关资料。

 

  性能测试的结果分析是性能测试的重中之重。在实际工作中，由于测试的结果分析比较复

杂、需要具备很多相关的专业知识，因此常常会感觉拿到数据不知从何下手。这也是我学习性能

测试过程中感觉比较尴尬和棘手的事，为此我在研读了《WEB性能测试实战》后特作了以下笔

记，这里只是书中第4章WEB应用程序性能分析的一

部分，贴出来希望和大家共同讨论：

一：性能分析的基础知识：

    1.几个重要的性能指标：相应时间、吞吐量、吞吐率、TPS（每秒钟处理的交易数）、点

击率等。

    2.系统的瓶颈分为两类：网络的和服务器的。服务器瓶颈主要涉及：应用程序、WEB服务

器、数据库服务器、操作系统四个方面。

    3.常规、粗略的性能分析方法：

   当增大系统的压力（或增加并发用户数）时，吞吐率和TPS的变化曲线呈大体一致，则系统

基本稳定；若压力增大时，吞吐率的曲线增加到一定程度后出现变化缓慢，甚至平坦，很可能是

网络出现带宽瓶颈，同理若点击率/TPS曲线出现变化缓慢或者平坦，说明服务器开始出现颈。

    4.作者提出了如下的性能分析基本原则，此原则本人十分赞同：

            ——由外而内、由表及里、层层深入

    应用此原则，分析步骤具体可以分为以下三步：

   第一步：将得到的响应时间和用户对性能的期望值比较确定是否存在瓶颈；

   第二步：比较Tn（网络响应时间）和Ts（服务器响应时间）可以确定瓶颈发生在网络还是服

务器；

   第三步：进一步分析，确定更细组件的响应时间，直到找出发生性能瓶颈的根本原因。

二：以WEB应用程序为例来看下具体的分析方法：

    1.用户事务分析：

    a.事务综述图(Transaction Summary ):以柱状图的形式表现了用户事务执行的成功与

失败。通过分析成功与失败的数据可以直接判断出系统是否运行正常。若失败的事务非常多，则

说明系统发生了瓶颈或者程序在执行过程中发生了问题。

    b.事务平均响应时间分析图（Average Transaction Response Time）: 该图显示在

测试场景运行期间的每一秒内事务执行所用的平均时间，还显示了测试场景运行时间内各个事务

的最大值、最小值和平均值。通过它可以分析系统的性能走向。若所有事务响应时间基本成一条

曲线，则说明系统性能基本稳定；否则如果平均事务响应时间逐渐变慢，说明性能有下降趋势，

造成性能下降的原因有可能是由于内存泄漏导致。

    c.每秒通过事务数分析图（Transaction per Second即TPS）:显示在场景运行的每一

秒中，每个事 务通过、失败以及停止的数量。通过它可以确定系统在任何给定时刻的实际事务

负载。若随着测试的进展，应用系统在单位时间内通过的事务数目在减少，则说明服务器出现瓶

颈。

     d.每秒通过事务总数分析图（Total Transactions per Second）:显示场景运行的

每一秒中，通过、失败以及停止的事务总数。若在同等压力下，曲线接近直线，则性能基本趋于

稳定；若在单位时间内通过的事务总量越来越少，即整体性能下降。原因可能是内存泄漏或者程

序中的缺陷。

      e.事务性能摘要图（Transaction Performance Summary）:显示方案中所有事务的

最小、最大平均执行时间，可以直接判断响应时间是否符合客户要求（重点关注事务平均、最大

执行时间）。

      f.事务响应时间与负载分析图（Transaction Response Time Under load）:通过

该图可以看出在任一时间点事务响应时间与用户数目的关系，从而掌握系统在用户并发方面的性

能数据。

      g.事务响应时间（百分比）图（Transaction Response Time(percentile)）:该

图是根据测试结果进行分析而得到的综合分析图。分析该图应从整体出发，若可能事务的最大响

应时间很长，但如果大多数事务具有可接受的响应时间，则系统的性能是符合。

      h.事务响应时间分布情况图（Transaction Response Time (Distribution)）:该

图显示了测试过程中不同响应时间的事务数量。若系统预先定义了相关事务可以接受的最小和最

大事务响应时间，则可以使用此图确定系统性能是否在接受范围内。

      分析到这一步，只能大概判断出瓶颈可能会出在那，要具体定位瓶颈还需要更深入

的分析。没有贴图，看起来有点费劲，如果你对这些图都比较了解，应该是比较简单的.

一、概述 LAODRUNNER8.1 作为专业的性能测试工具,通过模拟成千上万的用户对被测应用进行操作和请求,在实验室环境中精确重现生产环境中任意可能出现的业务压力,然后通过在测试过程中获取的信息和数据来确认和查找软件的性能问题,分析性能瓶颈.

LOADRUNNER提供了三个大主要模块,这三个模块既可以作为独立的工具分别完成各自的功能,又可以作为LOADRUNNER的一部分彼此衔接,与其他模块共同完成软件性能的整体测试.这三大模块主要是:

Ø         VITUAL USER GENERATOR--------用于录制脚本

Ø         MERCURY LOADRUNNER CONTROLLER---------用于创建,运行和监视场景

Ø         MERCURY LOADRUNNER ANALYSIS--------用于分析测试结果;

二、LOADRUNNER8.1 安装 LAODRUNNER8.安装过程比较简单,只需按系统的提示一步一步操作就可以了,这里对安装过程中的一些要点进行简要的说明.

Ø         安装类型 

安装盘内有两个盘片,MERCURY LOADRUNNER8.1和MECURY LOADRUNNER 8.0ADD-INS.前者包括了LR安装程序及常用组件,后者全部为组件,各组件的作用在安装盘中都有详细的提示.

Ø         LICENSE 类型

LICENSE类型说明如下:

PERMANENT  永不过期的LICENSE;

TIME LIMITED  限定了使用的起始时间和使用周期;

TEMPORARY   从安装后开始计算,限定了使用的天数;

VUD-BASED   限定了虚拟用户数量

PLUGGED   需要DONGLE,也就是HARDWARE KEY,DONGLE在中国被音译为“狗”,主要是防止软件被盗用

Ø         RPM和WEB SERVER之间的鉴权

如果在安装时选择安装REMOTE PERFORMANCE MONITOR SERVER,LOADRUNNER会弹出一个要求输入用户名和密码的对话框,

REMOTE PERFORMANCE MONITOR SERVER是一个远程监视场景的服务器,为测试人员提供WEB化的场景页面,用于实现多台及其通过浏览器同时在线监视场景.这里设定用户名和口令的目的主要是为了REMOTE PERFORMANCE MONITOR(RPM)和运行了IIS的WEB SERVER之间进行鉴权.在RPM安装完毕之后,只有在LOADRUNNER CONTROLLER的RPM用户配置对话框中输入指定的用户名和口令,系统才能允许进行远程监控.

Ø         设定LOADRUNNER GENERATOR如何登陆到CONTROLLER

LOADRUNNER提供了两种方式让LOAD GENERATOR的虚拟用户登陆到CONTROLLER,

n         ALLOW VIRTUALUSERS TO RUN ON THIS MACHINE WITHOUT USER LOGIN

n         MANUAL LOG IN TO THE LOAD GENERATOR MACHINE

三、使用VITUAL USER GENERATOR录制开发脚本 LOADRUNNER脚本的开发过程一般需要以下几个过程

Ø         使用LOADRUNNER的VIRTUAL USER GENERATOR录制基本的测试脚本；

Ø         根据系统需求编辑测试脚本，看能否通过，

Ø         在单机模式下运行脚本看能否通过，

 1．选择协议要想正确的选择LOADRUNNER的脚本协议，首先要从LOADRNNER的工作原理上深入理解协议的作用和意义。LOADRUNER启动后，在任务栏上会有一个LOADRNNER AGENT PROCESS的进程，这个进程的一项重要的工作就是监视各种协议的客户端和服务器端的通信。只要是能够支持的协议，LOADRUNNER在录制的过程中就可以通过脚本语言将通信过程录制下来。所以只要明确了被测软件的通信过程和所使用的协议，LOADRUNNER才能正确的录制脚本。对于常见的应用软件，我们可以根据被测应用是B/S结构还是C/S结构来选择协议；

Ø         对于B/S结构，可以选择WEB（HTTP/HTTML）协议；

Ø         对于C/S结构，可以根据后端数据库的类型来选择，如SYBASECTLIB协议用于测试后台数据库为SYBASE的应用，MS SQL SERVER协议用于测试后台数据库为SQL SERVER的应用；

Ø         对于没有数据库的WINDOWS应用，可以选择WINDOWS SOCKETS这个底层的协议；

这里需要说明的是，无论使用哪种协议，LOADRUNNER的测试流程都基本是一样的，只有在设定细节上有所不同，测试人员只要对被测应用的技术架构熟悉了，就能够成功完成脚本的录制。

 2．录制测试脚本根据需求设定好脚本录制参数后，在VIRTUAL USER GENERATOR主窗口单击START RECORD按钮，系统就开始自动录制脚本。

Ø         理解脚本的三个部分；

LOADRUNNER 将测试脚本分为3个部分，VUSER_INIT,VUSER_END和ACTION,其中VUSER_INIT和VUSER_END一般用于存放应用程序初始化的脚本和注销关闭的脚本,在重复执行的时候,这两部分的内容只执行一次.而ACTION部分用于存放实际的操作脚本,这部分脚本可以多次执行,测试人员还可以根据需要创建多个ACTION 脚本,但不能创建VUSER_INIT和VUSER_END.

Ø         熟悉录制脚本工具栏；

在录制的过程中屏幕上有一个悬浮的工具栏,这是控制脚本录制的工具栏,是脚本录制过程中测试人员和VUGEN交互的主要平台,每个可用的按钮都可以执行相应的操作;

Ø         查看脚本；

n         SCRIPT. VIEW:查看全部的脚本;

n         TREE VIEW:查看从每个URL获取来的页面;

3.开发测试脚本 Ø         插入事务

有时侯测试人员根据项目需要,除了要衡量整个测试脚本的性能外,还想获取到脚本中的某一段和几段操作的性能数据；以便更详细的知道具体的是用户的哪些动作对性能的影响比较大.LOADRUNNER采用在脚本中定义事务来达到这一要求.

所谓事务(TRANSACTION),就是在脚本定义中定义的某段操作(ACTION),更确切的说,就是一段脚本语句.定义事务时,首先在脚本中找到事务的开始和结束位置,然后分别插入一个事务起始标记,这样,当脚本运行的时候,LOADRUNER会自动在事务的起始点计时,脚本在运行到事务结束点时计时结束,系统会自动记录这段操作的运行时间等性能数据；在脚本运行完毕后,系统会在结果信息中单独反映每个事务运行结果.

事务的插入操作可以在脚本运行过程中进行,也可以在脚本录制完毕后进行,建议在脚本录制完毕后进行.

n         定位事务语句的集合

n         插入事务起始点语句

将光标放置在欲定义事务的语句集合中第一条语句的上面一行,单击工具栏上的INSERT START TRANSACTION按钮,输入事务名称后,单击OK按钮,系统自动在脚本语句中插入如下语句:

LR_START_TRANSACTION(“事务名称”)

n         插入事务结束点语句

将光标放置在欲定义事务的语句集合中最后一条语句的后面一行,单击工具栏上的INSERT END TRANSACTION按钮,输入事务名称后,单击OK按钮,系统自动在脚本语句中插入如下语句:

LR_END_TRANSACTION(“事务名称“)

Ø         插入集合点

多用户同时加载并发,并发过程仅仅体现在开始执行的那一刹那,随着服务器对请求的响应时间的不一致或系统环境条件的限制,在运行过程中能集合到一点的可能性微乎其微,所以将一定数量的用户同时加载并不是真正意义上的并发.

系统压力最大的情况是:所有用户都集中到系统瓶颈的某个点上进行操作,从脚本的角度来讲,这个点就是执行脚本的某一条或一段语句,为了真实模拟这个最坏的情况,查看系统在最坏情况下的反映,LOADRUNNER提供了集合点的功能,帮助测试人员实现真正意义上的并发.

使用LOADRUUNER实现集合点功能的方法如下:

n         在脚本准备访问的语句上面插入一个空白行,并将光标移到该空白行上;

n         选择INSERT|RENDEZVOUS命令,系统弹出RENDEZVOUS对话框,

n         输入集合点名称后点击OK按钮.

系统会自动在脚本中插入下面语句

LR_RENDEZVOUS(“集合点名称”)

这样的脚本在运行的时候,就可以在集合点处实现真正的并发了.运行带有集合点的脚本时可以在SCENARIO GROUP列表的RENDEZ一栏看到虚拟用户的聚集过程.

需要说明的是,这部分内容仅介绍了如何在LOADRUNNER的脚本中插入集合点,LOADRUNNER允许测试人员对集合点的执行过程进行更详细的设定,如聚集的用户数,系统等待时间和等待策略等.

Ø         脚本参数化

让所有用户都使用相同的数据来运行,对系统造成的压力与实际情况会有所不同.而对于那些禁止一个用户多次登陆的系统,也就严重到无法测试的地步了.为了解决这个问题,让系统更加真实的模拟多用户使用的实际环境,LOADRUNNER提供了对脚本进行参数化输入的功能;

所谓的脚本参数化,就是针对脚本中的某些常量,定义一个或多个包含数据源的参数来取代,让场景中不同的虚拟用户在执行相同的脚本时,分别使用参数数据源中的不同数据代替这些常量,从而达到模拟多用户真实使用系统的目的.

n         确定需要参数化的常量

打开脚本后,首先要确定哪些常量需要参数化;

n         准备数据

既然是使用多组数据来替换常量,就需要在使用参数替换常量之前,针对性的准备一些模拟真实情况的数据.LOADRUNNER允许多种类型的数据源,如DAT的文本文件,电子表格,来自ODBC的数据库数据和其他系统提供的数据源等,每种类型的数据源都要求了不同的格式,这些在LOADRUNER的帮助文件中都有详细的说明;

n         对脚本进行参数化

在脚本中用鼠标选中要参数化的常量,然后单击鼠标右键,在弹出的快捷菜单中选择REPLACE WITH A PARAMETER命令,系统弹出SELECT OR CREATE PARAMETER对话框.通过这个对话框可以选择一个已经存在的参数,还可以根据需要创建一个新的参数.

单击PROPERTIES按钮,可以在PARAMETER PROPERTIES 对话框中设定脚本执行时参数的详细替换方式,不同的数据源类型的属性设定对话框的内容也会有所不同.

n         注:参数化输入只能用于函数中的参数,不能用参数代替非函数中的常量参数;

Ø         插入检查点

LOADRUNNER检查点的功能主要用来验证某个界面上是否存在指定的TEXT或IMAGE等对象，在使用LOADRUNNER测试WEB应用时，可以检查压力较大时WEB服务器能否返回正常的页面。

n         定位要检查的页面

定位需要检查的页面，最好将脚本视图切换到TREE VIEW方式，这样就可以直观地查看到LOADRUNNER录制时获取的每个页面了。在TREE VIEW视图中用鼠标单击页面左侧列表中页面对应的URL，就能迅速查看到准备检查的页面和页面上需要检查的图象或文本信息。

n         插入文字检查点

选择相应的URL，单击鼠标右键，在系统弹出的菜单中选择INSERT AFTER或INSERT BEFORE命令，在URL的脚本前面或后面插入函数，在ADD STEP对话框中可以插入很多的函数，如果想为WEB应用插入图像或文本检查点，需要选择WEB CHECKS下面的IMAGE CHECK或TEXT CHECK，

在系统弹出的检查点属性对话框中，输入要查询的文字或图像名称后，系统会自动在TREE VIEW视图中的树型列表中插入类似的STEP。

LOADRUNNER 还允许对要检查的文字内容和图像名称进行参数化，参数化的过程可以在插入检查点的 过程中实现，还可以在插入之后重新打开脚本实现。要想在插入检查点时就直接实现参数化，只需要在设置被检查对象的名称时单击ABC按钮，创建或选择参数输入就可以了。

n         设定与检查点有关的选项

         系统在执行时是否起用检查点，是由一个系统参数控制的，该参数的设定方法为：VUSER|RUN-TIME SETTINGS|PREFERENCES，如果想让检查点起作用，需要选中ENABLE IMAGE AND

        TEXT CHECK 复选框。

n         查看检查点是否通过

脚本运行结束后，要想查看检查点是否通过，可以在TREE VIEW视图下，用鼠标右键单击检查点步骤，选择GO TO STEP IN EXECUTION命令，则系统自动将光标定位到执行日志中获取检查点结果的一行上。

Ø         RUN-TIME SETTINGS

选择VUSER|RUN-TIME SETTINGS 命令,可以设定VIRTUAL USER GENERATOR中和脚本相关的一些运行时参数；

n         ITERATION COUNT(重复次数)

入口:GENERAL|RUN LOGIC;

参数说明:设定每个ACTION的重复执行次数;

需要注意的是,DURATION参数是优先于ITERATION的,举例说明,假定将DURATION设为5分钟,即使在RUN-TIME中将INRATIONS参数设为1,虚拟用户也会在5分钟之内进行尽可能多的反复执行脚本,在限定了DURATION的场景中,DURATION时间是从所有用户状态变为INIT开始计算的,这样就存在一个问题,有些初始化过程很长的用户,可能还没有到达RUN状态就因DURATION时间限制而中止了,要解决这个问题,测试人员可选择INITIALIZE ALL VUSERS BEFORE RUN选项,这样DURATION时间会在所有用户都到达RUN状态后开始计时.

n         THINK TIME

THINK TIME参数设定入口:GENERAL|THINK TIME

参数说明:设定脚本回放时对思考时间的处理方式.

IGNORE THINK TIME:

选择该选项,脚本回放时将不在执行LR_THINK_TIME()函数,这样会给服务器造成更大的压力.

REPLAY THINK TIME:

选择该选项,脚本回放时执行LR_THINK_TIME()函数,

1,按录制时获取的THINK TIME值回放脚本;

2,按照录制时获取值的整数倍回放脚本;

3,限定一个最大和最小的比例,按照两者之间的随机值回放脚本;

LIMIT THINK TIME TO:

用于限定THINK TIME 的最大值,脚本回放过程中,如果发现有超过这个值的,用这个最大值替代;

n         ERROR HANDLING

入口:GENERAL|MISCELLANEOUS

参数说明:设定遇到错误时的处理方式

1,CONTINUE ON ERROR,遇到错误继续运行;

2,FAIL OPEN TRANSACTIONS ON LR_ERROR_MESSAGE,

执行到事务中调用的LR_ERROR_MESSAGE()函数时将事务的结果置为FAILED

3,GENERATE SNAJPSHOT ON ERROR对错误进行快照.

n         MULTITHREADING

设定脚本运行方式;

入口:GENERATOR|MISCELLANEOUS

1,RUN VUSER AS A PROCESS,以多进程方式运行;

2,RUN VUSER AS A THREAD,以多线程方式运行;

4．在 LoadRunner 脚本中做关联 (Correlation) Ø         自动关联---- Rules Correlation

可以自动找出需要关联的值，并且自动使用关联函数建立关联。

 

在录制过程中VuGen会根据订定的规则，实时自动找出要关联的值。

1.        启用auto-correlation

n         点选VuGen的【Tools】>【Recording Options】，开启【Recording Options】对话窗口，选取【Internet Protocol】>【Correlation】，勾选【Enable correlation during recording】，以启用自动关联。

n         假如录制的应用系统属于内建关联规则的系统，如AribaBuyer、BlueMartini、BroadVision、InterStage、mySAP、NetDynamics、Oracle、PeopleSoft、Siebel、SilverJRunner等，请勾选相对应的应用系统。

n         或者也可以针对录制的应用系统加入新的关联规则，此即为使用者自订的关联规则。

n         设定当VuGen侦测到符合关联规则的数据时，要如何处理：

u       【Issue a pop-up message and let me decide online】：跳出一个讯息对话窗口，询问您是否要建立关联。

u       【Perform. correlation in sceipt】：直接自动建立关联

2.        录制脚本
开始录制脚本，在录制过程中，当VuGen侦测到符合关联规则的数据时，会依照设定建立关联，您会在脚本中看到类似以下的脚本，此为BroadVision应用系统建立关联的例子，在脚本批注部分可以看到关联前的数据为何。

3.        执行脚本验证关联是OK的。

Ø         自动关联----Correlation Studio

当录制的应用系统不属于VuGen预设支持的应用系统时，Rule Correlation可能既无法发挥作用，这时可以利用Correlation Studio来做关联。

Correlation Studio会尝试找出录制时与执行时，服务器响应内容的差异部分，藉以找出需要关联的数据，并建立关联。

使用Correlation Studio的步骤如下：

1.         录制脚本并执行；

2.        执行完毕后，VuGen会跳出下面的【Scan Action for Correlation】窗口，询问您是否要扫描脚本并建立关联，按下【Yes】按钮。

3.        扫描完后，可以在脚本下方的【Correlation Results】中看到扫描的结果。

4.        检查一下扫瞄的结果后，选择要做关联的数据，然后按下【Correlate】按钮，一笔一笔做，或是按下【Correlate All】让VuGen一次就对所有的数据建立关联。
注意：由于Correlation Studio会找出所有有变动的数据，但是并不是所有的数据都需要做关联，所以不建议您直接用【Correlate All】。

5.        一般来说，您必须一直重复步骤1~4直到所有需要做关联的数据都找出来为止。因为有时前面的关联还没做好之前，将无法执行到后面需要做关联的部份。

Ø         手动关联

有可能有些需要做关联的动态数据，连Correlation Studio都无法侦测出来，这时您就需要自行做手动关联了。

5.试运行脚本脚本录制完毕后,按F5键或单击菜单上的RUN按钮,可以运行脚本,在VIRTUAL USER GENERATOR中运行脚本的作用,主要是查看录制的脚本能否正常通过,如果有问题,系统会给出提示信息,并定位到出错的行上,便于用户查找到错误,修改完善测试脚本,运行结束后；系统会给出相应的运行结果.

6.保存脚本 LOADRUNNER的测试脚本在资源管理器中是以目录的形式存储的,目录名称就是LOADRUNNER识别的脚本名称.

四、MERCURY LOADRUNNER CONTROLLER创建场景进行压力负载测试时,测试人员的工作就是了解被测应用的性能需求,从应用程序中找出一个或多个性能测试点,然后针对这些性能点分别进行测试,获取相关的性能指标结果,分析被测应用,追溯性能问题产生的根源.要使用LOADRUNENR实现这一过程,就需要针对这些性能点建立一个个的场景,因此,LOADRUNNER的每个场景都定义了一个在性能测试活动中发生的事件,它能控制虚拟用户的数量,测试脚本和运行脚本的LOAD GENERATOR.对于有经验的测试人员来说，定义场景是在计划阶段进行的，它优先于脚本的录制过程，并指导脚本的录制。只不过计划阶段的场景只能限于纸面上，要想让LOADRUNNER这个测试工具实现自动的负载测试，需要在CONTROLLER中建立实实在在的场景。

对于有经验的测试人员来说,定义场景是在计划阶段进行的.它优先于脚本的录制过程，并指导脚本的录制。只不过计划阶段的场景只限于纸面上，要想让LOADRUNNER这个测试工具实现自动的负载测试，需要在CONTROLLER中建立实实在在的场景。

1．选择场景类型每次在CONTROLLER中创建一个场景的时候，系统会首先让用户选择场景的类型。LOADRUNNER为用户提供了面向目标和手工设置的两种场景策略，具体选择哪一种要根据具体的项目需求来定。

Ø         MANUAL SCENARIO这种方式是完全手动设置，测试人员需要手工设定虚拟用户数，SCHEDULE和LOADGENERATOR等

Ø         MANUAL SCENARI WITH PERCENTAGE MODE 这种方式与MAMUAL SCENARIO方式比较相似，只是在分配用户数的方式有所不同

1，后者需要设定TOTAL NUMBER OF VUSERS，即所有虚拟用户数；

2，后者需要为每个脚本分配用户数比例，由系统按照比例自动分配用户数；

3，后者脚本选择LOADGENERATOR时，除了可以选择单个的LOAD GENERATOR外，还可以设置为ALL LOAD GENERATOR，即使用所有的LOADGENERATOR。

由于这种方式没有用户组的概念，因此在设置SCHEDULE时，不能按组设置，只能按整个场景设置，

Ø          GOAL-ORIENTED SCENARIO

这种方式是基于目标自动创建场景的方式，测试人员只要输入性能测试所要达到的目标，LOADRUNNER就会自动根据目标安排场景的运行；

采用GOAL-ORIENTED SCENARIO方式创建场景时，需要单击EDIT SCENARIO GOAL按钮定义场景目标，CONTROLLER在执行的时候会根据场景目标的要求，自动加载用户，控制场景的运行；

n         VIRTUAL USERS  

以虚拟用户数作为目标，当一个应用对用户数要求比较高时，可以使用这种方式来测试一个应用程序能够允许多少个用户同时运行。基于用户数目标的原理和设定方法比较简单，他和MANUAL SCENARIO WITH PERCENTAGE MODE 方式基本相似，只需要定义要求达到的用户数就可以了。从某种意义上讲，它还不能体现面向目标类型的优势。

n         HITS PER SECOND，以每秒点击数作为目标，

n         TRANSACTIONS PER SECOND，以每秒事务数作为目标，

n         PAGES PER MINUTE，以每分钟页数作为目标，

以上三种类型都需要用户指定虚拟用户数的范围，CONTROLLER在运行场景的时候，首先加载最小的用户数，如果使用最小的用户数不能达到目标，系统会自动逐渐增加用户直到能够达到设定的目标为止。当加载的用户数达到最大值仍然不能满足要求时，就需要重新设置场景，增加最大用户数。可以通过LOAD BEHAVIOR选项设定三种不同的用户加载策略，如果没有达到目标，LOADRUNNER会重新运行场景，一次加载最大的用户数，尝试是否能够达到目标，如果出现如下情况之一，场景的运行结果都会置于FAILED状态，

CONTROLLER两次加载了最大的用户数都没有达到目标；

在运行过程中所有的用户都失败了；

LOAD GENERATOR数目不能满足要求；

CONTROLLER在增加用户的过程中，性能指标没有增加；

CONTROLLER在加载第一批用户后，没有捕获到指标的值；

n         TRANSATIONS RESPONSE TIME，以事务响应作为目标，

主要用于衡量要达到预期的事务响应时间，系统所容纳的最多用户数，如果系统已经加载了最大的用户数，响应时间仍然低于设定的值，说明系统还有能力容纳更多的用户，如果使用一部分用户就达到了设定的响应时间，说明系统是无法容纳设定的最大数量的用户的，必须通过完善应用程序来达到目的；

2．多机联合产生负载       LOADRUNNER对应用程序施压时，采用的方法就是让一台机器模拟很多用户，同时向被测用户发送请求或进行操作。这样，如果一台测试机器模拟的虚拟用户数过多，他本身性能的下降会直接影响测试效果。为了避免这种情况，LOADRUNNER允许使用多台机器运行场景来均衡测试机器的负荷。只要一台机器安装了LOAD GENERATOR并启动了LOADRUNNER AGENT PROCESS进程，就可以被CONTROLLER统一调度来运行场景，CONTROLLER负载收集统一的测试信息和执行结果。

Ø          安装LOAD GENERATOR，如果一台测试机仅用来被CONTROLLER调用执行场景，只需安装LOAD GENERATOR就可以了。方法是在LOADRUNNER安装首页选择LOAD GENERATOR选项。需要注意的是，LOAD GENERATOR的服务启动后，屏幕右下角的任务栏上会显示一个代理（AGENT）的图标；

Ø         在CONTROLLER中创建LOAD GENERATOR

CONTROLLER进行多机联合产生负载之前，首先要加载准备使用的LOAD GENERATOR，单击场景设定对话框中的GENERATORS按钮，系统会弹出LOAD GENERATORS对话框；在LOAD GENERATOR

对话框中可以查看到所有已经加载的LOAD GENERATOR信息。

n         NAME：LOAD GENERATOR所在的机器名称。如果是LOCALHOST，表明这个GENERATOR是在本机上；

n         STATUS：标识了GENERATOR目前的状态，

n         PLATFORM：显示了系统的平台名称；

n         单击ADD可以添加新的LOAD GENERATOR；添加LOAD GENERATOR后，一般要测试CONTROLLER能否正确连接到这个GENERATOR，单击CONNECT按钮，LOADRUNNER的CONTROLLER就会尝试去连接选中的LOAD GENERATOR，如果连接成功就在STATUS字段中显示READY，如果失败就会显示FAILED。

Ø         在场景中用不同的LOAD GENERATOR联合产生负载

创建好LOADGENERATOR以后，在CONTROLLER的LOAD GROUPS列表中就可以选择使用了，

使用多个LOAD GENERATOR运行场景的时候，可以让不同的虚拟用户组在不同的机器上运行，分解了CONTROLER本身的压力，更能体现系统真实的运行环境；

3．设定集合点策略     LOADRUNNER在运行场景的时候，允许测试人员根据项目需要自己设定集合点的并发策略，要设定一个集合点以何种方法运行，在创建或打开脚本中包含集合点的场景时，选择SCENARIOI|RENDEZVOUS命令，可以查看场景中所有脚本中的集合点名称，所属脚本，当前状态和相关的虚拟用户列表信息等，根据系统需求，还可以针对集合点的执行进行设定。

Ø          单击DISABLE/ENABLE RENDEZVOUS按钮可以选定集合点是否启用；

Ø          单击DISABLE/ENABLE VUSERS按钮可以设定一个用户是否参与到集合点中；

Ø          单击POLICY按钮可以设定集合点执行策略。

n         在POLICY对话框中的TIMEOUT BETWEEN VUSERS文本框中设定了一个超时时间，当第一个用户到达集合点时，系统开始计时。如果在这个设定的时间内没有达到要求的集合点用户数，系统就不在等待，释放用户让场景继续执行；

4．启用IP欺骗     LOADRUNNER进行压力负载测试的时候，是让一台机器模拟成百上千的用户对服务器施压，这样就产生了一个问题，那就是所有用户向服务器发起请求的时候，使用的都是同一个IP地址，即LOAD GENERATOR所在机器的固定IP地址，这是和实际运行环境不符的，而且有些应用系统在设计的时候会根据IP来分配资源，有些还限制同一个IP的多次登陆过程。LOADRUNNER为了解决这个问题，使用了一种称为“IP欺骗（IP SPOOFER）”的技术。也就是让一个LOAD GENERATOR上的虚拟用户模拟从不同的IP来向服务器发起请求，以达到以假乱真的目的。

Ø          配置IP SPOOFER

 LOADRNNER配置动态IP的工具是程序组中的一个小工具-IP WIZARD，它能够指导用户按步骤完成配置过程，这里有三个单选按钮；

第一个单选按钮CREATE NEW SETTING，用于创建一个新的设置，首次运行时选用；

第二个单选按钮LOAD PREVIOUS SETTING FROM可以调用以前保存的设置；

第三个单选按钮RESTORE ORIGINALSET不是用来创建动态IP，而是将设置恢复为原始状态，这个选项主要用于使用后释放IP，如果使用完毕后不释放IP的话，那么这些IP会被一直占用，别人就无法使用了。

Ø         输入WEB SERVER的IP地址，这里主要用来检测新的IP地址加到主机中后，SERVER的路由表是否需要更新，如果SERVER和CLIENT使用的是相同的子网掩码，IP CLASS类型和网络，是无需更新的；

Ø         在添加新的动态IP的时候，需要注意如下几个选项的含义：

n         PRIVATE ADDRESS SPACES：选择测试环境的IP地址类型，关于IP地址类型的定义

n         FROM IP：要使用IP段的第一个值；

n         NUMBER TO：要使用的IP地址的数目。

n         SUBMASK：子网掩码，一般采用默认设置就可以了；

如果选中VERIFY THAT NEW IP ADDRESS ARE NOT ALREADY IN USE复选框，系统会在所选范围内检测每个IP地址，为了避免冲突，LOADRUNNER只添加那些没有被其他用户使用的IP地址。

如果已经预先知道选择范围内的某些地址可能被占用，那么在NUMBER TO文本框中输入的IP地址的个数就要有相应的增加。

Ø         起用IP欺骗

在CONTROLLER窗口中，选择SCENARIO|ENABLE IP SPOOFER命令，就可以起用IP欺骗了，在IP欺骗启用后，在CONTROLLER状态栏中会显示相应的状态标识；

Ø         在OPTIONS中设置IP地址的分配方式；

创建虚拟IP地址之后，还要选择TOOLS|OPTIONS命令，在弹出的对话框中单击GENERAL标签以设定IP地址的分配方式；

n         IP ADDRESS ALLOCATION PER PROCESS：给每个进程分配不同的IP地址；

n         IP ADDRESS ALLOCATION PER THREAD： 给每个线程分配不同的IP地址；

一般来说，如果在RUN-TIME SETTING中设置的是以多线程的方式运行，则这里就给每个线程分配不同的IP地址。如果在RUN-TIME SETTING中设置的是以多进程的方式运行，则这里给每个进程分配不同的IP地址；

注意：只有在CONTROLLER中选择TOOL|EXPERT MODE 命令，才能在OPTIONS对话框中包含设定IP分配的选项；

5．使用测试管理工具进行统一管理     LOADRUNNER和MERCURY QUALIY CENTER的完美结合，给用户组织和管理LOADRUNNER的测试脚本，场景和测试数据带来了极大的便利。QUALITY CENTER是MERCURY 提出的针对质量保证的解决方案。只要将LOADRUNNER连接到基于WEB的QUALITY CENTER，则场景的存储执行和测试结果的收集就会随时随地被MERCURY QUALITY CENTER的测试项目进行有效的管理；

Ø          连接到QUALITY CENTER

要想让LOADRUNNER使用一个QUALITY CENTER 对测试内容进行管理，首先必须通过URL连接到QUALITY CENTER，这个QUALITY CENTER 既可以是安装在本地的局域网上，也可以是通过广域网访问的测试管理平台；

在CONTROLLER模块中，选择TOOLS|QUALITY CENTER CONNECTION 命令，弹出QUALITY CENTER

CONNECTION 对话框，在SERVER文本框中输入安装了QUALITY CENTER的WEB服务器的URL地址，单击CONNECT按钮，系统会试图建立对QUALITY CENTER服务器的连接，如果连接建立成功，则会在PROJECT CONNECTION 一栏显示QUALITY CENTER的项目；

在PROJECT CONNECTION 一栏输入相关的内容，即选定要连接的测试管理项目，单击CONNECT按钮，系统开始对相应的项目建立连接。一旦建立成功，则QUALITY CENTER的项目信息就变为只读状态；

Ø         断开服务器或项目

在连接状态中，可以随时单击DISCONNECT 按钮断开QUALITY CENTER服务器或项目的连接；

Ø         打开/保存测试项目场景

如果LOADRUNNER正在连接到一个测试管理工具上，那么在保存和打开场景的时候，系统弹出的对话框会有所不同，如果仍然希望在文件系统中打开/保存场景，可以单击对话框中的FILE SYSTEM按钮进行切换；关于测试管理工具如何管理和调用LOADRUNNER的场景，请参考TD。

6．控制场景的运行在CONTROLLER中单击START SCENARIO按钮开始执行场景以后，LOADRUNNER首先检查场景的配置信息，并激活被测应用，然后将虚拟用户分配到相应的LOAD GENERATOR上。当虚拟用户准备好以后就开始对被测应用施压，在施压的同时LOADRUNNER会完成如下的操作；

1)        记录在脚本中定义的每个事务的执行时间；

2)        执行脚本中定义的集合点的功能；

3)        收集每个虚拟用户发出的告警，错误和提示信息；

在场景执行过程中，学员可以查看虚拟用户发出的各种信息，可以随时停止一个用户或多个用户组的执行，可以让LOADRUNNER命令某些用户和用户组在场景执行结束前进行重复操作等。

Ø         初始化用户组

单击START SCENARIO 按钮执行场景时，虚拟用户并没有立刻执行脚本，而是首先执行一个初始化过程，初始化完毕的用户状态会变为READY，只有状态为READY 的用户才能真正开始执行脚本。由于各种条件的限制，场景中用户的初始化过程是无法达到完全同步的，这就造就了用户无法同时运行测试脚本。为了让用户能够同时对被测应用施压，LOADRUNNER提供了初始化用户组的策略，让所有用户在执行脚本之前全部变为READY 状态。

初始化用户组的方法是在开始运行场景之前，先在RUN选项卡中选中要初始化的用户组，然后单击工具栏的INITIALIZE THE SELECTED VUSERS按钮，或者单击鼠标右键，在弹出的菜单中选择INITIALIZE GROUPS命令，如果初始化成功，用户状态变为READY，如果失败，用户的状态就会变为ERROR。

Ø         停止场景的运行

     一个场景会在以下三种情况停止运行：

1)        所有用户都执行完脚本；

2)        测试人员手动停止了场景的运行；

3)        执行超时；

LOADRUNNER可以根据用户的设定，采用不同的停止方式；

1)        要手动停止整个场景的运行，只需在场景运行过程中单击RUN标签中的STOP按钮即可。

2)        如果希望选定的用户组停止执行，可以单击工具栏的STOP VUSERS按钮；

3)        如果OPIONS的RUN-TIME SETTING中设定了WAIT FOR CURRENT INTERATION TO END BEFORE STOPPING 或者WAIT FOR CURRENT ACTION TO END BEFORE STOPPING ，那么可以单击GRADUAL STOP按钮逐渐停止场景的运行；

Ø         对正在运行的场景增加用户数

在场景运行的时候，还可以在RUN/STOP VUSER对话框中增加用户，对话框的内容会根据所选择的模式的不同而有所不同。如果使用的是VUSER GROUP MODE，则在RUN/STOP VUSERS对话框的“#” 一栏中为每个用户组输入新的用户总数后，单击“RUN”按纽，系统会自动初始化新增加的用户数并开始运行；如果使用的是PERCENTAGE MODE，那么只要输入用户总数，系统会根据比例自动分配新的用户到不同的组中。

五、MERCURY LOADRUNNER CONTROLLER监视场景     影响事务响应时间的一个主要因素就是系统资源和应用服务器的使用情况。通过监视场景执行时的系统和服务器资源，基本能够确定系统的瓶颈在哪里。下面简单介绍通过添加性能计时器来监视各个服务器的运行情况，确定系统的瓶颈；

1． 在线监视场景    LOADRUNNER允许测试人员在场景的执行过程中在线查看产生的性能数据，除了监视本机的性能指标外，CONTROLLER还允许用户在线监视服务器的性能；

   使用CONTROLLER监视场景之前，需要定义和配置LOADRUNNER的监视组件，根据监视指标的不同，相应的配置过程和参数也完全不同，要想完成监视组件的配置过程，测试人员除了掌握LOADRUNNER的使用以外，更重要的是要对被监视的服务器中的应用相当熟悉。

  一般来说，在监视一个服务器之前，要经过如下两个步骤：

1)        在服务器端配置被监视服务器的监视环境；（有些指标不需对服务器进行特殊配置）

关于如何配置服务器端监视环境，由于不同类型的指标配置方法也不尽相同，需要测试人员熟悉被测应用的系统架构，并查阅相关的LOADRUNNER文档；

2)        在LOADRUNNER的CONTROLLER中配置要监视的MONITOR；

在LOADRUNNER CONTROLLER中，对监视指标进行了分类，具体的分类方式及每个类别包括的性能指标在RUN 视图的AVALIABLE GRAPHS列表中都有详细的说明。 

Ø         添加计数器

很多服务器（DATABASE SERVER，WEB SERVER等）和系统资源的性能指标数据，是通过手动在CONTROLLER中添加计数器来实现的；下面来介绍如何在CONTROLLER中添加性能计数器。注意的是，使用不同的操作系统，计数器会不完全相同；

在AVAILABLE列表中，单击要监视的图表，选择MONITOR|ADD MEASUREMENTS；或者在AVAILABLE GRAPH中先将准备监视的指标拖至右侧图表栏中，然后用鼠标右键单击该图表，在弹出的快捷菜单选择ADD MEASUREMENTS，系统会自动弹出相应的监视服务器对话框；单击上部的ADD按钮，在MONITORED SERVER MACHINES中添加要监视的服务器名称（或IP地址）和相应的系统平台；单击下部的ADD按钮在RESOURCE MEASUREMENTS ON列表中添加相应的计数器，这里可以选择一个或多个性能指标。如果添加成功的话，场景运行的时候，就可以在线监视所选择的指标数据了

注意：必须以被监视机器的管理员身份登陆到CONTROLLER所在机器，才能添加被监视机器的性能计数器；

Ø         常见的计数器

1)        MEMORY相关，内存问题主要检查应用程序是否存在内存泄露，如果发生了泄露，PROCESS\PRIVATE BYTES计数器和PROCESS\WORKING SET计数器的值往往会升高,同时AVALIABLE BYTES的值会降低.内存泄露应该通过一个长时间的测试来检查,主要测试当所有内存都耗尽时应用程序的反应情况;

2)        PROCESSOR相关,判断应用程序是否存在处理器的瓶颈

n         如果PROCESSOR QUEUE LENGTH显示的队列长度保持不变(>=2),且处理器的利用率%PROCESSOR TIME超过90%,那么很可能存在处理器瓶颈;

n         如果发现PROCESSOR QUEUE LENGTH显示的队列长度超过2,而处理器利用率却一直很低,那么或许更应该去解决处理器的阻塞问题,处理器一般不是瓶颈;

n         如果系统由于应用程序代码效率低下或者系统结构设计有缺陷而导致大量的上下文切换(CONTEXT SWITCHES/SEC,显示的上下文切换次数)比较大,那么就会造成大量的系统资源;

n         如果系统吞吐量降低并且CPU的使用率很高,并且此现象发生时切换水平在1500以上,那么意味着上下文切换的次数过高;

n         还可以比较CONTEXT SWITCHES/SEC和%PRIVILEGED TIME来判断上下文切换是否过量;如果后者的值超过40%,且上下文切换的速率也很高,那么应该检查为什么会产生这么高的上下文切换;

3)        网络吞吐量及带宽

BYTES TOTAL/SEC: 判断网络连接速度是否是瓶颈,可以用该计数器的值和目前网络的带宽比较,相除结果应该小于50%;

4)        磁盘相关

     判断磁盘瓶颈的方法是通过以下的公式来计算:

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

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

5)        WEB SERVER相关

 

 

6)        数据库服务器相关

 

2．定制图表显示方式 Ø          定制在线监视图表个数；

场景运行时,LOADRUNNER让用户默认在线监视4个图表,测试人员可以根据需要自己定制图表的个数:

鼠标右键单击一个图像,在弹出的快捷菜单中选择VIEW GRAPHS(或选择VIEW|VIEW GRAPHS命令),然后选择或设定显示图象的个数就可以了;

Ø          设定监视器选项；

     选择TOOLS|OPTION命令,在MONITORS选项卡中可以统一设定监视器的一些参数选项,

1)        TRANSACTION  DATA

用于监视事务图表的数据行为,这些参数不能在场景运行过程中更改,参数修改后需要重新连接虚拟用户的LOADGENERATOR才能生效;

n         ENABLE TRASACTION MONITOR:如果选择该选项,场景启动后就自动开始监视事务,默认情况下,该选项是选中的;

n         FREQUENCY:设定MONITOR抽样数据产生事务,获取数据点和生成网络资源在线图表的频率.默认为5秒,如果是小的场景建议使用1秒;如果大一些的场景,建议3-5秒;这个参数越低,采样间隔越小,监视图表越精确,网络工作量也就越大;

2)        SERVER RESOURCE MONITORS

定义了服务器资源监视器的行为,修改该选项对已经被激活的图表不起作用,只对随后被激活的图表起作用;

DATA SAMPLING RATE:定义了服务器两次采样数据的时间间隔,默认为3秒,这个参数对所有图表都起作用,如果要对单个图表起作用,需要在单个图表的配置属性中定义,

     每个图表都有一个最小的采样频率,如果这里设定的值低于图表的最小采样频率,图表仍然使用最小的采样频率;

3)        ERROR HANDLING

     定义了监视过程中的错误处理方式；

n         SEND ERROR TO THE OUTPUT WINDOW：遇到错误时将出错信息输出到OUTPUT窗口；

n         POP-UP AN ERROR MASSAGE BOX：遇到错误时弹出错误信息窗口；

4)        DEBUG

设定DEBUG场景的方式；

DISPLAY DEBUG MESSAGE：选中该复选框，系统会向输出日志中发送DEBUG相关信息，定义DEBUG的等级；

Ø          配置图表和计数器属性；

n         设定图表属性

如果想对一个图表单独配置显示属性，只需选择该图表，选择MONITOR|ONLINE GRAPHS|CONFIGURE命令，或者在右键单击图表后选择CONFIGURE命令，系统都会打开GRAPH CONFIGURE对话框。在该对话框中可以设定图表的数据刷新频率，X轴（时间轴）和Y轴的显示方式，显示比例等；

n         设定计数器属性

要设定图表中单个计数器的属性，可以用鼠标右键单击图表列表中的相应计数器，在弹出的菜单中选择CONFIGURE命令，可以设定计数器在图表中的显示颜色，显示比例和是否隐藏等；

Ø         合并图表；

     LOADRUNNER为了便于测试人员比较两个图表数据之间的关系，提供了图表合并的功能，也就是可以将同一个场景中的两个图表中的计数器合并到一个图表中，合并以后的图表共用一个X轴。

    要合并两个图象，只需右键单击一个图表，在弹出的快捷菜单中选择OVERLAY GRAPHS命令，然后在系统提示的对话框中选择另一个图表，并为新图表命名，需要注意的是只有X轴相同的图表才能合并；

3．其他与监视图表相关的功能 Ø         穿越防火墙监视图表；

为了安全起见，运行MONITOR和VUSER的机器安装了防火墙，这样处于防火墙之外的CONTROLLER在控制虚拟用户执行和监视场景的时候就会碰到一些麻烦；

LOADRUNER通过在防火墙上使用基于HTTPS或者使用标准SSL端口（443）的安全的TCP/IP的协议来解决这个问题。使用LOAD GENERATOR机器或MONITOR机器上的代理充当通信过程的媒介，与MI LISTENER通信。 MI

LISTENER是一个需要单独安装的LOADRUNNER组件，它服务于CONTROLLER和LOADRUNNER代理之间，

如果未安装MI LISTENER组件，LOADRUNNER也可以穿越防火墙实现监控MONITOR和执行VUSERS，这时需要在

LOAD GENERATOR 端和CONTROLLER端的防火墙上均打开54345端口；

Ø         远程监视场景；

LOADRUNNER提供了一个组件，用于同时通过多个机器上的WEB页面远程监视场景，每个监视还可以根据需要定制不同监视图表；

要完成远程监控，需要一个远程性能监视服务器，（REMOTE PERFORMANCE MONITOR SERVER），它是一个包括很多ASP页面和性能图表过滤器的网站，和CONTROLLER交互数据，并且决定能够在线查看场景的用户数。远程性能监视服务器上必须安装LOADRUNNER的REMOTE PERFORMANCE MONITOR SERVER组件，该组件有如下系统需求：

n          WEB SERVER: IIS5.0

n          操作系统:WINDOWS 2000SERVER或WINDOWS 2000ADVANCED SERVER

n          客户端浏览器:IE5.0或NETSCAPE6.2以上;

六、使用ANALYSIS分析测试结果      要查找系统瓶颈，就必需分析LOADRUNNER获取的性能指标数据，在LOADRUNNER场景运行的同时获取了大量的数据，可以根据以下几种方式分析这些数据：

1)        查看VUSER LOG文件,这些文件包括了场景运行过程中每个用户的跟踪数据,VUSER LOG文件一般放在脚本目录中;

2)        在CONTROLLER的OUTPUT窗口查看场景的执行过程信息;

3)        使用ANALYSIS模块分析执行结果图表;

4)        使用SPREADSHEET直接查看生成图表的原始数据---GRAPH  DATA或者RAW DATA;

5)        让LOADRUNNER自动生成HTML或WORD格式的测试报告,通过报告分析;

LOADRUNNER的ANALYSIS模块是分析系统的性能指标的一个主要工具,它能够直接打开场景的执行结果文件,将场景数据信息生成相关的图表进行显示.ANALYSIS集成了强大的数据统计分析功能,允许测试员对图表进行比较和合并等多种操作,分析后的图表能够自动生成需要的测试报告文档;ANALYSIS作为LOADRUNNER的一个主要模块,是帮助测试人员分析系统性能瓶颈的得力助手;

1、 使用ANALYSIS分析测试结果场景运行完毕，在结果目录下会自动保存一个扩展名为LRR的结果文件，ANALYSIS能够打开这个结果文件，加载时自动处理LRR文件内的结果信息，并自动生成相应的结果图表；

每次对结果信息进行处理的时候，ANALYSIS是在一个开启的会话内进行工作的。每个会话至少包括一套场景结果（即一个LRR文件）。在ANALYSIS中对结果信息进行另存的时候，除了重新保存数据自身信息外，还保存了结果数据在ANALYSIS中实现的显示方式和层次关系，以及哪些图表被激活等信息，这时保存的文件扩展名为LRA，

Ø         打开分析图表；

除了系统提示的默认的图表外，测试人员还可以查看其他包含数据的图表，方法是：在左侧的图表列表中双击NEW GRAPH，弹出OPEN A NEW GRAPH对话框，对话框中所有名称为篮色的图表均为包含数据的图表；

选中后单击OPEN A NEW GRAPH按钮即可以添加到主窗口中；

Ø         使用ANALYSIS分析结果图表；

     加载场景运行结果文件（.LRR）后,ANALYSIS就可以根据需要对相关的性能指标进行分析了.首次加载结果文件后可以看到,在ANALYSIS中包含了很多图表,也同时说明了LOADRUNNER在场景运行过程中获取了很多和性能相关的数据;针对每一个被测应用来说,到底哪个性能指标是影响性能的关键了.了解常用的性能指标,熟悉使用ANALYSIS分析工具分析测试结果是确定系统瓶颈的关键.再次强调,不同的应用程序,影响其性能的因素也不同,要分析被测软件的性能因素,首先要熟悉被测软件的技术架构;

     LOADRUNNER除了将获取的原始数据形成直观的图表外,还对数据进行了一些统计,,例如在多数分析图表下方的图例列表中,给出了最大值,最小值,平均值,中间值和STD等一些统计字段,便于用户分析;

     STD是一个统计学概念,称为标准偏差值,是用来衡量数据的偏离程度的.当平均值不多时,可以从STD指标看出统计图表列数据到底是分散还是集中的.STD越小表示图表的列数据越集中,拿AVERAGE RESPONSE TIME来说,也就表示每个虚拟用户单一的响应时间值大致是差不多的,即被测系统的反应很稳定,没有大起大落;

1)        TRANSACTION  PERFORMANCE SUMMARY

可以基本确认哪个事务的响应时间比较长,一般来说,响应时间长的事务是分析的重点;

2)        AVERAGE  TRANSACTION RESPONSE TIME

     可以详细查看每个事务在场景运行中的响应时间,

3)        WEB PAGE BREAKDOWN

用于分解页面,查看页面中哪些组件导致事务的响应时间比较长,

n         DNS RESOLUTION时间     DNS服务器解析IP地址的时间,这个度量时间可以确定DNS服务器或者DNS服务器的配置是否有问题,如果DNS运行正常,这个值一般比较小;

n         CONNECTION时间    浏览器和WEB SERVER建立初始化连接的时间,这个度量可以判断网络情况,也可以判断WEBSERVER是否响应这个请求;

n         SSL HANDSHAKING 时间     建立SSL连接的时间,使用SSL协议页面比较少,一般应用在HTTPS通信;

n         FTP AUTHENTICATION时间     FTP服务器在处理客户端的命令之前,首先要对客户端进行鉴权,这个度量就是FTP服务器对客户端进行鉴权的时间;

n         FIRST BUFFER时间    指连接建立成功后,从WEB SERVER发出的第一个数据包经过网络传输到客户端,浏览器成功接受到第一个字节的时间.这个度量既包括WEB SERVER的延迟时间,也包括了网络的反应时间.

n         RECEIVE时间   从浏览器收到第一个字节起,直到成功收到最后一个字节,所经历的时间.这个度量和组件大小结合,可以判断网络的质量;

n         CLIENT时间   指请求在客户端的延迟时间,这个延迟可能是浏览器的THINK TIME等引起的

n         ERROR时间    指从发送HTTP请求到HTTP错误信息返回的时间;

4)        TIME TO FIRST BUFFER BREAKDOWN

可以将页面或组件的时间分解为服务器时间和网络时间,帮助测试人员判断问题缘由到底是服务器还是网络存在瓶颈;

5)        THROUTPUT

     可分析整个压力测试过程中WEB SERVER的吞吐量,即虚拟用户在测试过程中各时刻从服务器上接收到的数据量.

6)        DOWNLOAD COMPONENT SIZE

页面元素的大小分解和比较

7)        WINDOWS  RESOURCE

系统资源图表,可以监视服务器端的系统资源使用情况,从而判断服务器的CPU,内存等是否是导致性能降低的原因;

Ø         关于分析图表的几个选项

n         自动整理合并结果

在使用ANALYSIS分析场景结果之前，首先要明确结果文件中收集了哪些信息，默认情况下，各个虚拟用户的执行结果数据都是存放在各个虚拟用户所在的机器上的，场景执行结束后，才被系统自动整理合并后放置到结果目录下，LOADRUNNER是否执行这个整理合并操作是受CONTROLLER中的AUTO COLLATE RESULTS选项控制的。该选项设定方法是在RESULTS下选择AUTO COLLATE RESULTS复选框；

n         设定收集结果信息方式 

对于结果文件大于100MB的大型场景，ANALYSIS加载结果数据时会耗费很长时间，测试人员在等待全部数据加载的同时可以首先查看结果的概要数据，这样，在测试人员浏览概要信息的时候系统会陆续加载其他详细信息数据；

测试人员可以根据需要设定是否产生概要数据，以及以何种方式显示结果信息，设定入口：菜单 TOOLS|OPTION|RESULT COLLECTION ，

在DATA SOURCE一栏有三个选项供测试人员选择；

只生成概要数据；只生成全部详细数据；在生成全部详细数据的同时显示概要数据；

n         设定数据聚集粒度

n         使用系统自动聚合的公式自动聚合数据 ;

n         使用系统自动聚合公式只对WEB数据进行聚合;

n         单击AGGREGATION CONFIGURATION自己定义聚合方式 ;

2、使用ANALYSIS技巧 Ø         查看图表技巧

1)        将鼠标放置到图表上需要放大部分的起始位置，然后按住鼠标左键拖动，松开鼠标后鼠标圈住的矩形部分的图表放大显示，便于用户查看图表细节；

2)        在图例列表中选择一个MEASUREMENT，单击鼠标右键，在系统弹出的菜单中选择CONFIGURE MEASUREMENT命令，之后就可以设定显示颜色和比例，通过设定比例，可以让不同数量级的数据都在图表的主要区域显示，使每个图表的趋势都很明显；

3)        在图例列表中单击鼠标右键，选择CONFIGURE COLUMN，可以设定在图例列表包含哪些列，以及表格中的图例如何排序等；

4)        在图表中单击鼠标右键，选择SET FILTER/GROUP BY，可以筛选图表中要显示数据和数据的分组方式；

Ø         分析图表技巧

1)        向下钻取图表

选中一个图表中的某条折线,单击鼠标右键后选择DRILL DOWN,可以对选定的MEASUERMENT J进行向下钻取,钻取的方向可以根据需要进行选择,要取消钻取,需要使用SET FILTER/GROUP BY功能;

2)        查看原始数据

在图表下面的RAW DATA或GRAPH DATA中,可以查看图表的原始数据;

3)        自动关联图表

在一个图表上单击鼠标右键,在弹出的菜单中选择AUTO COLLATE命令,依据提示进行设定后,系统会自动搜寻和该图表趋势有一定规律的图表,合并到该图表上,该功能便于测试人员分析指标间的联系,

4)        合并图表

为了便于分析指标间的相互关系,在ANALYSIS中还可以手动将两个图表合并为一个图表.两个图表合并的条件是具有相同的X轴,合并图表的方法是:在ANALYSIS中用鼠标右键单击想要合并图表重中的一个,在弹出的菜单中选择MERGE GRAPH,根据系统提示选择被合并的图表和合并方式,系统会自动生成新的合并后图表.下面是ANALYSIS图表的3种合并方式

n         OVERLAY

两个图表合并和共用一个X轴，左边的Y轴上标识当前图表的刻度值，右边的Y轴标识被合并图表的刻度值。当有多个图表被合并时，仍显示一个Y轴刻度，这时可以通过设定图表的显示比例让所有图表都显示在主区域；

n         TILE

         两个图表合并后共用一个X轴，Y轴会被分为两个部分，这样合并的两个图表，看起来相对独立一些，其中一个显示在另一个的上部；

n         CORRELATE

         在合并图表后的图表中，其中一个图表的Y轴作为合并后的Y轴，而另一个图表的Y轴作为合并后图表的X轴，这样合并的图表更能看出两个图表变化趋势之间的关系；

Ø         使用QUALITY CENTER管理分析结果

要分析QUALITY CENTER 中的测试结果,首先要做的就是建立到QUALITY CENTER WEB服务器和相关项目的连接;

1)        连接到QUALITY CENTER

在ANALYSIS模块主菜单中选择TOOLS|QUALITY CENTER CONNECTION，弹出QUALITY CENTER CONNECTION对话框，在这里建立连接和取消连接的方法；

2)        使用QUALITY CENTER管理分析结果

     在连接的建立状态，测试人员可以选择是打开文件系统文件，还是打开保存在QUALITY  CENTER的项目中的场景执行结果文件，还可以在QUALITY CENTER中创建会话，保存结果分析文件等。

Ø         引入外部数据

监视场景的时候,可以通过添加计数器的方式监视服务器的系统资源,使用ANALYSIS打开场景的结果文件后,就可以对这些系统资源的数据图表进行分析.

     但有时受客观条件的限制，测试人员无法在LR场景中监视服务器系统资源，这时可以采用一个办法，就是让服务器自己监视自己的资源，并生成相应的CSV文件，当使用ANALYSIS分析结果的时候，把这些单独的CSV文件作为外部数据导入到ANALYSIS中；

     LOADRUNNER提供了ANALYSIS IMPORT DATA工具允许测试人员把一些非自身生成的数据信息引入和集成到ANALYSIS的SESSION中，引入之后，就可以使用ANALYSIS的工具对它们进行查看和分析了。

     工具入口：菜单TOOLS|EXTERNAL MONITORS|IMPORT DATA

     单击ADD FILE 按钮，输入保存的外部数据源文件后，需要在FILE FORMAT中正确选择数据源的格式，否则可能导致引入过程失败

1 监视连接前的准备工作
1)  在被监控WinXP主机上修改访问模式，办法是：安全策略在作怪（管理工具 -> 本地安全策略 -> 安全选项 -> "网络访问：本地帐户的共享和安全模式"）。默认情况下，XP的访问方式是"仅来宾"的方式，那么你访问它，当然就固定为Guest来访问，而guest账户没有监控的权限，所以要把访问方式改为“经典”模式，这样就可以以administrator的身份登陆了。
注意：一定需要设置密码，否则在MonitorConfiguration中添加 Measurements仍然会提示拒绝登录。
2) 保证被监视的winXP系统开启以下三个服务Remote Procedure Call(RPC) 和Remote Registry Service 、Remote Registry。其中Remote Procedure Call (RPC) Locator的登陆选项中要输入当前主机帐户和密码，然后重启该服务，其他服务设置不变。
注意：网上有些写着只要开启两个服务Remote Procedure Call(RPC) 和Remote Registry Service就可以，不确认其监视的Windows版本，但是Win XP必须开启Remote Registry这个服务。
3) 确认安装Controller的机器可以连接到被监视的WinXP机器。如果监控失败，并且 LoadRunner 找不到指定的服务器，请确认指定的服务器是否可用。在 Controller 或优化控制台计算机命令行中键入 ping <server_name>（或ip），执行 “ping” 操作。
4) 验证可以正常连接之后，如果有其他问题，可以参见下表解决：

问题1.无法监控其他域中的 Windows 计算机，或者“访问被拒绝”。
解决：要获得对远程计算机的管理权限，请在命令提示符下执行以下命令：%net use \\<计算机名>/用户:[<域>\<远程计算机名>] 提示输入密码时，输入远程计算机的密码。

问题2：无法监控 NT/Win 2000 计算机（发出一条错误消息：“未找到计算机名”或“无法连接到主机”）
解决：要监控的 NT/Win 2000 计算机仅允许具有管理员权限的用户进行监控。要允许非管理员用户进行监控，必须授予用户对特定文件和注册表项的读取权限（Microsoft 技术说明编号 Q158438）。需要执行下列步骤：
a. 使用浏览器或文件管理器，授予用户对下列项的读取权限：
   %windir%\system32\PERFCxxx.DAT 
     %windir%\system32\PERFHxxx.DAT 
     其中 xxx 是系统的基本语言 ID，例如，英语的 ID 为 009。这些文件可能已丢失或损坏。如果对此有怀疑，请从安装 CD 中提取这些文件。
b. 使用 REGEDT32，授予用户对下列项的读取权限：
   HKEY_LOCAL_MACHINE\Software\Microsoft\Windows
     NT\CurrentVersion\Perflib以及该项的所有子项。
c. 使用 REGEDT32，至少授予用户对下列项的读取权限：
   HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurePipeServers\winreg

问题3：无法从 NT 计算机监控某些 Win 2000 计数器。
解决：在 Win 2000 计算机上运行 Controller 或优化控制台。

问题4：某些 Windows 默认计数器生成错误
解决：删除有问题的计数器，并使用“添加度量”对话框添加相应计数器。

问题5：无法从被监控的计算机上获得 SQL Server 6.5 版的性能计数器。
解决：这是 SQL Server 6.5 版的一个错误。解决方法为：在被监控的计算机上使用 regedt32，授予用户对以下注册表项的读取权限：HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\MSSQLServer

问题6：选定度量未显示在图中。
解决：确保已注册显示文件和 online.exe。要在不执行完全安装的情况下注册监控器的 dll，请运行LoadRunner\bin中的set_mon.bat批处理文件。

问题7：监控 Windows 计算机时，图中不显示任何度量。
解决：检查内置的 Windows 性能监控器。如果该监控器不能正常工作，则可能是通信设置有问题。

问题8：监控 UNIX 计算机时，图中不显示任何度量。
解决：确保rstatd正在 UNIX 计算机上运行（请参阅“系统资源监控”）。

问题9：无法监控下列 Web 服务器之一：MS IIS、MS ASP 或ColdFusion
解决：请参阅上面的问题“无法监控 Windows 计算机”。

问题10：无法监控 WebLogic (JMX) 服务器
解决：打开<LoadRunner 根文件夹>\dat\monitors\WebLogicMon.ini文件，并搜索：[WebLogicMonitor]JVM=javaw.exe
将 javaw.exe 更改为 java.exe。将打开一个包含跟踪信息的窗口。

5) 确认并打开共享文件。首先，在被监视的WINXP机器:右击我的电脑，选择管理->共享文件夹->共享 在这里面要有C$这个共享文件夹。该文件可能存在，也可能不存在，没有的话，需要手动增加。然后，在安装LR的机器上使用运行，输入\\被监视机器IP\C$ 然后输入管理员帐号和密码，如果能看到被监视机器的C盘了，就说明你得到了那台机器的管理员权限，可以使用LR去连接了。
注意：这两步必须都进行操作，否则即使该共享文件已经存在但未在LR机器中进行连接，也可能无法正常使用。
2用LR监视windows的步骤

具体步骤参见LoadRunner Controller User’s Guild > Working with Firewalls >Monitoring Over a Firewall>Configuring Server Monitor Properties。

 

应用场景
　　假设有3个不同的测试场景，分别为并发登录、核心业务、可靠性测试，3个场景有先后执行顺序。由于白天测试机器另有用处，只能在晚上进行性能测试，这时我们的期望是能否把测试场景都设定好之后晚上自动运行，第二天我们回来看测试结果呢？
答案是肯定的，可以有两种方式实现。

　　第一种，相对简单
　　充分利用LR Controller里面Group的功能。
　　新建一个场景把3个脚本都添加进来，在Edit Schedule中选择“Schedule by Group”的方式，在StartTime中设置3个脚本的运行顺序为“Start when Group xxx finished”，并在“Scenario Start Time”中设定场景在晚上的运行启动时间。设定完定时执行场景后，点击StartScenario按钮，会出现一个倒计时窗口，这样在固定的某个时间上，测试场景中的3个脚本将乖乖的按照设定的先后顺序进行测试。注意，如果没有点击StartScenario按钮激活测试，是不会真正进行测试的。（感谢Athenst朋友的提醒，^_^）

　　第二种，比较灵活
　　我们把应用场景稍微扩展一下，假设其中1、3场景只有一个测试脚本，而核心业务场景由数据录入、数据查询、数据上报3个脚本组成，同样的，3个场景仍需按顺序进行测试。这时如果采用第一种方式，由于第2个场景有3个脚本，所以第三个脚本的启动时间就是一个问题了。由于Controller中每个脚本都对应一个Group，而且GroupName不能重复，这时第三个场景的StartTime中“Start when group finished”则只能是选择第二个场景中的某个Group，而并非是第二个场景的3个脚本都完成之后再进行，无法达到我们的初衷。
　　这时，可以通过命令行的方式来进行。
　　首先创建并设置好3个测试场景，再创建一个一个批处理程序按先后顺序调用这3个场景进行测试，最后通过Windows的定时任务设定批处理的执行时间。
　　批处理示例如下：

cls SET M_ROOT="D:\Program Files\MI\Mercury LoadRunner\bin\" %M_ROOT%\wlrun.exe -TestPath "D:\Program Files\MI\Mercury LoadRunner\scenario\Test\TestScen_1.lrs" -Run %M_ROOT%\wlrun.exe -TestPath "D:\Program Files\MI\Mercury LoadRunner\scenario\Test\TestScen_2.lrs" -Run %M_ROOT%\wlrun.exe -TestPath "D:\Program Files\MI\Mercury LoadRunner\scenario\Test\TestScen_3.lrs" -Run

　　这种方式比较灵活，但需要注意在Result　Settings中设置“Automatically create a results directory for each scenario execution”，以免后面的测试结果覆盖了前面的。

　　另外补充一下，如果想对某个脚本进行50、100、150...等用户数递增的测试，也可以用以上方法实现，但需要注意的是将事务名称区分开以便进行分析。

　1、使用LR自带的监控引擎

　　在LR的controller上安装oracle客户端：

　　这一步就不用说了，安装直接Setup，安装就OK了。

　　1）安装完后，先配置一下Net Configuration Assistant。记住配置的服务名。

　　配置成功会显示：正在连接...测试成功。

　　2）用sqlplus连接一下，看是否可以连接成功，打开sqlplus输入oracle用户名密码和主机字符串。

　　查看是否登录成功。

　　添加oracle计数器：

　　3）登录成功后，打开LR的controller.，在可用图中选择oracle，点击add measurements,再点击Advanced，如下所示：

　　这里我们用LR native monitors。

　　4）在Monitored Server Machines区域，添加oracle服务器所在的IP。

　　5）再在Resource Measurements on:IP区域点击添加，弹出对话框如下：

　　6）输入相应的信息，这里的orcl就是前面在Net Configuration Assistant配置的服务名。

　　7）点击OK，这里我们应该可以看到可以添加oracle的计数器了，如下所示：

　2、使用Sitescope引擎

　　不需要配置Net Configuration Assistant。

　　1）在第一个图choose monitor engine中选择sitescope，然后在在Monitored Server Machines区域点击Add如下所示：

　　在这里可以选择本地或者其他机器的sitescope，如果sitescope启用了account的验证，也要写上相应的用户名密码。

　　2）在Resource Measurements on:IP区域点击添加，弹出对话框如下：

　　3）输入信息如图。点击OK，如下：

　　至此就可以监控Oracle了。

1.前期准备：
 
 
1,把rstatd文件解压到要监控的机器上。
2,打开终端，定位到rstatd文件夹下：查看文件夹中的内容如下：
　　

[root@localhost rpc.rstatd]# ls aclocal.m4    COPYING     Makefile.am    README        rstat_proc.c rup.1 config.h.in   CVS         Makefile.in    rpc.rstatd.8 rstat.x       rup.c configure     INSTALL     missing        rstatd.8      rsysinfo.1    stamp-h.in configure.in install-sh mkinstalldirs rstat_main.c rsysinfo.c

2.执行如下步骤：
 
 
2.1.执行：./configure 命令
 
 

[root@localhost rpc.rstatd]# ./configure creating cache ./config.cache checking for a BSD compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking whether make sets ${MAKE}... yes checking for working aclocal... found checking for working autoconf... found checking for working automake... found checking for working autoheader... found checking for working makeinfo... found checking for gawk... gawk checking for gcc... gcc checking whether the C compiler (gcc ) works... yes checking whether the C compiler (gcc ) is a cross-compiler... no checking whether we are using GNU C... yes checking whether gcc accepts -g... yes checking for a BSD compatible install... /usr/bin/install -c checking whether ln -s works... yes checking whether make sets ${MAKE}... (cached) yes checking how to run the C preprocessor... gcc -E checking for sys/ioctl.h... yes checking for syslog.h... yes checking whether time.h and sys/time.h may both be included... yes checking whether gcc needs -traditional... no checking for ANSI C header files... yes checking return type of signal handlers... void updating cache ./config.cache creating ./config.status kcreating Makefile creating config.h

1、设置代理服务器可能引起这个MERR-26612，取消代理服务器的设置解决
2、取消选中run time settings-browser emulation-download non-html resources.解决
3、没有设置关联，在录制完成之后F8，自动关联看看
4、服务器程序本身问题

　　分析原则：

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

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

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

　　分析的信息来源：

　　1. 根据场景运行过程中的错误提示信息

　　2. 根据测试结果收集到的监控指标数据

　　一．错误提示分析

　　分析实例：

　　1．Error: Failed to connect to server “172.17.7.230″: [10060] Connection

　　Error: timed out Error: Server “172.17.7.230″ has shut down the connection prematurely

　　分析：

　　A、应用服务死掉。

　　（小用户时：程序上的问题。程序上处理数据库的问题，实际测试中多半是服务器链接的配置问题）

　　B、应用服务没有死

　　（应用服务参数设置问题）

　　对应的Apache和tomcat的最大链接数需要修改，如果连接时收到connection refused消息，说明应提高相应的服务器最大连接的设置，增加幅度要根据实际情况和服务器硬件的情况来定，建议每次增加25%！

　　C、数据库的连接

　　(数据库启动的最大连接数（跟硬件的内存有关）)

　　D、我们的应用程序spring控制的最大链接数太低

　　2. Error: Page download timeout (120 seconds) has expired

　　分析：

　　A、应用服务参数设置太大导致服务器的瓶颈

　　B、页面中图片太多

　　C、在程序处理表的时候检查字段太大多

　　D、实际测试时有些资源需要请求外网，而我们的测试环境是局域网环境

　　3. Error “http://172.17.7.230/Home.do....”

　　分析：

　　A、脚本设计错误，造成页面异常。服务器有响应！

　　B、并发数过大，造成服务器响应延迟。

　　4. Error page “text=xxxxx”

　　分析：

　　A、脚本设计问题，例如，前一脚本修改了某些内容，造成后面的脚本访问异常。

　　B、不确定因素，有时候回放正常的脚本，一放到场景中就出现这样的错误。只能反复修改脚本！

　　二．监控指标数据分析

　　1．Vusers数

　　Loadrunner 系统设置的虚拟用户数目。Vuser去实际调用事先制作的脚本文件中的应用。

　　每个Vuser产生响应的操作，所有的操作对服务器形成并发。

　　颜色 比例 度量 图最小值 图平均值 图最大值 图中间值 图SD

　　1 Run 0.0 21.25 44 41 21.276

　　在实际测试中，Vusers可以根据实际情况的需要，在测试过程中增加或者减少。

　　2．最大并发用户数：

　　颜色 比例 度量 最小值 平均值 最大值 SD

　　100 Apache CPU 使用情况(Apache):172.17.7.210 0.777 0.852 0.93 0.043

　　0.01 已发送 KB/秒(Apache):172.17.7.210 6 1430.371 2689.333 327.924

　　0.1 点击次数/秒(Apache):172.17.7.210 0.333 114.352 533.667 40.201

　　应用系统在当前环境下能承受的最大并发用户数。

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

　　从上图可以看出：在测试运行到4个小时左右的时候，apache的点击数/秒开始迅速增加！

3．业务操作响应时间：

　　使用“事务性能摘要”图，可以确定在方案执行期间响应时间过长的事务。

　　颜色 比例 度量

　　1 最小值

　　1 平均值

　　1 最大值

　　分析事务的响应情况，要每次详细分析，目前还只能观察到响应时间过长的事务！

　　4．每秒点击数

　　负载测试期间每秒内 Vuser 在 Web 服务器上点击的次数。可根据点击次数来估算 Vuser 生成的负载数。

　　颜色 比例 度量 图最小值 平均值 图最大值 图中间值 图SD

　　1 点击次数 69.908 105.736 130.244 103.666 12.186

　　从图中不难看出，在4小时的时候，点技数明显增高。和apache的每秒点击数增大的时间相吻合！

　　5．吞吐量

　　负载测试期间 Web 服务器上的吞吐量(字节)。吞吐量表示在任何指定秒内 Vuser 从服务器接收到的数据量。此图可估计 Vuser 生成的负载量(服务器吞吐量)。

　　颜色 比例 度量 图最小值 平均值 图最大值 图中间值 图SD

　　1 Throughput 1257502.795 1375591.372 1525865.047 1372743.691 49130.473

　　同样，从图中可以看出，在4个小时的时候，web服务器的吞吐量开始增高。在图中还可以看到吞吐量的走势图，从开始到进行到4个小时反弹之前呈降低的趋势，这是因为系统在初期调用的资源都是直接来之服务器，运行一段时间后系统的部分资源来自缓存。

　　6．下载组件大小

　　每个页面的组件大小，且包括组件的标头的大小！

　　页面组件大小的分析表格比较复杂，实际分析中可以通过loadrunner的报告分析工具来分析。页面组件大小分析主要是找到页面中比较庞大的组件，如果其影响到了页面的下载速度，则要想办法将其改小！

　　7．Apache资源

　　显示APACHE web服务器上的资源摘要。前面已经提到过以并发点击数为主。

　　颜色 比例 度量 最小值 平均值 最大值 SD

　　100 Apache CPU 使用情况(Apache):172.17.7.210 0.777 0.852 0.93 0.043

　　0.01 已发送 KB/秒(Apache):172.17.7.210 6 1430.371 2689.333 327.924

　　0.1 点击次数/秒(Apache):172.17.7.210 0.333 114.352 533.667 40.201

　　三．服务器资源监控指标：

　　（目前通过top监察）

　　内存：

　　Linux资源监控中指标内存页交换速率（Paging rate），如果该值偶尔走高，表明当时有线程竞争内存。如果持续很高，则内存可能是瓶颈。也可能是内存访问命中率低。

　　实际测试中，当并发点击数出现突然剧增前后，内存的PR 值则居高25不下。说明目前测试的系统中内存存在瓶颈！

　　内存资源成为系统性能的瓶颈的征兆:

　　很高的换页率(high pageout rate);

　　进程进入不活动状态;

　　交换区所有磁盘的活动次数可高;

　　可高的全局系统CPU利用率;

　　内存不够出错(out of memory errors)

　　处理器：

　　Linux资源监控中指标CPU占用率持续超过80%（对该值的要求，根据具体应用和机器配置而要求不同，有资料表明95％），表明瓶颈是CPU。

　　实际测试中，当并发点技数出现突然增加前后，cpu的占用率持续保持在86％以上！

　　说明，目前系统用应用的cpu也是测试的瓶颈！

　　CPU资源成为系统性能的瓶颈的征兆:

　　很慢的响应时间(slow response time)

　　CPU空闲时间为零(zero percent idle CPU)

　　过高的用户占用CPU时间(high percent user CPU)

　　过高的系统占用CPU时间(high percent system CPU)

　　长时间的有很长的运行进程队列(large run queue size sustained over time)

　　四．数据库服务器：

　　数据库服务器目前测试观察，当web服务器点击率增大时，观察mysql数据库的最大连接数，仍未超过系统设置的最大连接数。所以，暂时未发现数据库的瓶颈！

　　五．结论

　　以上报告分析中的数据、图标均来自同一次测试。是在平时测试中挑出的一次现象比较明显，比较利于观察的作为分析案例。

　　根据以上综合分析，当前测试环境下，当应用系统产生最大533.667的并发压力。平均负载压力114.352。根据分析，用户在4个小时的时候，并发数迅速增加前后的值在400左右！分析结果跟实际测试的硬件环境以及测试脚本有一定关系。同时，测试服务器的硬件配置和实际服务器的配置还有一定的差距！

在测试过程中，可能会出现以下常见的几种测试情况：

　　一、当事务响应时间的曲线开始由缓慢上升，然后处于平衡，最后慢慢下降这种情形表明：

　　* 从事务响应时间曲线图持续上升表明系统的处理能力在下降，事务的响应时间变长；

　　* 持续平衡表明并发用户数达到一定数量，在多也可能接受不了，再有请求数，就等待；

　　* 当事务的响应时间在下降，表明并发用户的数量在慢慢减少，事务的请求数也在减少。

　　如果系统没有这种下降机制，响应时间越来越长，直到系统瘫痪。

　　从以上的结果分析可发现是由以下的原因引起：

　　1. 程序中用户数连接未做限制，导致请求数不断上升，响应时间不断变长；

　　2. 内存泄露；

　　二、CPU的使用率不断上升，内存的使用率也是不断上升，其他一切都很正常；

　　表明系统中可能产生资源争用情况；

　　引起原因：

　　开发人员注意资源调配问题。

　　三、 所有的事务响应时间、cpu等都很正常，业务出现失败情况；

　　引起原因：

　　数据库可能被锁，就是说，你在操作一张表或一条记录，别人就不能使用，即数据存在互斥性；

　　当数据量大时，就会出现数据错乱情况。

Transactions（用户事务分析）
用户事务分析是站在用户角度进行的基础性能分析。

1、Transation Sunmmary（事务综述）
对事务进行综合分析是性能分析的第一步，通过分析测试时间内用户事务的成功与失败情况，可以直接判断出系统是否运行正常。

2、Average Transaciton Response Time（事务平均响应时间）
“事务平均响应时间”显示的是测试场景运行期间的每一秒内事务执行所用的平均时间，通过它可以分析测试场景运行期间应用系统的性能走向。
例：随着测试时间的变化，系统处理事务的速度开始逐渐变慢，这说明应用系统随着投产时间的变化，整体性能将会有下降的趋势。

3、Transactions per Second（每秒通过事务数/TPS）
“每秒通过事务数/TPS”显示在场景运行的每一秒钟，每个事务通过、失败以及停止的数量，使考查系统性能的一个重要参数。通过它可以确定系统在任何给定时刻的时间事务负载。分析TPS主要是看曲线的性能走向。
将它与平均事务响应时间进行对比，可以分析事务数目对执行时间的影响。
例：当压力加大时，点击率/TPS曲线如果变化缓慢或者有平坦的趋势，很有可能是服务器开始出现瓶颈。

4、Total Transactions per Second（每秒通过事务总数）
“每秒通过事务总数”显示在场景运行时，在每一秒内通过的事务总数、失败的事务总署以及停止的事务总数。

5、Transaction Performance Sunmmary（事务性能摘要）
“事务性能摘要”显示方案中所有事务的最小、最大和平均执行时间，可以直接判断响应时间是否符合用户的要求。
重点关注事务的平均和最大执行时间，如果其范围不在用户可以接受的时间范围内，需要进行原因分析。

6、Transaction Response Time Under Load（事务响应时间与负载）
“事务响应时间与负载”是“正在运行的虚拟用户”图和“平均响应事务时间”图的组合，通过它可以看出在任一时间点事务响应时间与用户数目的关系，从而掌握系统在用户并发方面的性能数据，为扩展用户系统提供参考。此图可以查看虚拟用户负载对执行时间的总体影响，对分析具有渐变负载的测试场景比较有用。

7、Transaction Response Time(Percentile)（事务响应时间(百分比)）
“事务响应时间(百分比)”是根据测试结果进行分析而得到的综合分析图，也就是工具通过一些统计分析方法间接得到的图表。通过它可以分析在给定事务响应时间范围内能执行的事务百分比。

8、Transaction Response Time(Distribution)（事务响应时间(分布)）
“事务响应时间(分布)”显示在场景运行过程中，事务执行所用时间的分布，通过它可以了解测试过程中不同响应时间的事务数量。如果系统预先定义了相关事务可以接受的最小和最大事务响应时间，则可以使用此图确定服务器性能是否在可以接受的范围内。

 

Web Resources（Web资源分析）
Web资源分析是从服务器入手对Web服务器的性能分析。

1、Hits per Second（每秒点击次数）
“每秒点击次数”，即使运行场景过程中虚拟用户每秒向Web服务器提交的HTTP请求数。
通过它可以评估虚拟用户产生的负载量，如将其和“平均事务响应时间”图比较，可以查看点击次数对事务性能产生的影响。通过对查看“每秒点击次数”，可以判断系统是否稳定。系统点击率下降通常表明服务器的响应速度在变慢，需进一步分析，发现系统瓶颈所在。

2、Throughput（吞吐率）
“吞吐率”显示的是场景运行过程中服务器的每秒的吞吐量。其度量单位是字节，表示虚拟用在任何给定的每一秒从服务器获得的数据量。
可以依据服务器的吞吐量来评估虚拟用户产生的负载量，以及看出服务器在流量方面的处理能力以及是否存在瓶颈。
“吞吐率”图和“点击率”图的区别：
“吞吐率”图，是每秒服务器处理的HTTP申请数。
“点击率”图，是客户端每秒从服务器获得的总数据量。

3、HTTP Status Code Summary（HTTP状态代码概要）
“HTTP状态代码概要”显示场景或会话步骤过程中从Web服务器返回的HTTP状态代码数，该图按照代码分组。HTTP状态代码表示HTTP请求的状态。

4、HTTP Responses per Second（每秒HTTP响应数）
“每秒HTTP响应数”是显示运行场景过程中每秒从Web服务器返回的不同HTTP状态代码的数量，还能返回其它各类状态码的信息，通过分析状态码，可以判断服务器在压力下的运行情况，也可以通过对图中显示的结果进行分组，进而定位生成错误的代码脚本。

5、Pages Downloader per Second（每秒下载页面数）
“每秒下载页面数”显示场景或会话步骤运行的每一秒内从服务器下载的网页数。使用此图可依据下载的页数来计算Vuser生成的负载量。
和吞吐量图一样，每秒下载页面数图标是Vuser在给定的任一秒内从服务器接收到的数据量。但是吞吐量考虑的各个资源极其大小（例，每个GIF文件的大小、每个网页的大小）。而每秒下载页面数只考虑页面数。
注：要查看每秒下载页数图，必须在R-T-S那里设置“每秒页面数(仅HTML模式)”。

6、Retries per Second（每秒重试次数）
“每秒重试次数”显示场景或会话步骤运行的每一秒内服务器尝试的连接次数。
在下列情况将重试服务器连接：
A、初始连接未经授权
B、要求代理服务器身份验证
C、服务器关闭了初始连接
D、初始连接无法连接到服务器
E、服务器最初无法解析负载生成器的IP地址

7、Retries Summary（重试次数概要）
“重试次数概要”显示场景或会话步骤运行过程中服务器尝试的连接次数，它按照重试原因分组。将此图与每秒重试次数图一起使用可以确定场景或会话步骤运行过程中服务器在哪个时间点进行了重试。

8、Connections（连接数）
“连接数”显示场景或会话步骤运行过程中每个时间点打开的TCP/IP连接数。
借助此图，可以知道何时需要添加其他连接。
例：当连接数到达稳定状态而事务响应时间迅速增大时，添加连接可以使性能得到极大提高（事务响应时间将降低）。

9、Connections Per Second（每秒连接数）
“每秒连接数”显示方案在运行过程中每秒建立的TCP/IP连接数。
理想情况下，很多HTTP请求都应该使用同一连接，而不是每个请求都新打开一个连接。通过每秒连接数图可以看出服务器的处理情况，就表明服务器的性能在逐渐下降。

10、SSLs Per Second（每秒SSL连接数）
“每秒SSL连接数”显示场景或会话步骤运行的每一秒内打开的新的以及重新使用的SSL连接数。当对安全服务器打开TCP/IP连接后，浏览器将打开SSL连接。

Web Page Breakdown（网页元素细分）
“网页元素细分”主要用来评估页面内容是否影响事务的响应时间，通过它可以深入地分析网站上那些下载很慢的图形或中断的连接等有问题的
元素。

1、Web Page Breakdown（页面分解总图）
“页面分解”显示某一具体事务在测试过程的响应情况，进而分析相关的事务运行是否正常。
“页面分解”图可以按下面四种方式进行进一步细分：
1)、Download Time Breaddown（下载时间细分）
“下载时间细分”图显示网页中不同元素的下载时间，同时还可按照下载过程把时间进行分解，用不同的颜色来显示DNS解析时间、建立连接时间、第一次缓冲时间等各自所占比例。
2)、Component Breakdown(Over Time)（组件细分(随时间变化)）
“组件细分”图显示选定网页的页面组件随时间变化的细分图。通过该图可以很容易的看出哪些元素在测试过程中下载时间不稳定。该图特别适用于需要在客户端下载控件较多的页面，通过分析控件的响应时间，很容易就能发现那些控件不稳定或者比较耗时。
3)、Download Time Breakdown(Over Time)（下载时间细分(随时间变化)）
“下载时间细分(随时间变化)” 图显示选定网页的页面元素下载时间细分（随时间变化）情况，它非常清晰地显示了页面各个元素在压力测试过程中的下载情况。
“下载时间细分”图显示的是整个测试过程页面元素响应的时间统计分析结果，“下载时间细分(随时间变化)”显示的事场景运行过程中每一秒内页面元素响应时间的统计结果，两者分别从宏观和微观角度来分析页面元素的下载时间。
4)、Time to First Buffer Breakdown(Over Time)（第一次缓冲时间细分(随时间变化)）
“第一次缓冲时间细分(随时间变化)”图显示成功收到从Web服务器返回的第一次缓冲之前的这段时间，场景或会话步骤运行的每一秒中每个网页组件的服务器时间和网络时间（以秒为单位）。可以使用该图确定场景或会话步骤运行期间服务器或网络出现问题的时间。
First Buffer Time：是指客户端与服务器端建立连接后，从服务器发送第一个数据包开始计时，数据经过网络传送到客户端，到浏览器接收到第一个缓冲所用的时间。

2、Page Component Breakdown（页面组件细分）
“页面组件细分”图显示每个网页及其组件的平均下载时间（以秒为单位）。可以根据下载组件所用的平均秒数对图列进行排序，通过它有助于隔离有问题的组件。

3、Page Component Breakdown(Over Time)（页面组件分解(随时间变化)）
“页面组件分解(随时间变化)”图显示在方案运行期间的每一秒内每个网页及其组件的平均响应时间 （以秒为单位）。

4、Page Download Time Breakdown（页面下载时间细分）
“页面下载时间细分”图显示每个页面组件下载时间的细分，可以根据它确定在网页下载期间事务响应时间缓慢是由网络错误引起还是由服务器错误引起。
“页面下载时间细分”图根据DNS解析时间、连接时间、第一次缓冲时间、SSL握手时间、接收时间、FTP验证时间、客户端时间和错误时间来对每个组件的下载过程进行细分。

5、Page Download Time Breakdown(Over Time)（页面下载时间细分(随时间变化)）
“页面下载时间细分(随时间变化)”图显示方案运行期间，每一秒内每个页面组件下载时间的细分。使用此图可以确定网络或服务器在方案执行期间哪一时间点发生了问题。
“页面组件细分(随时间变化)”图和“页面下载时间细分(随时间变化)”图通常结合起来进行分析：首先确定有问题的组件，然后分析它们的下载过程，进而定位原因在哪里。

6、Time to First Buffer Breakdown（第一次缓冲时间细分）
“第一次缓冲时间细分”图显示成功收到从Web服务器返回的第一次缓冲之前的这一段时间内的每个页面组件的相关服务器/网路时间。如果组件的下载时间很长，则可以使用此图确定产生的问题与服务器有关还是与网络有关。
网络时间：定义为第一个HTTP请求那一刻开始，直到确认为止所经过的平均时间。
服务器时间：定义为从收到初始HTTP请求确认开始，直到成功收到来自Web服务器的一次缓冲为止所经过的平均时间。

7、Time to First Buffer Breakdown(Over Time)（第一次缓冲时间细分(随时间变化)）
“第一次缓冲时间细分(随时间变化)”图显示成功收到从Web服务器返回的第一个缓冲之前的这段时间内，场景运行的每一秒中每个网页组件的服务器时间和网络时间。可以使用此图确定场景运行期间服务器或网络出现问题的时间点。

8、Downloader Component Size(KB)（已下载组件大小）
“已下载组件大小”图显示每个已经下载的网页组建的大小。通过它可以直接看出哪些组件比较大并需要进一步进行优化以提高性能

TPS  1   Transactions Per Second 的 缩 写， 也 就 是 事 务 数/ 秒

         2   Throughtput Per Second 的缩写，单位：Byte/second 字节/秒，也就是吞吐量啦。。。。。
 
【分享】Network Interface 计数器

 

许多人对 Kbps、KB、Mbps 等速度单位有所误解，
以下简单解释一下所谓的 1.5M、3M、6M 如何计算。
所谓 1.5M 宽带，其实是指 1.5Mbps (bits per second)，亦即 1.5 x 1024 / 8 = 192KB/sec，

但这只是理论上的速度，实际上则要再扣约 12% 的 Ethernet Header, IP Header, TCP Header, ATM Header 等控制讯号，故其传输速度上限应为 169KB/sec 左右。

在传输单位的写法上，B 和 b 分别代表 Bytes 和 bits，两者的定义是不同的，钱万不要混淆。

1 Byte = 8 bits
1 Kb = 1024 bits
1 KB = 1024 bytes
1 Mb = 1024 Kb
1 MB = 1024 KB

宽带最高下载理论值

1.5 M =169 KB/s
3 M =338 KB/s
6 M =676 KB/s
10 M =1126 KB/s

以上谈到的是理论值，对于实际的连接速度可以通过下载文件的方法来测试，

Bytes Total/sec    是在每个网络适配器上发送和接收字节的速率，包括帧字符在内。Network Interface\\Bytes Received/sec=Network Interface\\Bytes Received/sec+Network Interface\\Bytes Sent/sec.

Current Bandwidth  指以位/每秒估计的网络接口的当前带宽。

Output Queue Length      为输出数据列队(数据包)的长度。如果这个长于 2，即会出现延缓并且如果可能的话找出并解决瓶颈问题。由于请求是在这个操作由网络驱动程序接口规格(NDIS)列队，这永远会是 0。

Packets/sec      为在网络界面发送和接收数据包的速率。

Packets Outbound Discarded      为选为丢弃的输出数据包的数目，即便没有发现会阻止传输这些数据包的错误。丢弃数据包的可能原因是释放缓冲空间。

Packets Outbound Error      为由于错误不能传输的输出数据包的数目。

Packets Received Discarded      指选定要丢弃的输入数据包的数字，即使没有发现阻碍这些数据包成为可传送到更高层协议的错误。造成丢弃数据包的可能原因是释放缓冲器空间。

Packets Received Error       指输入数据包的数目，这些数据包含阻碍它们成为可传送到更高层协议的错误。

Packets Received/sec        为在网络界面接收数据包的速率。

Packets Sent/sec      为在网络界面发送数据包的速率。

 

 

【分享】Processor计数器
Processor计数器

% Processor Time        指处理器用来执行非闲置线程时间的百分比。计算方法是，测量范例间隔内非闲置线程活动的时间，用范例间隔减去该值。(每台处理器有一个闲置线程，该线程在没有其他线程可以运行时消耗周期)。这个计数器是处理器活动的主要说明器，显示在范例间隔时所观察的繁忙时间平均百分比。这个值是用 100% 减去该服务不活动的时间计算出来的。    通常CPU的平均活动符合应该在80%以下，超过80%表示CPU的处理能力已经达到极限。

% DPC Time        指在范例间隔期间处理器用在缓延程序调用(DPC)接收和提供服务的百分比。DPC 正在运行的为比标准间隔优先权低的间隔。由于 DPC 是以特权模式执行的，DPC 时间的百分比为特权时间百分比的一部分。这些时间单独计算并且不属于间隔计算总数的一部分。这个总数显示了作为实例时间百分比的平均忙时。越低越好。在多处理器系统中，如果这个值大于50%并且Processor:% Processor Time非常高，加入一个网卡可能会提高性能，提供的网络已经不饱和。

% Privileged Time        在特权模式下处理线程执行代码所花时间的百分比。当调用 Windows 系统服务时，此服务经常在特权模式运行，以便获取对系统专有数据的访问。在用户模式执行的线程无法访问这些数据。 对系统的调用可以是直接的(explicit)或间接的(implicit)，例如页面错误或中断。不像某些早期的操作系统，Windows 除了使用用户和特权模式的传统保护模式之外，还使用处理边界作为分系统保护。某些由 Windows 为您的应用程序所做的操作除了出现在处理的特权时间内，还可能在其他子系统处理出现。这个时间包括CPU维护中断和延迟过程调用的时间。如果该值过高，应该有I/O处理导致大量系统中断。

% User Time        指处理器处于用户模式的时间百分比。用户模式是为应用程序、环境分系统和整数分系统设计的有限处理模式。另一个模式为特权模式，它是为操作系统组件设计的并且允许直接访问硬件和所有内存。操作系统将应用程序线程转换成特权模式以访问操作系统服务。这个计数值将平均忙时作为示例时间的一部分显示。

Interrupts/sec        是处理器接收和处理硬件中断的平均速度，单位为每秒事例数。这不包括分开计数的延迟的进程调用(DPCs)。这个值说明生成中断的设备(如系统时钟、鼠标、磁盘驱动器、数据通讯线、网络接口卡和其他外缘设备)的活动。这些设备通常在完成任务或需要注意时中断处理器。正常线程执行因此被中断。系统时钟通常每 10 毫秒中断处理器一次，创建中断活动的背景。这个计数值显示用上两个实例中观察到的值之间的差除于实例间隔的持续时间所得的值。

% Interrupt Time        是处理器在实例间隔期间接受和服务硬件中断的时间。此值间接表示了生成间隔的设备活动， 如系统时钟、鼠标、磁盘驱动程序、数据通讯线路、网络界面卡和其他外围设备。当这些设备完成一项任务或需要管理时，它们通常会中断处理器。中断期间，正常的线程执行会停止。多数系统时钟会每隔 10 毫秒中断处理器，产生间隔活动的背景，在间隔期间，终止正常的线程执行。此计数器显示此平均占用时间为实例时间的一部分。

Private Bytes        指这个处理不能与其他处理共享的、已分配的当前字节数。

Page Faults/sec        指在这个进程中执行线程造成的页面错误出现的速度。当线程引用了不在主内存工作集中的虚拟内存页即会出现 Page Fault。如果它在备用表中(即已经在主内存中)或另一个共享页的处理正在使用它，就会引起无法从磁盘中获取页。

% User Time        指处理线程用于执行使用用户模式的代码的时间的百分比。应用程序、环境分系统和集合分系统是以用户模式执行的。Windows 的可执行程序、内核和设备驱动程序不会被以用户模式执行的代码损坏。不像某些早期的操作系统，Windows 除了使用用户和特权模式的传统式保护模式之外，还使用处理边界作为分系统保护。某些由 Windows 为您的应用程序所做的操作除了出现在处理的特权时间内，还可能在其他子系统处理出现。

% Privileged Time        是在特权模式下处理线程执行代码所花时间的百分比。当调用 Windows 系统服务时，此服务经常在特权模式运行，以便获取对系统专有数据的访问。在用户模式执行的线程无法访问这些数据。对系统的调用可以是直接的(explicit)或间接的(implicit)，例如页面错误或间隔。不像某些早期的操作系统，Windows 除了使用用户和特权模式的传统保护模式之外，还使用进程边界作为分系统保护。某些由 Windows 为您的应用程序所做的操作除了出现在进程的特权时间内，还可能在其他子系统进程出现。

% Processor Time        是所有进程线程使用处理器执行指令所花的时间百分比。指令是计算机执行的基础单位。线程是执行指令的对象，进程是程序运行时创建的对象。此计数包括处理某些硬件间隔和陷阱条件所执行的代码。

Virtual Bytes        指处理使用的虚拟地址空间的以字节数显示的当前大小。使用虚拟地址空间不一定是指对磁盘或主内存页的相应的使用。虚拟空间是有限的，可能会限制处理加载数据库的能力。

Working Set        指这个处理的 Working Set 中的当前字节数。Working Set 是在处理中被线程最近触到的那个内存页集。如果计算机上的可用内存处于阈值以上，即使页不在使用中，也会留在一个处理的 Working Set中。当可用内存降到阈值以下，将从 Working Set 中删除页。如果需要页时，它会在离开主内存前软故障返回到 Working Set 中。

Page File Bytes        指这个处理在 Paging file 中使用的最大字节数。Paging File 用于存储不包含在其他文件中的由处理使用的内存页。Paging File 由所有处理共享，并且 Paging File 空间不足会防止其他处理分配内存。

I/O Data Bytes/sec        处理从 I/O 操作读取/写入字节的速度。这个计数器为所有由本处理产生的包括文件、网络和设备 I/O 的活动计数。

 

 

【分享】Memory计数器

Page Faults/sec        每秒钟出错页面的平均数量。由于每个错误操作中只有一个页面出错，计算单位为每秒出错页面数量，因此这也等于页面错误操作的数量。这个计数器包括硬错误(那些需要磁盘访问的)和软错误(在物理内存的其他地方找到的错误页)。许多处理器可以在有大量软错误的情况下继续操作。但是，硬错误可以导致明显的拖延。当进程请求一块内存但系统无法分配时发生页面错误，该值过高（与未加压时比较）可能有两方面的原因：
                       1、 应用程序已经占用了过多内存，这可以通过增加内存量来解决。
                        2、 应用程序的内存请求过于频繁（如：频繁地创建和销毁对象）。此时要考虑更改设计。

Committed Bytes        指以字节表示的确认虚拟内存。确认内存磁盘页面文件上保留了空间的物理内存。每个物理磁盘上可以有一个或一个以上的页面文件。这个计数器只显示上一回观察到的值；它不是一个平均值。

Available MBytes        计算机上运行的进程的可用物理内存大小，单位是千字节，而不是在 Memory\\Available Bytes 中报告的字节。它是将零的、空闲的和备用内存列表的空间添加在一起来计算的。空闲内存可随时使用; 零内存是为了防止以后的进程看到以前进程使用的数据而在很多页内存中填满了零的内存。备用内存是指从进程的工作集(它的物理 内存)移到磁盘的，但是仍旧可以重新调用的内存。 这个计数器只显示观察到的最后一个值；它不是一个平均值。当这个数值变小时，Windows开始频繁地调用磁盘页面文件。如果这个数值很小，例如小于5 MB，系统会将大部分时间消耗在操作页面文件上。

Pages/sec        指为解决硬页错误从磁盘读取或写入磁盘的速度。这个计数器是可以显示导致系统范围延缓类型错误的主要指示器。它是 Memory\\Pages Input/sec 和 Memory\\Pages Output/sec 的总和。是用页数计算的，以便在不用做转换的情况下就可以同其他页计数如: Memory\\Page Faults/sec 做比较，这个值包括为满足错误而在文件系统缓存(通常由应用程序请求)的非缓存映射内存文件中检索的页。    一般如果pages/sec持续高于几百，那么您应该进一步研究页交换活动。

Commit Limit        指在不用扩展分页文件的情况下可以使用的虚拟内存的数量。这是用字节来计算的。确认的内存是指保留在磁盘分页文件上的物理内存。在每个逻辑磁盘上可以有一个分页内存。如果扩展分页文件，这个限量将相应增加。这个计数器只显示上一回观察到的值；而不是一个平均值。

 

今天，我先把我整理的一些计数器及其阈值要求等贴出来，这些计数器是针对我对windows操作系统，C/S结构的sql server数据库及WEB平台。net产品测试时的一些计数器；大家可以继续补充，作过unix平台上oracle数据库测试及J2EE架构及WEBLOGIC方面测试的朋友，也希望把自己使用的计数器贴出来，让大家分享。

    好了，先说这些了，希望通过这个专题，最终能让大家对自己的测试结果进行分析。

    Memory： 内存使用情况可能是系统性能中最重要的因素。如果系统“页交换”频繁，说明内存不足。“页交换”是使用称为“页面”的单位，将固定大小的代码和数据块从 RAM 移动到磁盘的过程，其目的是为了释放内存空间。尽管某些页交换使 Windows 2000 能够使用比实际更多的内存，也是可以接受的，但频繁的页交换将降低系统性能。减少页交换将显著提高系统响应速度。要监视内存不足的状况，请从以下的对象计数器开始：Available Mbytes：可用物理内存数。 如果Available Mbytes的值很小（4 MB 或更小），则说明计算机上总的内存可能不足，或某程序没有释放内存。

    page/sec： 表明由于硬件页面错误而从磁盘取出的页面数，或由于页面错误而写入磁盘以释放工作集空间的页面数。一般如果pages/sec持续高于几百，那么您应该进一步研究页交换活动。有可能需要增加内存，以减少换页的需求（你可以把这个数字乘以4k就得到由此引起的硬盘数据流量）。Pages/sec 的值很大不一定表明内存有问题，而可能是运行使用内存映射文件的程序所致。

    page read/sec：页的硬故障，page/sec的子集，为了解析对内存的引用，必须读取页文件的次数。阈值为>5. 越低越好。大数值表示磁盘读而不是缓存读。

    由于过多的页交换要使用大量的硬盘空间，因此有可能将导致将页交换内存不足与导致页交换的磁盘瓶径混淆。因此，在研究内存不足不太明显的页交换的原因时，您必须跟踪如下的磁盘使用情况计数器和内存计数器：Physical Disk\ % Disk Time Physical Disk\ Avg.Disk Queue Length例如，包括 Page Reads/sec 和 % Disk Time 及 Avg.Disk Queue Length.如果页面读取操作速率很低，同时 % Disk Time 和 Avg.Disk Queue Length的值很高，则可能有磁盘瓶径。但是，如果队列长度增加的同时页面读取速率并未降低，则内存不足。

    要确定过多的页交换对磁盘活动的影响，请将 Physical Disk\ Avg.Disk sec/Transfer 和 Memory\ Pages/sec 计数器的值增大数倍。如果这些计数器的计数结果超过了 0.1，那么页交换将花费百分之十以上的磁盘访问时间。如果长时间发生这种情况，那么您可能需要更多的内存。

    Page Faults/sec：每秒软性页面失效的数目（包括有些可以直接在内存中满足而有些需要从硬盘读取）较page/sec只表明数据不能在内存的指定工作集中立即使用。

    Cache Bytes：文件系统缓存（File System Cache），默认情况下为50%的可用物理内存。如IIS5.0 运行内存不够时，它会自动整理缓存。需要关注该计数器的趋势变化如果您怀疑有内存泄露，请监视 Memory\ Available Bytes 和 Memory\ Committed Bytes，以观察内存行为，并监视您认为可能在泄露内存的进程的 Process\Private Bytes、Process\Working Set 和Process\Handle Count.如果您怀疑是内核模式进程导致了泄露，则还应该监视 Memory\Pool Nonpaged Bytes、Memory\ Pool Nonpaged Allocs 和 Process（process_name）\ Pool Nonpaged Bytes.

    Pages per second ：每秒钟检索的页数。该数字应少于每秒一页。

    Process：%Processor Time： 被处理器消耗的处理器时间数量。如果服务器专用于sql server，可接受的最大上限是80-85% Page Faults/sec：将进程产生的页故障与系统产生的相比较，以判断这个进程对系统页故障产生的影响。

    Work set： 处理线程最近使用的内存页，反映了每一个进程使用的内存页的数量。如果服务器有足够的空闲内存，页就会被留在工作集中，当自由内存少于一个特定的阈值时，页就会被清除出工作集。

    Inetinfo：Private Bytes：此进程所分配的无法与其它进程共享的当前字节数量。如果系统性能随着时间而降低，则此计数器可以是内存泄漏的最佳指示器。

    Processor：监视“处理器”和“系统”对象计数器可以提供关于处理器使用的有价值的信息，帮助您决定是否存在瓶颈。

    %Processor Time：如果该值持续超过95%，表明瓶颈是CPU.可以考虑增加一个处理器或换一个更快的处理器。

    %User Time：表示耗费CPU的数据库操作，如排序，执行aggregate functions等。如果该值很高，可考虑增加索引，尽量使用简单的表联接，水平分割大表格等方法来降低该值。

    %Privileged Time：（CPU内核时间）是在特权模式下处理线程执行代码所花时间的百分比。如果该参数值和"Physical Disk"参数值一直很高，表明I/O有问题。可考虑更换更快的硬盘系统。另外设置Tempdb in RAM，减低"max async IO"，"max lazy writer IO"等措施都会降低该值。

    此外，跟踪计算机的服务器工作队列当前长度的 Server Work Queues\ Queue Length 计数器会显示出处理器瓶颈。队列长度持续大于 4 则表示可能出现处理器拥塞。此计数器是特定时间的值，而不是一段时间的平均值。

    % DPC Time：越低越好。在多处理器系统中，如果这个值大于50%并且Processor：% Processor Time非常高，加入一个网卡可能会提高性能，提供的网络已经不饱和。

    Thread ContextSwitches/sec： （实例化inetinfo 和dllhost 进程） 如果你决定要增加线程字节池的大小，你应该监视这三个计数器（包括上面的一个）。增加线程数可能会增加上下文切换次数，这样性能不会上升反而会下降。如果十个实例的上下文切换值非常高，就应该减小线程字节池的大小。

    Physical Disk：%Disk Time %：指所选磁盘驱动器忙于为读或写入请求提供服务所用的时间的百分比。如果三个计数器都比较大，那么硬盘不是瓶颈。如果只有%Disk Time比较大，另外两个都比较适中，硬盘可能会是瓶颈。在记录该计数器之前，请在Windows 2000 的命令行窗口中运行diskperf -yD.若数值持续超过80%，则可能是内存泄漏。

    Avg.Disk Queue Length：指读取和写入请求（为所选磁盘在实例间隔中列队的）的平均数。该值应不超过磁盘数的1.5~2 倍。要提高性能，可增加磁盘。注意：一个Raid Disk实际有多个磁盘。

    Average Disk Read/Write Queue Length：指读取（写入）请求（列队）的平均数。

    Disk Reads（Writes）/s： 物理磁盘上每秒钟磁盘读、写的次数。两者相加，应小于磁盘设备最大容量。

    Average Disksec/Read： 指以秒计算的在此盘上读取数据的所需平均时间。

    Average Disk sec/Transfer：指以秒计算的在此盘上写入数据的所需平均时间。

    Network Interface：Bytes Total/sec ：为发送和接收字节的速率，包括帧字符在内。判断网络连接速度是否是瓶颈，可以用该计数器的值和目前网络的带宽比较

    SQLServer性能计数器：Access Methods（访问方法） 用于监视访问数据库中的逻辑页的方法。。 Full Scans/sec（全表扫描/秒） 每秒不受限的完全扫描数。可以是基本表扫描或全索引扫描。如果这个计数器显示的值比1或2高，应该分析你的查询以确定是否确实需要全表扫描，以及S Q L查询是否可以被优化。。 Page splits/sec（页分割/秒）由于数据更新操作引起的每秒页分割的数量。

    Buffer Manager（缓冲器管理器）：监视 Microsoft&reg； SQL Server？ 如何使用： 内存存储数据页、内部数据结构和过程高速缓存；计数器在 SQL Server 从磁盘读取数据库页和将数据库页写入磁盘时监视物理 I/O. 监视 SQL Server 所使用的内存和计数器有助于确定： 是否由于缺少可用物理内存存储高速缓存中经常访问的数据而导致瓶颈存在。如果是这样，SQL Server 必须从磁盘检索数据。 是否可通过添加更多内存或使更多内存可用于数据高速缓存或 SQL Server 内部结构来提高查询性能。

    SQL Server 需要从磁盘读取数据的频率。与其它操作相比，例如内存访问，物理 I/O 会耗费大量时间。尽可能减少物理 I/O 可以提高查询性能。。Page Reads/sec：每秒发出的物理数据库页读取数。这一统计信息显示的是在所有数据库间的物理页读取总数。由于物理 I/O 的开销大，可以通过使用更大的数据高速缓存、智能索引、更高效的查询或者改变数据库设计等方法，使开销减到最小。。Page Writes/sec （。写的页/秒） 每秒执行的物理数据库写的页数。。Buffer Cache Hit Ratio. 在“缓冲池”（Buffer Cache/Buffer Pool）中没有被读过的页占整个缓冲池中所有页的比率。可在高速缓存中找到而不需要从磁盘中读取的页的百分比。这一比率是高速缓存命中总数除以自 SQL Server 实例启动后对高速缓存的查找总数。经过很长时间后，这一比率的变化很小。由于从高速缓存中读数据比从磁盘中读数据的开销要小得多，一般希望这一数值高一些。通常，可以通过增加 SQL Server 可用的内存数量来提高高速缓存命中率。计数器值依应用程序而定，但比率最好为90% 或更高。增加内存直到这一数值持续高于90%，表示90% 以上的数据请求可以从数据缓冲区中获得所需数据。。 Lazy Writes/sec（惰性写/秒）惰性写进程每秒写的缓冲区的数量。值最好为0. Cache Manager（高速缓存管理器） 对象提供计数器，用于监视 Microsoft&reg； SQL Server？ 如何使用内存存储对象，如存储过程、特殊和准备好的 Transact-SQL 语句以及触发器。。 Cache Hit Ratio（高速缓存命中率，所有Cache“的命中率。在SQL Server中，Cache可以包括Log Cache，Buffer Cache以及Procedure Cache，是一个总体的比率。） 高速缓存命中次数和查找次数的比率。对于查看SQL Server高速缓存对于你的系统如何有效，这是一个非常好的计数器。如果这个值很低，持续低于80%，就需要增加更多的内存。

    Latches（闩） 用于监视称为闩锁的内部 SQL Server 资源锁。监视闩锁以明确用户活动和资源使用情况，有助于查明性能瓶颈。。 Average Latch Wait Ti m e （ m s ） （平均闩等待时间（毫秒）） 一个SQL Server线程必须等待一个闩的平均时间，以毫秒为单位。如果这个值很高，你可能正经历严重的竞争问题。。 Latch Waits/sec （闩等待/秒） 在闩上每秒的等待数量。如果这个值很高，表明你正经历对资源的大量竞争。

    Locks（锁） 提供有关个别资源类型上的 SQL Server 锁的信息。锁加在 SQL Server 资源上（如在一个事务中进行的行读取或修改），以防止多个事务并发使用资源。例如，如果一个排它 （X） 锁被一个事务加在某一表的某一行上，在这个锁被释放前，其它事务都不可以修改这一行。尽可能少使用锁可提高并发性，从而改善性能。可以同时监视 Locks 对象的多个实例，每个实例代表一个资源类型上的一个锁。。 Number of Deadlocks/sec（死锁的数量/秒） 导致死锁的锁请求的数量。 Average Wait Time（ms） （平均等待时间（毫秒）） 线程等待某种类型的锁的平均等待时间。 Lock Requests/sec（锁请求/秒） 每秒钟某种类型的锁请求的数量。

    Memory manager：用于监视总体的服务器内存使用情况，以估计用户活动和资源使用，有助于查明性能瓶颈。监视 SQL Server 实例所使用的内存有助于确定：是否由于缺少可用物理内存存储高速缓存中经常访问的数据而导致瓶颈存在。如果是这样，SQL Server 必须从磁盘检索数据。

    是否可以通过添加更多内存或使更多内存可用于数据高速缓存或 SQL Server 内部结构来提高查询性能。

    Lock blocks：服务器上锁定块的数量，锁是在页、行或者表这样的资源上。不希望看到一个增长的值。

    Total server memory：sql server服务器当前正在使用的动态内存总量。

    监视IIS需要的一些计数器Internet Information Services Global：File Cache Hits %、File CacheFlushes、File Cache Hits File Cache Hits %是全部缓存请求中缓存命中次数所占的比例，反映了IIS 的文件缓存设置的工作情况。对于一个大部分是静态网页组成的网站，该值应该保持在80%左右。而File Cache Hits是文件缓存命中的具体值，File CacheFlushes 是自服务器启动之后文件缓存刷新次数，如果刷新太慢，会浪费内存；如果刷新太快，缓存中的对象会太频繁的丢弃生成，起不到缓存的作用。通过比较File Cache Hits 和File Cache Flushes 可得出缓存命中率对缓存清空率的比率。通过观察它两个的值，可以得到一个适当的刷新值（参考IIS 的设置ObjectTTL 、MemCacheSize 、MaxCacheFileSize）

    Web Service：Bytes Total/sec：显示Web服务器发送和接受的总字节数。低数值表明该IIS正在以较低的速度进行数据传输。

    Connection Refused：数值越低越好。高数值表明网络适配器或处理器存在瓶颈。

    Not Found Errors：显示由于被请求文件无法找到而无法由服务器满足的请求数（HTTP状态代码404）

前言：为什么这里说是细说LoadRunner参数化，在书和网上到处都能找到关于LoadRunner参数化的内容，但是细心的读者不能难发现，虽然现在很多资料都有关于参数化的内容，但写的都不够详细，对于初学者来说是一件很困难的事，而参数化又是编辑脚本最重要的一部分之一，没有学好参数化就不能算是一名合格的性能测试工程师，因此，在这里我将自己理解的关于参数化的内容写出来和初学者共享，希望这份资料对大家学好参数化部分的知识有帮助。

首先：为什么要对脚本进行参数化

a)         为了减少脚本的大小和脚本数量，借助参数化我们可以减少脚本的数量，如果不进行参数化我们为了达到目标可能要拷贝并修改很多个脚本。

b)        使业务更接近其实的客户的业务，每个虚拟用户使用不同参数值来模拟这样才接近客户的实际情况。

第二：怎么进行参数化

首先在这里先声明一下，下面所有使用的例子都是录制LoadRunner中自带的的那个例子的注册过程。

这里包括两部分的部分：

a)         编辑脚本，使用参数代替常量；

b)        设置参数的属性和数据源；

那么如何进行参数化呢？选中要参数化的内容点右键­->Replace with a parameter（如下图）。输入参数化的名称，假设为password。

 

这时要我们要注意的一个问题是，当参数化结束后，脚本保存的根目录下会多出一个参数化的文件，

 

接下来的工作就是将参数化文件合并，这里只有两个参数化文件，合不合并可能不会有多大影响，但是如果当有多个参数化文件并且每个文件都占很大空间时，

图中多出两个参数化的文件（pw和user）就是刚才对两个数进行参数化后的文本文件，当然一般的情况下不要将这个参数化的文件放到脚本的目录下，而应该是放到一个专门的文件下，这样可以保证参数化文件与脚本分离，如我们新建一个文件夹parameter，将所有参数化的文本文件都放到这个文件夹下。

 

这里我们只是两个参数化文件，那么当有很多参数化文件怎么办呢，因为当一个项目很大时，其录制的业务很多时，参数化文件会很多，甚至上几百MB时，这时为了方便管理参数化文件和节约空间我们会对参数化文件进行合并到一个文件夹中，如果上面两个参数化文件就可以合并，参数化之间用逗号隔开即可，如下图合并好后的参数化文件。

 

 

再看一下参数化的属性：

a)        参数类型属性：

1.         "Date/Time"（日期/时间）参数类型：

"Date/Time"类型用当前的日期和/或时间替换参数。要指定日期/时间的格式，可以从菜单列表中选择，或者指定实际需要的格式。该格式应该与脚本中录制的日期/时间格式相对应。还可以单击该对话框中相应的按钮对格式进行添加、删除、还原等操作。

2.         "Group Name"（组名）参数类型：

用Vuser组的名称替换参数。创建方案时，要指定Vuser组的名称，否则运行VuGen的脚本时，组名始终为"无"。但在VuGen中运行时，Group Name将会是None。

3.         "Iteration Number"（迭代编号）参数类型：用当前的迭代编号替换参数。

4.         "Load Generator Name"（负载生成器名）参数类型：用Vuser脚本的负载生成器名替换参数。负载生成器是运行Vuser的计算机。

5.         "Random Number"（随机编号）参数类型：用一个随机生成的整数替换参数，可以通过指定最小和最大值，设置随机编号的范围。

6.         "Unique Number"（唯一编号）参数类型：用一个唯一编号替换参数。"Block size"（块大小）指明分配给每个Vuser的编号块的大小。每个Vuser都从其范围的下限（start）开始，在每次迭代时递增该参数值。

7.         "Vuser ID"参数类型：LoadRunner使用该虚拟用户的ID来代替参数值，该ID是由Controller来控制。在VuGen中运行脚本时，VuGen将会是-1。

8.         File参数类型：可以在参数属性中编辑参数文件，也可以直接编辑好参数文件通过路径来选择，还有从现成的数据库中提取。这是参数化最常的一种参数类型。

b)        Browse属性：

这里是用来选择参数文件的路径，这里要注意的一个问题是，一般我们在做参数化的时候没有单独把参数文件放到一个文件夹下，所以一般我们都没有更改过这块，但我们上面已经讲过，一般都会将参数化文件合并到一个文件下并放到一个专门管理参数的文件夹下，这样我说就要选择参数的路径，否则无法读到参数文件中的参数，具体的如下图。

 

选择好之后，会列出参数化文件中所有的项，如下图：

注意：读者可能会发现，这样如果我们换一个把这个脚本拷贝到另外一台机器上去这个路径不就出错了吗？也就是我们的脚本可移植性不好，对是的，会出错，因为这里写的是绝对路径，如果换到其它的一个盘或机器，运行就报错了，那么怎么解决这个问题？这里我们采用相对路径来解决这个问题，这是我们Browse设置为相对路径，将脚本的根目录使用“。“来代替。见下图，这样就不会出错了。

这样就解决了上面的那个问题，具体更好的可移植性了。

c)         导入数据方法：

LoadRunner允许使用Microsoft Query或者指定数据库连接字符串与SQL语句，利用参数化从已存在的数据库中导入数据。在这里这两种导入数据的方法的区别在于使用Microsoft Query时，不要新建数据源，在导入向导过程中直接连接数据库，而手动指定数据库字符器，需要先做好数据源，现在一般都使用这种方法。

下面我们来看一下使用Data Wizard中的Specify SQL statement manually如何导入数据库中的数据。

首先建立一个数据源，在这里我个做一个数据源，名称为LR，点击Data Wizard按钮，选择使用SQL语句（如下图）。

接下来是选择数据源和写SQL语句（如下图）。

连接成功后，数据将会被成功的导入，下面我们看一下数据库中数据被导入到的情况。

d)        Select next now属性：

注意：这里要注意的是所有的Select next now属性选择是针对虚拟用户来说的，也就是这里的策略是针对Controller设置的，在调试脚本的过程中是看不出来的，其决定虚拟用户如何选择参数的过程。

Ø         Sequential：虚拟用户Vuser按照行顺序的进行读取参数文件中的数据，如果参数文件中没有足够的数据，则返回到第一个值，并一直循环到结束。

例：如上图我们这里有arivn01到arivn07七个数据，假设我们有10个Vuser，那么第1个Vuser读到的参数为arivn01，于此类推，到第8个Vuser的时候，这里表中已经没有数据了，于是又从第一个数据开始读取，故第8个Vuser读到的数据是arivn01，第9个Vuser读到的数据是arivn02。

Ø         Random：每个Vuser从表中随机的读起参数数据，假设有50个数据，那么随机数

将在1～50之间随机取一个，然后把这个数做为行号，去读取相应行的参数数据。

Ø         Unique：唯一的数，即每个Vuser取到的参数均不一致，这里强调了用户的差异性。

Ø         Same link as ＊＊＊：如果一个脚本中定义了多个参数，而有一些参数应该是对应的关系，如上图中的用户名和密码就是对应关系，即密码应该始终和用户名对，这时就要用到这个选项。

e)        Update value on属性：

注意：这里设置的策略是针对脚本的迭代来讲的，也就是说这里的一切策略其仅仅在脚本迭代次数发挥作用，而对Vuser选择参数没有影响。

Ø         Each iteration：脚本每迭代一次都访问数据表中的下一个值。

注意：如果在一次迭代过程中，某个参数使用到两次，如下图这个例子中，在一次迭代中使用到两次用户名和密码，这两次使用的同一个数据，而并不是两个数据。

下面我们来看一下编辑的结果

第一次迭代使用表中数据的结果

 

再看第二次迭代使用表中数据的结果

Ø         Each occurrence：参数在每次迭代的过程中，参数的值都的更新。

注意：如果一个参数在一次迭代过程中出现多次，在同一次迭代过程中也得更新，下面同样看这个例子，其迭代的结果。

Ø         Once：在同一个Vuser中一直取同一个参数，表中的数据不参于迭代的过程。

还是看我们上面的例子的结果：

到这里参数化的过程已经全部讲完，这里总结一下，参数化过程中要注意的问题：

1)        参数化文件尽可能少，因为参数是放在内存中的，占用了内存的资源；

2)        参数化文件与脚本分离；

3)        参数文件的路径应该以相对路径来取；

4)        一些时候为了使参数更具有真实性，参数应该从数据库中来获得；

5)        参数类型的选择；

6)        参数的数据一般要由业务决定；

后记：参数化到这里已经彻底讲完了，主要涉及的内容是：

1)        为什么要进行参数化；

2)        如何进行参数化；

3)        参数化过程中要注意那些问题：

Transactions(用户事务分析)
　　用户事务分析是站在用户角度进行的基础性能分析。

　　1、Transation Sunmmary(事务综述)

　　对事务进行综合分析是性能分析的第一步，通过分析测试时间内用户事务的成功与失败情况，可以直接判断出系统是否运行正常。

　　2、Average Transaciton Response Time(事务平均响应时间)

　　“事务平均响应时间”显示的是测试场景运行期间的每一秒内事务执行所用的平均时间，通过它可以分析测试场景运行期间应用系统的性能走向。

　　例：随着测试时间的变化，系统处理事务的速度开始逐渐变慢，这说明应用系统随着投产时间的变化，整体性能将会有下降的趋势。

　　3、Transactions per Second(每秒通过事务数/TPS)

　　“每秒通过事务数/TPS”显示在场景运行的每一秒钟，每个事务通过、失败以及停止的数量，使考查系统性能的一个重要参数。通过它可以确定系统在任何给定时刻的时间事务负载。分析TPS主要是看曲线的性能走向。

　　将它与平均事务响应时间进行对比，可以分析事务数目对执行时间的影响。

　　例：当压力加大时，点击率/TPS曲线如果变化缓慢或者有平坦的趋势，很有可能是服务器开始出现瓶颈。

　　4、Total Transactions per Second(每秒通过事务总数)

　　“每秒通过事务总数”显示在场景运行时，在每一秒内通过的事务总数、失败的事务总署以及停止的事务总数。

　　5、Transaction Performance Sunmmary(事务性能摘要)

　　“事务性能摘要”显示方案中所有事务的最小、最大和平均执行时间，可以直接判断响应时间是否符合用户的要求。

　　重点关注事务的平均和最大执行时间，如果其范围不在用户可以接受的时间范围内，需要进行原因分析。

　　6、Transaction Response Time Under Load(事务响应时间与负载)

　　“事务响应时间与负载”是“正在运行的虚拟用户”图和“平均响应事务时间”图的组合，通过它可以看出在任一时间点事务响应时间与用户数目的关系，从而掌握系统在用户并发方面的性能数据，为扩展用户系统提供参考。此图可以查看虚拟用户负载对执行时间的总体影响，对分析具有渐变负载的测试场景比较有用。

　　7、Transaction Response Time(Percentile)(事务响应时间(百分比))

　　“事务响应时间(百分比)”是根据测试结果进行分析而得到的综合分析图，也就是工具通过一些统计分析方法间接得到的图表。通过它可以分析在给定事务响应时间范围内能执行的事务百分比。

　　8、Transaction Response Time(Distribution)(事务响应时间(分布))

　　“事务响应时间(分布)”显示在场景运行过程中，事务执行所用时间的分布，通过它可以了解测试过程中不同响应时间的事务数量。如果系统预先定义了相关事务可以接受的最小和最大事务响应时间，则可以使用此图确定服务器性能是否在可以接受的范围内。

　　WebResources(Web资源分析)

　　Web资源分析是从服务器入手对Web服务器的性能分析。

　　1、Hits per Second(每秒点击次数)

　　“每秒点击次数”，即使运行场景过程中虚拟用户每秒向Web服务器提交的HTTP请求数。

　　通过它可以评估虚拟用户产生的负载量，如将其和“平均事务响应时间”图比较，可以查看点击次数对事务性能产生的影响。通过对查看“每秒点击次数”，可以判断系统是否稳定。系统点击率下降通常表明服务器的响应速度在变慢，需进一步分析，发现系统瓶颈所在。

　　2、Throughput(吞吐率)

　　“吞吐率”显示的是场景运行过程中服务器的每秒的吞吐量。其度量单位是字节，表示虚拟用在任何给定的每一秒从服务器获得的数据量。

　　可以依据服务器的吞吐量来评估虚拟用户产生的负载量，以及看出服务器在流量方面的处理能力以及是否存在瓶颈。

　　“吞吐率”图和“点击率”图的区别：

　　“吞吐率”图，是每秒服务器处理的HTTP申请数。

　　“点击率”图，是客户端每秒从服务器获得的总数据量。

　　3、HTTP Status Code Summary(HTTP状态代码概要)

　　“HTTP状态代码概要”显示场景或会话步骤过程中从Web服务器返回的HTTP状态代码数，该图按照代码分组。HTTP状态代码表示HTTP请求的状态。

　　4、HTTP Responses per Second(每秒HTTP响应数)

　　“每秒HTTP响应数”是显示运行场景过程中每秒从Web服务器返回的不同HTTP状态代码的数量，还能返回其它各类状态码的信息，通过分析状态码，可以判断服务器在压力下的运行情况，也可以通过对图中显示的结果进行分组，进而定位生成错误的代码脚本。

　　5、Pages Downloader per Second(每秒下载页面数)

　　“每秒下载页面数”显示场景或会话步骤运行的每一秒内从服务器下载的网页数。使用此图可依据下载的页数来计算Vuser生成的负载量。

　　和吞吐量图一样，每秒下载页面数图标是Vuser在给定的任一秒内从服务器接收到的数据量。但是吞吐量考虑的各个资源极其大小(例，每个GIF文件的大小、每个网页的大小)。而每秒下载页面数只考虑页面数。

　　注：要查看每秒下载页数图，必须在R-T-S那里设置“每秒页面数(仅HTML模式)”。

　　6、Retries per Second(每秒重试次数)

　　“每秒重试次数”显示场景或会话步骤运行的每一秒内服务器尝试的连接次数。

　　在下列情况将重试服务器连接：

　　A、初始连接未经授权

　　B、要求代理服务器身份验证

　　C、服务器关闭了初始连接

　　D、初始连接无法连接到服务器

　　E、服务器最初无法解析负载生成器的IP地址

　　7、Retries Summary(重试次数概要)

　　“重试次数概要”显示场景或会话步骤运行过程中服务器尝试的连接次数，它按照重试原因分组。将此图与每秒重试次数图一起使用可以确定场景或会话步骤运行过程中服务器在哪个时间点进行了重试。

　　8、Connections(连接数)

　　“连接数”显示场景或会话步骤运行过程中每个时间点打开的TCP/IP连接数。

　　借助此图，可以知道何时需要添加其他连接。

　　例：当连接数到达稳定状态而事务响应时间迅速增大时，添加连接可以使性能得到极大提高(事务响应时间将降低)。

　　9、Connections Per Second(每秒连接数)

　　“每秒连接数”显示方案在运行过程中每秒建立的TCP/IP连接数。

　　理想情况下，很多HTTP请求都应该使用同一连接，而不是每个请求都新打开一个连接。通过每秒连接数图可以看出服务器的处理情况，就表明服务器的性能在逐渐下降。

　　10、SSLs Per Second(每秒SSL连接数)

　　“每秒SSL连接数”显示场景或会话步骤运行的每一秒内打开的新的以及重新使用的SSL连接数。当对安全服务器打开TCP/IP连接后，浏览器将打开SSL连接。

 

本文关键字WebPage Breakdown(网页元素细分)
　　“网页元素细分”主要用来评估页面内容是否影响事务的响应时间，通过它可以深入地分析网站上那些下载很慢的图形或中断的连接等有问题的

　　元素。

　　1、Web Page Breakdown(页面分解总图)

　　“页面分解”显示某一具体事务在测试过程的响应情况，进而分析相关的事务运行是否正常。

　　“页面分解”图可以按下面四种方式进行进一步细分：

　　1)、Download Time Breaddown(下载时间细分)

　　“下载时间细分”图显示网页中不同元素的下载时间，同时还可按照下载过程把时间进行分解，用不同的颜色来显示DNS解析时间、建立连接时间、第一次缓冲时间等各自所占比例。

　　2)、Component Breakdown(Over Time)(组件细分(随时间变化))

　　“组件细分”图显示选定网页的页面组件随时间变化的细分图。通过该图可以很容易的看出哪些元素在测试过程中下载时间不稳定。该图特别适用于需要在客户端下载控件较多的页面，通过分析控件的响应时间，很容易就能发现那些控件不稳定或者比较耗时。

　　3)、Download Time Breakdown(Over Time)(下载时间细分(随时间变化))

　　“下载时间细分(随时间变化)” 图显示选定网页的页面元素下载时间细分(随时间变化)情况，它非常清晰地显示了页面各个元素在压力测试过程中的下载情况。

　　“下载时间细分”图显示的是整个测试过程页面元素响应的时间统计分析结果，“下载时间细分(随时间变化)”显示的事场景运行过程中每一秒内页面元素响应时间的统计结果，两者分别从宏观和微观角度来分析页面元素的下载时间。

　　4)、Time to First Buffer Breakdown(Over Time)(第一次缓冲时间细分(随时间变化))

　　“第一次缓冲时间细分(随时间变化)”图显示成功收到从Web服务器返回的第一次缓冲之前的这段时间，场景或会话步骤运行的每一秒中每个网页组件的服务器时间和网络时间(以秒为单位)。可以使用该图确定场景或会话步骤运行期间服务器或网络出现问题的时间。

　　First Buffer Time：是指客户端与服务器端建立连接后，从服务器发送第一个数据包开始计时，数据经过网络传送到客户端，到浏览器接收到第一个缓冲所用的时间。

　　2、Page Component Breakdown(页面组件细分)

　　“页面组件细分”图显示每个网页及其组件的平均下载时间(以秒为单位)。可以根据下载组件所用的平均秒数对图列进行排序，通过它有助于隔离有问题的组件。

　　3、Page Component Breakdown(Over Time)(页面组件分解(随时间变化))

　　“页面组件分解(随时间变化)”图显示在方案运行期间的每一秒内每个网页及其组件的平均响应时间 (以秒为单位)。

　　4、Page Download Time Breakdown(页面下载时间细分)

　　“页面下载时间细分”图显示每个页面组件下载时间的细分，可以根据它确定在网页下载期间事务响应时间缓慢是由网络错误引起还是由服务器错误引起。

　　“页面下载时间细分”图根据DNS解析时间、连接时间、第一次缓冲时间、SSL握手时间、接收时间、FTP验证时间、客户端时间和错误时间来对每个组件的下载过程进行细分。

　　5、Page Download Time Breakdown(Over Time)(页面下载时间细分(随时间变化))

　　“页面下载时间细分(随时间变化)”图显示方案运行期间，每一秒内每个页面组件下载时间的细分。使用此图可以确定网络或服务器在方案执行期间哪一时间点发生了问题。

　　“页面组件细分(随时间变化)”图和“页面下载时间细分(随时间变化)”图通常结合起来进行分析：首先确定有问题的组件，然后分析它们的下载过程，进而定位原因在哪里。

　　6、Time to First Buffer Breakdown(第一次缓冲时间细分)

　　“第一次缓冲时间细分”图显示成功收到从Web服务器返回的第一次缓冲之前的这一段时间内的每个页面组件的相关服务器/网路时间。如果组件的下载时间很长，则可以使用此图确定产生的问题与服务器有关还是与网络有关。

　　网络时间：定义为第一个HTTP请求那一刻开始，直到确认为止所经过的平均时间。

　　服务器时间：定义为从收到初始HTTP请求确认开始，直到成功收到来自Web服务器的一次缓冲为止所经过的平均时间。

　　7、Time to First Buffer Breakdown(Over Time)(第一次缓冲时间细分(随时间变化))

　　“第一次缓冲时间细分(随时间变化)”图显示成功收到从Web服务器返回的第一个缓冲之前的这段时间内，场景运行的每一秒中每个网页组件的服务器时间和网络时间。可以使用此图确定场景运行期间服务器或网络出现问题的时间点。

　　8、Downloader Component Size(KB)(已下载组件大小)

　　“已下载组件大小”图显示每个已经下载的网页组建的大小。通过它可以直接看出哪些组件比较大并需要进一步进行优化以提高性能。

一、Step download timeout (120 seconds)

　　这是一个经常会遇到的问题，解决得办法走以下步骤：

　　1、 修改run time setting中的请求超时时间，增加到600s,其中有三项的参数可以一次都修改了，HTTP-request connect timeout，HTTP-request receieve timeout，Step download timeout，分别建议修改为600、600、5000；run time setting设置完了后记住还需要在control组件的option的run time setting中设置相应的参数；

　　2、 办法一不能解决的情况下，解决办法如下：

　　设置runt time setting中的internet protocol-preferences中的advaced区域有一个winlnet replay instead of sockets选项，选项后再回放就成功了。切记此法只对windows系统起作用，此法来自zee的资料。

　　二、问题描述Connection reset by peer

　　这个问题不多遇见，一般是由于下载的速度慢，导致超时，所以，需要调整一下超时时间。

　　解决办法：Run-time setting窗口中的‘Internet Protocol’－‘Preferences’设置set advanced options（设置高级选项），重新设置一下“HTTP-request connect timeout（sec），可以稍微设大一些”；

　　三、问题描述connection refused

　　这个的错误的原因比较复杂，也可能很简单也可能需要查看好几个地方，解决起来不同的操作系统方式也不同；

　　1、 首先检查是不是连接weblogic服务过大部分被拒绝，需要监控weblogic的连接等待情况，此时需要增加acceptBacklog，每次增加 25%来提高看是否解决，同时还需要增加连接池和调整执行线程数，（连接池数*Statement Cache Size）的值应该小于等于oracle数据库连接数最大值；

　　2、 如果方法一操作后没有变化，此时需要去查看服务器操作系统中是否对连接数做了限制，AIX下可以直接vi文件limits修改其中的连接限制数，还有 tcp连接等待时间间隔大小，wiodows类似，只不过wendows修改注册表，具体修改方法查手册，注册表中有TcpDelayTime项；

　　四、问题描述open many files

　　问题一般都在压力较大的时候出现，由于服务器或者应用中间件本身对于打开的文件数有最大值限制造成，解决办法：

　　1、 修改操作系统的文件数限制，aix下面修改limits下的nofiles限制条件，增大或者设置为没有限制，尽量对涉及到的服务器都作修改；

　　2、 方法一解决不了情况下再去查看应用服务器weblogic的commonEnv.sh文件，修改其中的nofiles文件max-nofiles数增大，应该就可以通过了，具体就是查找到nofiles方法，修改其中else条件的执行体，把文件打开数调大；修改前记住备份此文件，防止修改出错；

　　五、问题描述has shut down the connection prematurely

　　一般是在访问应用服务器时出现，大用户量和小用户量均会出现；

　　来自网上的解释：

　　1> 应用访问死掉

　　小用户时：程序上的问题。程序上存在数据库的问题

　　2> 应用服务没有死

　　应用服务参数设置问题

　　例如：

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

　　Java连接池的大小设置，或JVM的设置等

　　3> 数据库的连接

　　在应用服务的性能参数可能太小了

　　数据库启动的最大连接数（跟硬件的内存有关）

　　以上信息有一定的参考价值，实际情况可以参考此类调试。

　　如果是以上所说的小用户时：程序上的问题。程序上存在数据库的问题，那就必须采用更加专业的工具来抓取出现问题的程序，主要是程序中执行效率很低的sql语句，weblogic可以采用introscope定位，期间可以注意观察一下jvm的垃圾回收情况看是否正常，我在实践中并发500用户和600用户时曾出现过jvm锯齿型的变化，上升下降都很快，这应该是不太正常的；

　　六、问题描述Failed to connect to server

　　这个问题一般是客户端链接到服务失败，原因有两个客户端连接限制（也就是压力负载机器），一个网络延迟严重，解决办法：

　　1、 修改负载机器的tcpdelaytime注册表键值，改小；

　　2、 检查网络延迟情况，看问题出在什么环节；

　　建议为了减少这种情况，办法一最好测试前就完成了，保证干净的网络环境，每个负载机器的压力测试用户数不易过大，尽量平均每台负载器的用户数，这样以上问题出现的概率就很小了。

分析原则：