在压力测试时经常碰到LOADNRUNNER的controller会报120秒超时，如果想让测试成功率大些，不会一直报120秒超时错误信息，可以适当修改LR 的配置参数，让超时时间大于120秒，只是这个是治标不治本的方法毕竟性能问题还是存在。

Step download timeout(sec)设置。

  timeout分了connect,receive以及download三个部分，默认都是120秒，但是经常我们要设置的更大一些，具体设置方法：Vugen--》Vuser---》Runtime-settings----》Preferences------》option，将Step download timeout(sec)默认值120s改为自己需要的值，其次要改变HTTP-reguest connnect timeout（sec）和HTTP-reguest receive timeout（sec）也为相应的值。

 

 

或者在脚本中加入 web_set_timeout 函数也可以。

  具体怎么定为 120秒超时问题主要看各个服务器 性能问题或者网络连接问题

在使用LR压力测试过程中如果出现120秒超时如何定位问题？

一般在压力测试时经常120秒超时，正常情况下可以说明性能问题了
问题一：看是数据库问题？那就看是否出现死锁 等待现象，数据库资源使用率怎么样例如CPU使用率
'w[1]P5B KQP'rmr9_m72464问题二：看应用问题 参数设置大小导致的？页面图片太大？ 程序死循环或者处理表的时候检查字段过大过多？内存溢出问题？

问题三：网络问题，正常情况下测试都是局域网的这种问题比较少出现！

问题四：中间件的参数调整问题了，线程数 数据库连接池等太大太小都会引起这个问题

1. 平均事务响应时间

　　Average Transation Response Time 优秀：<2s

　　良好：2-5s

　　及格：6-10s

　　不及格：>10s

　　2. 每秒点击率

　　Hits per Second

　　当增大系统的压力(或增加并发用户数)时，吞吐率和TPS的变化曲线呈大体一致，则系统基本稳定若压力增大时，吞吐率的曲线增加到一定程度后出现变化缓慢，甚至平坦，很可能是网络出现带宽瓶颈.同理若点击率/TPS曲线出现变化缓慢或者平坦,说明服务器开始出现.

　　3. 请求响应时间

　　Time to Last Byte

　　4. 每秒系统处理事务数

　　Transaction per second

　　5. 吞吐量

　　Throughout

　　6. CPU利用率

　　Processor / %Processor Time 好：70%

　　坏：85%

　　很差：90%+

　　7. 数据库操作消耗的CPU时间

　　Processor / %User Time 如果该值较大，可以考虑是否能通过友好算法等方法降低这个值。如果该服务器是数据库服务器， Processor\%User Time 值大的原因很可能是数据库的排序或是函数操作消耗了过多的CPU时间，此时可以考虑对数据库系统进行优化。

　　8. 核心态CPU平均利用率

　　Processor /%Privileged Time 如果该参数值和"Physical Disk"参数值一直很高，表明I/O有问题。可考虑更换更快的硬盘系统

　　9. 处理列队中的线程数

　　Processor / Processor Queue Length 如果该值保持不变(>=2)个并且%Processor Time 超过90%，那么可能存在处理器瓶颈。如果发现超过2，而处理器的利用率却一直很低，那么或许更应该去解决处理器阻塞问题，这里处理器一般不是瓶颈。

　　10. 文件系统缓存

　　Memory / Cache Bytes 50%的可用物理内存

　　11. 剩余的可用内存

　　Memory / Avaiable Mbytes 至少要有10% 的物理内存值

　　本文出自51Testing软件测试网，感谢会员fmsbai5在每周一问(08-12-29)中的精彩回答。http://bbs.51testing.com/forum-157-1.html

　　12. 每秒下载页数

　　Memory / pages/sec 好：无页交换

　　坏：CPU每秒10个页交换

　　很差：更多的页交换

　　13. 页面读取操作速率

　　Memory / page read/sec 如果页面读取操作速率很低，同时 % Disk Time 和 Avg.Disk Queue Length的值很高，则可能有磁盘瓶径。但是，如果队列长度增加的同时页面读取速率并未降低，则内存不足。

　　14. 物理磁盘利用率

　　Physical Disk / %Disk Time 好：<30%

　　坏：<40%

　　很差：<50%+

　　15. 物理磁盘平均磁盘I/O队列长度

　　Physical Disk / Avg.Disk Queue Length 该值应不超过磁盘数的1.5~2 倍。要提高性能，可增加磁盘

　　16. 网络吞吐量

　　Network Interface / Bytes Total/sec 判断网络连接速度是否是瓶颈，可以用该计数器的值和目前网络的带宽，结果应该小于50%

　　17. 数据高速缓存区命中率 命中率应大于0.90最好

　　18. 共享区库缓存区命中率 命中率应大于0.99

　　19. 监控 SGA 中字典缓冲区的命中率 命中率应大于0.85

　　20. 检测回滚段的争用 小于1%

　　21. 监控 SGA 中重做日志缓存区的命中率

　　应该小于1%

　　22. 监控内存和硬盘的排序比率 最好使它小于 10%

一直在找指标分析，但是一直很难找到好的，今天在论坛上看到，就先收藏下来

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

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: 被处理器消耗的处理器时间数量。如果服务器专用于sqlserver,可接受的最大上限是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® 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® 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）

重贴

监视内存计数器

要监视内存不足的状况，请从以下的对象计数器开始：

内存信息：

Memory\ Available Bytes

Memory\ Pages/sec

Memory\ Available Bytes

如果您怀疑有内存泄露，请监视 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。

CPU信息：

Processor\ % Processor Time 获得处理器使用情况。

也可以选择监视 Processor\ % User Time 和 % Privileged Time 以获得详细信息。

Server Work Queues\ Queue Length 计数器会显示出处理器瓶颈。队列长度持续大于 4 则表示可能出现处理器拥塞。

System\ Processor Queue Length 用于瓶颈检测

通过使用 Process\ % Processor Time 和 Process\ Working Set

Process\ % Processor Time过程的所有线程在每个处理器上的处理器时间总和。

硬盘信息：

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\ % Disk Time

Physical Disk\ Avg.Disk Queue Length

例如，包括 Page Reads/sec 和 % Disk Time 及 Avg.Disk Queue Length。如果页面读取操作速率很低，同时 % Disk Time 和 Avg.Disk Queue Length的值很高，则可能有磁盘瓶径。但是，如果队列长度增加的同时页面读取速率并未降低，则内存不足。

请观察 Processor\ Interrupts/sec 计数器的值，该计数器测量来自输入/输出 (I/O) 设备的服务请求的速度。如果此计数器的值明显增加，而系统活动没有相应增加，则表明存在硬件问题。

Physical Disk\ Disk Reads/sec and Disk Writes/sec

Physical Disk\ Current Disk Queue Length

Physical Disk\ % Disk Time

LogicalDisk\ % Free Space

测试磁盘性能时，将性能数据记录到另一个磁盘或计算机，以便这些数据不会干扰您正在测试的磁盘。

可能需要观察的附加计数器包括 Physical Disk\ Avg.Disk sec/Transfer、Avg.Disk Bytes/Transfer，和 Disk Bytes/sec。

Avg.Disk sec/Transfer 计数器反映磁盘完成请求所用的时间。较高的值表明磁盘控制器由于失败而不断重试该磁盘。这些故障会增加平均磁盘传送时间。对于大多数磁盘，较高的磁盘平均传送时间是大于 0.3 秒。

也可以查看 Avg.Disk Bytes/Transfer 的值。值大于 20 KB 表示该磁盘驱动器通常运行良好；如果应用程序正在访问磁盘，则会产生较低的值。例如，随机访问磁盘的应用程序会增加平均 Disk sec/Transfer 时间，因为随机传送需要增加搜索时间。

Disk Bytes/sec 提供磁盘系统的吞吐率。

决定工作负载的平衡

要平衡网络服务器上的负载，需要了解服务器磁盘驱动器的繁忙程度。使用 Physical Disk\ % Disk Time 计数器，该计数器显示驱动器活动时间的百分比。如果 % Disk Time 较高（超过 90%），请检查 Physical Disk\ Current Disk Queue Length 计数器以查看正在等待磁盘访问的系统请求数量。等待 I/O 请求的数量应当保持在不大于组成物理磁盘的主轴数的 1.5 到 2 倍。

尽管廉价磁盘冗余阵列 (RAID) 设备通常有多个主轴，大多数磁盘有一个主轴。硬件 RAID 设备在“系统监视器”中显示为一个物理磁盘；通过软件创建的 RAID 设备显示为多个驱动器（实例）。可以监视每个物理驱动器（而不是 RAID）的 Physical Disk 计数器，也可以使用 _Total 实例来监视所有计算机驱动器的数据。

使用 Current Disk Queue Length 和 % Disk Time 计数器来检测磁盘子系统的瓶颈。如果 Current Disk Queue Length 和 % Disk Time 的值始终较高，可以考虑升级磁盘驱动器或将某些文件移动到其他磁盘或服务器。

实现LoadRunner多个场景的顺序执行
注：以下内容部分总结自51testing论坛。

应用场景
假设有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...等用户数递增的测试，也可以用以上方法实现，但需要注意的是将事务名称区分开以便进行分析。

 

 

 

*************************************分隔线*****************************

批量执行场景：

@echo off

echo =====================================

echo 批量执行场景...

echo =====================================

SET M_ROOT="C:\Program Files\Mercury LoadRunner\bin\"

%M_ROOT%\wlrun.exe -TestPath "D:\Fin\scenario\Scen_1.lrs" -Run

echo Scen_1执行完毕

%M_ROOT%\wlrun.exe -TestPath "D:\Fin\scenario\Scen_2.lrs" -Run

echo Scen_2执行完毕

%M_ROOT%\wlrun.exe -TestPath "D:\Fin\scenario\Scen_3.lrs" -Run

echo Scen_3执行完毕

%M_ROOT%\wlrun.exe -TestPath "D:\Fin\scenario\Scen_4.lrs" -Run

echo Scen_4执行完毕

echo. & pause

批量执行脚本：（说明，有些时候我们需要把LR 当作 功能测试使用，但是又能做到QTP所做不到的东西，例如协议验证测试中，我们通过LR脱离客户端，直接向后端服务器发送报文这时需要用到脚本1中的结果保存成文件给脚本2做数据执行。LR 只是一个工具，并非只能做功能测试。因为他的是真实的向目标服务器进行交互。）

@echo off

echo =====================================

echo XX项目自动化脚本执行开始...

echo =====================================

echo 读取Data文件...

echo 传送文件中...

copy .\Data\login.txt .\PGCreateGroup_ex\login.dat

copy .\Data\Apply.txt .\PGApplyGroup_ex\login.dat

copy .\Data\ipport.txt .\PGApplyGroup_ex\ipport.dat

copy .\Data\ipport.txt .\PGSetMemberPermission\ipport.dat

copy .\Data\ipport.txt .\PGCreateGroup_ex\ipport.dat

echo 传送完毕...

SET M_ROOT="C:\Program Files\Mercury\LoadRunner\bin"

%M_ROOT%\vugen.exe -TestPath ".\PGCreateGroup_ex\PGCreateGroup_ex.usr" -RUN

echo 传送文件中...

copy .\PGCreateGroup_ex\login.dat .\PGSetMemberPermission\login.dat

echo 传送完毕...

%M_ROOT%\vugen.exe -TestPath ".\PGApplyGroup_ex\PGApplyGroup_ex.usr" -RUN

echo 传送文件中...

copy .\PGApplyGroup_ex\AddGroup.dat .\PGSetMemberPermission\AddGroup.dat

copy .\PGApplyGroup_ex\login.dat .\PGSetMemberPermission\MemSip.dat

echo 传送完毕...

%M_ROOT%\vugen.exe -TestPath ".\PGSetMemberPermission\PGSetMemberPermission.usr" -RUN

echo 执行完毕...

echo copyright in 02-24-2009 , Fin.

echo. & pause

曾经用过的两种用用法，另外配上有一个兄弟发的自己做的定时执行批处理文件工具，就更完美了。技术共享。。。

 

 

作者: redforce    来源: redforce的博客

　　分析原则：

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

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

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

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

　　分段排除法 很有效

　　分析的信息来源：

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

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

　　一．错误提示分析

　　分析实例：

　　1）Error: Failed to connect to server “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、数据库的连接

　　(1、在应用服务的性能参数可能太小了 2、数据库启动的最大连接数（跟硬件的内存有关）)

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

　　分析：可能是以下原因造成

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

　　B、页面中图片太多

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

　　二．监控指标数据分析

　　1．最大并发用户数：

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

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

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

　　2．业务操作响应时间：

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

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

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

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

　　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的大小。

　　2）如果数据的缓存命中率小于0.90，那么需要加大DB_BLOCK_BUFFERS参数的值（单位：块）。

　　3）如果日志缓冲区申请的值较大，则应加大LOG_BUFFER参数的值。

　　4）如果内存排序命中率小于0.95，则应加大SORT_AREA_SIZE以避免磁盘排序 。

 

怎么开场呢？我就不说这个问题“很傻很天真”了，这就好比“渔夫要捞鱼，如何选择合适的网眼”、“程序员要写代码，如何选择系统头文件”一样，提出这样的问题充分暴露出一种浮躁盲目的情绪：