51Testing软件测试论坛

标题: 如何使用Loadrunner进行资源占用率的分析？（08-12-29）（获奖名单已公布） [打印本页]

作者: 默默巫 时间: 2008-12-29 17:01
标题: 如何使用Loadrunner进行资源占用率的分析？（08-12-29）（获奖名单已公布）
Loadrunner作为业界最流行的性能测试工具，应用已经十分广泛。Loadrunner如何分析性能数据，这个是每一个做性能测试人员都非常关心的话题．
但此话题受具体业务和环境的影响不太好回答，所以缩小一下范围．如何使用Loadrunner进行资源占用率（CPU，内存，硬盘）的分析？

感谢会员wichingh提供此精彩问题！如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！

获奖名单
奖项	获奖名单	奖励	答案链接
一等奖	archonwang	当当购物卡50元	5#
二等奖	fmsbai5	300论坛积分	15#
三等奖	angelna	100论坛积分	23#

作者: wssgily 时间: 2008-12-29 17:46
这个问题有难度啊。

作者: yetties2005 时间: 2008-12-29 17:58
个人觉得CPU、内存、硬盘这些数据单单的去看可能看不出什么。要放在一起才好分析出问题。例如把这些数据还有相关的加压数。吞吐量,每秒点击率，等都放在一起看。看在什么样的情况下哪个指标过高或是出现异常,

作者: weifei1031 时间: 2008-12-30 11:03
占位

作者: archonwang 时间: 2008-12-30 13:46
情况比较复杂，有兴趣的话可以就这个问题写本很厚的书。

1. 系统分类
1.1. windows
1.2. unix/linux
2. 核心分类
1.1. 单核CPU
1.2. 多核CPU
3. 应用分类
3.1. JAVA应用
3.2. DotNet应用
3.3. 其他应用
4. 磁盘分类
5. 平台分类
5.1. 中间件平台
5.2. 数据库平台
5.3. 其他中间件平台
6. 综合以上这些内容分析，相信会有很多排列组合。由于参数组合及应用的复杂性，说性能的高低标准实在很难一概而论。只能就事论事，依照情况分析。

之前有过一些分析的帖子和博文，一概拿来主义，分享下（感谢那些曾经整理过并拿来分享的兄弟姐妹）。

原帖请看：《LoadRunner监视的性能计数器》51testing上有。

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

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

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

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

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

%Privileged Time：（CPU内核时间）是在特权模式下处理线程执行代码所花时间的百分比。如果该参数值和"

hysical 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 :为发送和接收字节的速率，包括帧字符在内。判断网络连接速度是否是瓶颈，可以用该计数器的值和目前网络的带宽比较

[ 本帖最后由 archonwang 于 2008-12-30 13:48 编辑 ]

作者: 佐伊 时间: 2008-12-31 10:46
楼上的同学每次回答都很认真啊．

作者: trtdsoft 时间: 2008-12-31 16:52
标题: 综合考虑为佳.
对呀,我也觉得应该综合考虑...不然,实在是不容易呀..哈哈..

作者: m_r3326 时间: 2008-12-31 16:55
斑竹出售果然不同凡响

作者: creatysun 时间: 2009-1-4 10:49
5楼的说的很全面，想请教一下，用loadrunner监控 linux的话，只有statd里的一些计数器，可能对分析问题还不够，有没有更好的方法监控更多的计数器。

作者: 郁闷的我 时间: 2009-1-4 15:02
并发性能测试的测试内容如下:

一、负载压力测试。模拟不同数量用户并发执行关键业务，测试系统能够承受的最大并发用户数。

二、系统资源监控。进行负载压力测试的同时，使用测试工具监控数据库服务器、应用服务器以及中间件服务的资源占用情况。观察不同压力下，各服务器资源占用变化曲线，找出系统的性能瓶颈。

性能测试中除需要选择正确的性能测试点和测试策略外，测试环境也是关系性能测试能否成功的关键因素。

通常，性能测试需要在测试环境中进行，所以要求测试环境尽量同生产环境保持一致．
在建立好测试环境后，接下来就要准备测试案例。测试案例的选取有三点:第一、根据系统实际的用户数量制定并发用户;第二、根据系统的关键业务流程点;第三、根据系统在某个时段可能产生最大的并发量。

根据以上几点方法，测试人员与开发人员进行充分沟通后，分析可能出现的压力、设计出单项并发测试案例和疲劳测试案例。

作者: lovetesting52 时间: 2009-1-5 11:01
羡慕懂性能测试的同行，继续努力，向你们学习哦！

作者: 投缘 时间: 2009-1-5 13:27
以我目前的水平还是先不要误人子弟了，先顶下5楼的！！

作者: 咚咚宝031102 时间: 2009-1-5 15:29
我赞同综合考虑
谢谢楼主

作者: hutter2006 时间: 2009-1-5 16:39
12楼的讲话比较到位！
顶一个

作者: fmsbai5 时间: 2009-1-5 18:11
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% 的物理内存值
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%

作者: leaveall 时间: 2009-1-6 16:01
标题: 恩,这个问题很深,要考虑的问题很多.
刚开始还在监控器里面添加一些记数器的,后来发现加了自己也看不明白就不加了.

,我想请教一个问题LR里面带宽的选择基本上可以模拟你所在的测试环境么?外网就用速度低的.内部就用速度高的,仅次而已?

作者: namisang 时间: 2009-1-6 16:02

原帖由 leaveall 于 2009-1-6 16:01 发表
刚开始还在监控器里面添加一些记数器的,后来发现加了自己也看不明白就不加了.
,我想请教一个问题LR里面带宽的选择基本上可以模拟你所在的测试环境么?外网就用速度低的.内部就用速度高的,仅次而已?

问题中又见问题呀

作者: jian12278 时间: 2009-1-6 19:10
占位，上来学习下

作者: archonwang 时间: 2009-1-7 09:29
标题: 回复 16# 的帖子
关于带宽限制，我们一般都会考虑服务器的可供应带宽来考量。如果说需要测试客户端压力也可以使用该选项。

作者: jmtest 时间: 2009-1-7 22:15
来学习一下，刚刚接触

作者: jmtest 时间: 2009-1-7 22:17
来学习一下，刚刚接触

作者: saran 时间: 2009-1-8 10:15
观众

作者: angelna 时间: 2009-1-8 14:38
对象 :System

度量 : %Total Processor Time

描述 :
系统上所有处理器都忙于执行非空闲线程的平
均时间的百分比。在多处理器系统上，如果所
有处理器始终繁忙，此值为 100%，如果所有
处理器为 50% 繁忙，此值为 50%，而如果这
些处理器中的四分之一是 100% 繁忙的，则
此值为 25%。它反映了用于有用作业上的时
间的比率。每个处理器将分配给空闲进程中的
一个空闲线程，它将消耗所有其他线程不使用
的那些非生产性处理器周期
度量:
File Data Operations/sec
描述:
计算机对文件系统设备执行读取和写入操作的
速率。这不包括文件控制操作
度量

rocessor Queue Length
描述:
线程单元中的处理器队列的即时长度。如果您
不同时监视线程计数，则此计数始终为 0。所
有处理器都使用单一队列（线程在该队列中
等待处理器进行循环）。此长度不包括当前正
在执行的线程。一般情况下，如果处理器队列
的长度一直超过二，则可能表示处理器堵塞。
此值为即时计数，不是一段时间的平均值
对象

rocessor
度量:%Processor Time
描述:
处理器执行非空闲线程的时间百分比。此计数
器为反映处理器活动的一个主要指示器。它是
通过度量处理器在每个采样间隔中执行空闲进
程的线程所花费的时间比率，然后从 100%
中减去此值来计算的。（每个处理器都有一个
空闲线程，它在没有其他线程准备运行时消耗
处理器周期。）它可以反映有用作业占用的采
样间隔的百分比。该计数器显示在采样期间所
观察到的繁忙时间的平均百分比。它是通过监
视服务处于非活动状态的时间，然后从 100%
中减去此值来计算的

内存,磁盘占用空间,进程,线程,文件系统,时间比等来进行综合度量

作者: lanbiers 时间: 2009-1-9 17:56
那些通过网络来进行日常交易的业务需要为客户提供尽可能好的用户使用体验，这样才能确保业务的成功。然而，这些业务往往会因为他们的网站无法处理峰值时期的网络流量而失去许多客户。

本文就“维护网络应用性能是战胜这些电子商务挑战并创造更多收入的关键”这一观点进行了阐述，讨论了维护网络应用对于保证客户满意度的重要性，以及负载测试对于网站成功启动和管理具有重要意义的原因。另外，本文还调查了不同类型的负载测试，详细讨论了负载测试流程和可靠测试工具所应具有的特性。最后，本文对全球BTO领导者（Mercury）公司的负载测试解决方案——LoadRunner作了总体介绍。

电子商务发展迅速

在过去几年中，电子商务的发展速度令人震惊。分析家估计，现在有8亿人使用网络——并且没有任何放慢速度的迹象。事实上，国际数据公司（IDC，International Data Corporation）预测，网络用户的数量将在未来几年中超过10亿。

电子商务成为流行商业媒介的原因有2个：其一，它使业务能够分享全世界的信息和资源；其二，它为广告、市场推广和销售提供了一个有效渠道。网络有助于提高销售量、扩大市场推广范围、提高客户服务质量，并能在企业内外高效完成业务。

随着网络客户数量的增长，销售商之间的竞争变得日益激烈，人们正在意识到这样一个事实：为客户提供良好的最终用户体验，这是非常重要的，也非常具有挑战性，但同时也将是高回报的。

保证最优的最终用户体验——一个复杂问题

电子商务的运行是非常复杂的。根据不同的商务交易类型，商业网站可以被划分为四大类：出版/订户网站、在线购物网站、客户自助网站和贸易拍卖网站。

无论是哪种交易类型，网站必须能够让客户及时完成业务。因此，拥有一个可扩展的架构是必须的。

然而，一个良好的网络环境包含着一个非常复杂的多层次系统，如果要端到端地扩展这个基础架构，就必须管理每一层中的每个组件的性能和容量。图1说明了这些组件的复杂性。

这一复杂性引起了关于网站完整性和性能容量方面的许多问题，例如用户所经历的响应时间是否小于2秒？该网站是否能支撑一定数量的用户？当系统中的所有组件被连接到一起时，是否能协同共存？应用服务器和数据库服务器间的信息传送速度是否足够快？每一层上是否有足够的硬件来处理高访问量？客户是否在广域网获得了最优的质量体验？

为了解决这些性能问题，业务必须实施一种方法，这种方法能在部署前预测到web应用在生产环境中的行为。

上线前的应用负载测试

为了适应网站的发展，web开发人员们往往会优化软件或者在每个系统组件上增加硬件。然而，这种随意改进性能的方法并不理想，往往会导致无节制的硬件购买，成功也没有一点保障。为了真正确保最优性能，必须在上线前对所有系统组成部分进行负载测试。

应用负载测试就是对整个网络应用能力进行衡量，使其能支持众多并发用户和交易，并保证适当的响应时间。由于此类测试涉及面广，因此负载测试是唯一一种能够在上线前精确测试网站端到端性能的方法。

应用负载测试能帮助开发人员隔离任何基础架构组件的瓶颈问题。通常，实施这一流程有两种方法：手动测试和自动化测试。手动测试面临几个内在挑战，例如决定如何来模拟应用中相互作用的成千上万个用户的行为和负载，如何协调用户操作，如何衡量响应时间，如何保持重复测试方法的一致性以及如何比较测试结果等。

由于负载测试具有不断反复的特性，用户必须识别性能问题，调整系统，然后重复测试，这样才能确保该调整所产生的影响是有利的。由于需要不断重复测试，手动测试显然不是一个实用的选择。

有了自动化测试工具后，重复进行测试就变得轻而易举，测量结果也能自动得到。与手动测试相比，这种方法所采用的自动测试工具能提供一个更具有成本效率的有效解决方案，并且它还降低了测试过程中产生人为错误的风险。

现在，自动负载测试是网络应用负载测试的首选。包括LoadRunner在内的自动化工具通常采用三大组件来执行一个测试，它们包括：负责组织、驱动并管理负载的控制面板；流程中用来模拟真实用户在客户端应用上执行业务流程行为的虚拟用户；用于运行虚拟用户的负载服务器。

有了这些组件后，自动负载测试工具就能用自动化虚拟客户来替代手动测试人员，在单个负载生成器上同时运行多个虚拟用户，自动衡量交易响应时间，便捷地重复负载场景，验证性能设计的变更内容，这一先进的功能将帮您节省时间和昂贵的资源。

最近，Newport Group的一份报告证明了诸如LoadRunner等自动化测试工具的价值。该报告显示，一半以上的网络业务无法达到它们预想的扩展目标。这其中的大多数未使用任何类型的自动负载测试工具。相反，那些能够达到扩展预期效果的业务几乎都使用了自动负载测试工具。

自动化负载测试工具面临的挑战

随着技术的不断发展，自动化负载测试工具也面临着诸多挑战。这些挑战主要包括：精确性、可扩展性以及隔离性能问题的能力。为了隔离性能问题，负载测试工具要监控主要系统水平组件，并在运行负载测试时识别出瓶颈问题。精确性被定义为一个自动化工具模拟真实用户行为的程度；可扩展性则与产品使用最少资源产生最大负载相关。使用LoadRunner工具，可以很好的解决精确性与可扩展性问题。

自动化负载测试的流程

采用严格的方法进行负载测试，用户可以实现资源的优化；更好地预测到硬件、软件和网络需求；建立性能预期目标来满足最终用户服务水平协议(SLAs)。而为了验证变化是否已经生效，就必须重复进行测试。

在下一篇文章中，我们将以LoadRunner工具为例，详细介绍使用先进测试工具进行自动化负载测试的主要步骤和流程。

ＬｏａｄＲｕｎｎｅｒ

LoadRunner是业界最为先进的负载测试工具之一，它能预测系统行为和性能。通过模拟任意数量的用户（从一个到上万个），它能测试整个企业基础架构，识别并隔离问题。由于能够支持多种环境，LoadRunner能测试整个企业基础架构和应用，其中包括电子商务、ERP、CRM和定制客户/服务器应用，帮助IT和网络群组优化应用性能。通过模拟真实用户行为，LoadRunner能测试如HTTP(s), COM, CORBA, oracle Applications等各种协议的应用传送。同时，LoadRunner能与Mercury Business Availability Center（业务可用性中心）完美整合。

因此，应用部署完毕后，测试中创建的测试能被重新用来监控应用。LoadRunner改进了负载测试流程中的每一步骤，确保用户取得最大的投资回报。

总之，对于网络业务和实体业务来说，电子商务这种业务模式被证明是可行。网络用户数量正以几何倍数级的速度增长，因此，这些业务必须做好准备，保证他们的系统能够支持高用户数量。现在，业务可采用负载测试方案和工具来保证他们的网络应用性能满足最终用户的需求。

LoadRunner是预测电子商务应用的可扩展性、可靠性和性能问题的领先工具，能够识别系统瓶颈问题，并显示测试结果。LoadRunner可以产生不同数量的用户来模拟各种交易。对于规划业务成长，降低业务风险，了解应用极限，这是非常必要的。LoadRunner也能实时测试系统行为，并把这一数据转换成使用方便但数据详细的图表和报告。有了这些信息，问题就能被更快更有效地解决，从而保证了良好的最终用户体验，创造了增加收入的机会。在下篇文章中，我们将进一步讨论LoadRunner是如何为负载测试流程中的每个阶段提供支持的。

使用（Mercury）LoadRunner自动化负载测试工具，我们能采用严格的方法进行负载测试，实现资源的优化；能更好地预测到硬件、软件和网络需求；能够建立性能预期目标来满足最终用户服务水平协议(SLAs)。

通过自动化工具实现负载测试自动化一般有以下七个步骤：

第一步：系统分析

系统分析对于诠释用户的测试需求来说是至关重要的。可以此来判断系统是否将按照预期目标扩展和运行。

使用LoadRunner可进行同样的系统分析。模拟测试环境时，识别所有测试条件，其中包括系统架构组件、测试流程以及测试的虚拟用户总量。一个良好的系统分析能够帮助客户把他们的目标和要求转换成一个成功的自动测试场景。

第二步：创建虚拟用户脚本

首先，用户要记录业务流程，创建测试脚本。脚本记录可由LoadRunner的虚拟用户产生器（Virtual User Generator (VUGen)）来完成。VUGen是运行在客户桌面上的一个组件，它能捕获真实客户的应用与服务器之间的信息传送。通过发送各种电子商务协议请求，VUGen能模拟真实浏览者的确切行为。VUGen也能记录使用Netscape或Internet Explorer浏览器的用户，或者任何能够指定代理服务器地址的规定客户。完成记录流程后，测试脚本也就产生了。

然后，用户就能在脚本中增加逻辑关系，使之变得更加符合现实。用户还可以在脚本中加入智能，这样,它们在执行交易时就能模拟虚拟用户进行推理论证。在这个阶段的执行过程中，LoadRunner使用到了交易、检验和参数化三项特性。

·交易：交易是指一系列需要在一定负载条件下测试的操作。

·检验：VUGen允许插入内容检查（Content Check）复核点进行检验，通过对返回HTML网页的分析，检验应用功能。如果检验失败，LoadRunner会记录错误并提示失败的原因,例如连接断线、图片丢失、错误文本等。

·参数化：为了精确模拟真实用户行为，LoadRunner的虚拟用户在负载测试中使用不同的数据，把脚本中的常量替代为变量或参数。虚拟用户可以从文本文件、随机数字发生器、时钟等数据源取得的值来替代参数。

第三步：定义用户行为

LoadRunner提供综合运行时间设定值来配置那些模拟真实用户的脚本，运行时间设定值包括：

·思考时间：控制虚拟用户作用系统的速度，其中包括测试期间的思考暂停时间。通过不同的用户思考时间，LoadRunner 能够模仿从新手到熟练用户不同用户的行为。

·拨号速度：模拟用户使用调制解调器或LAN/WAN连接到系统。这有助于控制用户行为，精确模拟每个请求的响应时间。调制解调器的速度从14.4 Kbps到56.6 Kbps不等。

·模拟高速缓存：模拟具有一定高速缓存用户的浏览。也可根据服务器要求关闭高速缓存。

·浏览器模拟：帮您确定虚拟用户所模拟的浏览器。LoadRunner 同时支持Netscape、Internet Explorer以及任何定制型的浏览器。

·连接数量：像真实浏览器一样，可以让虚拟用户在下载网页内容时控制连接到服务器的连接数量。

·IP地址分配：在同一个物理机器上分配虚拟用户的IP地址，测试IP相关组件的性能影响。

·迭代测试：命令重复运行虚拟用户脚本，协调虚拟用户，通知间隔间的等待时间。根据使用不同数据执行流程的次数，迭代测试定义了用户的工作量。

·错误处理：规定虚拟用户在执行脚本时的错误处理方法。当虚拟用户在重新执行过程中碰到错误时，LoadRunner 能激活Continue on Error。

·日志文件：储存虚拟用户服务器传送信息。标准日志能图示所有交易、集结和输出信息，扩展日志记录也会跟踪警报和其他信息。

第四步：创建负载测试场景

用户可以使用LoadRunner的控制器来创建场景。作为一个控制中心，它提供了完整的测试和虚拟用户信息。

控制器可让您实现以下操作，使负载测试场景的创建变得更加容易：

·向各个群组分配脚本。

·定义运行测试所需的虚拟用户数量。

·定义运行虚拟用户的主机。

另外，LoadRunner为测试人员提供了ScenarioWizard、调度器（Scheduler）和TurboLoad。LoadRunner的Scenario Wizard能帮助测试人员迅速创建多用户负载测试方案。

Scenario Wizard:通过五个步骤，Scenario Wizard帮用户选择运行虚拟用户和测试脚本的工作站。通过这一流程，也可以创建虚拟用户的模拟群组。

调度器（Scheduler）: LoadRunner 的调度器用于改变准备状态和运行状态下的虚拟用户数量。该调度器也能管理时间计划，并带有一个自动化流程，可以在用户离开时运行脚本。

CPU消耗最小化：这一技术能提供最大的扩展性。 LoadRunner能最小化每个虚拟用户的CPU消耗，因此可以让每一台负载生成器上运行更多的用户。最新客户基准中使用了10个Windows负载服务器，LoadRunner每天在网络系统上产生三十多亿次点击（或每台机器3,700次点击/每秒），而负载生成器的运行只占用不到40%的CPU。

第五步：创建网络影响测试

LoadRunner能够进行WAN模拟，因此，前几步中使用到的虚拟用户脚本还可用于网络影响测试，并为运行在同一个测试中的并存虚拟用户群组改进诸如连接速度、等待时间和错误率等网络特性。然后，用户就能精确确定不同群组的响应时间所产生的网络影响，以及应用对网络的敏感性。此外，它还可以记录预期响应时间数据和网络要求，在应用部署完毕后，系统会用到这些信息。

第六步：运行负载测试方案，监控性能

脚本一旦创建完成，用户就可以运行测试了。LoadRunner的控制器提供了一整套的性能监控器，能在负载测试期间监控多层次系统中的每个组件。通过捕捉整个系统的性能数据，用户就能把这一信息与最终用户负载和响应时间相关联起来，找到瓶颈问题所在。LoadRunner能监控网络、网络装置、大多数的普通web服务器、应用服务器和数据服务器的性能，该性能监控是在非插入的方式下进行的，这样对性能的影响就能降到最低。另外，所有监控器都独立于硬件和操作系统，无需在远程监控服务器上安装代理。

LoadRunner可支持多种环境，提供精确的在线监控，包括：

·运行时间图表：显示虚拟用户状态、用户规定数据点。

·交易图表：显示响应时间，交易（成功/失败）。

·web服务器资源图表：显示每秒点击数、生产量、Apache MS IIS, Netscape等信息。

·系统资源图表：显示服务器资源，SNMP Tuxedo信息。

·Web应用服务器图表：显示BroadVision、ColdFusion、MS Active Server Pages、 SilverStream、 Web-Logic的运行状态。

·数据库服务器资源图表： SQL 服务器, oracle

第七步：分析测试结果

评估测试结果是负载测试流程中最重要的一步。在网络上进行多个流程时，用户已经能够精确记录和执行真实用户的行为，并且性能监控能在运行脚本时准确找到瓶颈问题。用户可以采取以下步骤来修复这些问题：首先，由一个网络专家(DBA, 顾问)对系统做必要调整；其次，用户需要重新运行脚本，验证这些改变确实已经发生；最后，进行前后比较，测试得出系统的改进结果。

LoadRunner的分析组件提供了一个整合环境，能够收集整个测试周期中产生的数据。这个工具非常强大，易于使用，用户能用它来建立各种方案之间的图表比较，从而丰富数据分析流程。

作者: duola1119 时间: 2009-1-12 17:10
分析这东西岂是将这些指标列出来这么简单。

作者: duola1119 时间: 2009-1-12 17:11
在论坛混了这么久，包括我在内，没有人能够把这道题完全的答出来。

作者: huangcm 时间: 2009-1-14 23:28
个人感觉要逐步细化分析，
先可以监控一些常见衡量CPU，内存，磁盘的性能指标，进行综合分析，
然后根据所测系统具体情况，进行初步问题定位，然后确定更详细的监控指标来分析。

怀疑内存不足时：
方法1：
【监控指标】：Memory Available MBytes ，Memory的Pages/sec, page read/sec, Page Faults/sec
【参考值】：
如果 Page Reads/Sec 比率持续保持为 5，表示可能内存不足。
Page/sec 推荐00-20（如果服务器没有足够的内存处理其工作负荷，此数值将一直很高。如果大于80，表示有问题）。

方法2：根据Physical Disk 值分析性能瓶颈
【监控指标】：Memory Available MBytes ，Pages read/sec，%Disk Time 和 Avg.Disk Queue Length
【参考值】：%Disk Time建议阈值90%
当内存不足时，有点进程会转移到硬盘上去运行，造成性能急剧下降，而且一个缺少内存的系统常常表现出很高的CPU利用率，因为它需要不断的扫描内存，将内存中的页面移到硬盘上。

怀疑内存泄漏时
【监控指标】：Memory Available MBytes ，Process\Private Bytes和Process\Working Set，PhysicalDisk/%Disk Time
【说明】：
Windows资源监控中，如果Process\Private Bytes计数器和Process\Working Set计数器的值在长时间内持续升高，同时Memory\Available bytes计数器的值持续降低，则很可能存在内存泄漏。内存泄漏应该通过一个长时间的，用来研究分析当所有内存都耗尽时，应用程序反应情况的测试来检验。

CPU分析
【监控指标】：
System %Processor Time CPU，Processor %Processor Time CPU
Processor%user time 和Processor%Privileged Time
system\Processor Queue Length
Context Switches/sec 和%Privileged Time
【参考值】：
System\%Total processor time不持续超过90%，如果服务器专用于SQL Server,可接受的最大上限是80-85% ，合理使用的范围在60%至70%。
Processor %Processor Time小于75%
system\Processor Queue Length值,小于CPU数量的总数+1

CPU瓶颈问题
1：System\%Total processor time如果该值持续超过90%,且伴随处理器阻塞，则说明整个系统面临着处理器方面的瓶颈.
注: 在某些多CPU系统中,该数据虽然本身并不大,但CPU之间的负载状况极不均衡,此时也应该视作系统产生了处理器方面的瓶颈.
2：排除内存因素，如果Processor %Processor Time计数器的值比较大，而同时网卡和硬盘的值比较低，那么可以确定CPU 瓶颈。（内存不足时，有点进程会转移到硬盘上去运行，造成性能急剧下降，而且一个缺少内存的系统常常表现出很高的CPU利用率，因为它需要不断的扫描内存，将内存中的页面移到硬盘上。）

造成高CPU使用率的原因：
频繁执行程序，复杂运算操作，消耗CPU严重
数据库查询语句复杂，大量的 where 子句，order by, group by 排序等，CPU容易出现瓶颈
内存不足，IO磁盘问题使得CPU的开销增加

磁盘I/O分析
【监控指标】：PhysicalDisk/%Disk time，PhysicalDisk/%Idle Time,Physical Disk\ Avg.Disk Queue Length， Disk sec/Transfer
【参考值】：%Disk Time建议阈值90%

Windows资源监控中，如果% Disk Time和Avg.Disk Queue Length的值很高，而Page Reads/sec页面读取操作速率很低，则可能存在磁盘瓶径。

Processor%Privileged Time该参数值一直很高,且如果在 Physical Disk 计数器中,只有%Disk time 比较大,其他值都比较适中,硬盘可能会是瓶颈。若几个值都比较大, 那么硬盘不是瓶颈。若数值持续超过80%,则可能是内存泄露。如果 Physical Disk 计数器的值很高时该计数器的值（Processor%Privileged Time）也一直很高，则考虑使用速度更快或效率更高的磁盘子系统。

Disk sec/Transfer 一般来说,该数值小于15ms为最好,介于15-30ms之间为良好,30-60ms之间为可以接受,超过60ms则需要考虑更换硬盘或是硬盘的RAID方式了.

[ 本帖最后由 huangcm 于 2009-1-14 23:45 编辑 ]

作者: yanming_huo 时间: 2009-1-17 08:25
标题: 回复 5# 的帖子
o ，如果是自己总结的，很不错……
具体还要看架构，和业务需求。

作者: jxibicf 时间: 2009-2-4 14:21
标题: 11111111111111111111
不是很清楚

作者: waley.qian 时间: 2009-2-6 12:06
有没有关于服务器一些性能监控结果的分析？比如NMON

作者: liuyanerfly 时间: 2009-3-13 19:09

原帖由 duola1119 于 2009-1-12 17:10 发表
分析这东西岂是将这些指标列出来这么简单。

太有同感了！
之前脚本，配置等一系列都正确了，测试出的结果才有可分析性。
仅就一些数字去对这些指标，应该是看不出系统问题的

作者: Fin 时间: 2009-5-12 16:58

原帖由 fmsbai5 于 2009-1-5 18:11 发表
1.       平均事务响应时间
Average Transation Response Time       优秀：10s
2.       每秒点击率
Hits per Second
当增大系统的压力（或增加并发用户数）时，吞吐率和TPS的变化曲线呈大体一致，则系统基本 ...

哥们儿，你是把controller 监控资源的部分计数器罗列出来了吧？
还有，你所谓的优秀、良好、及格、不及格是谁规定的？评价性能不是你这样评价的好不好？要你这样说越小工程的网站访问量极低的性能就好？相对来说TPS达600、1700等庞大访问量那样的网站由于此原因难免响应时间长，就说人家网站不好？太片面了吧？
还有你的CPU利用率怎么就规定出来的好与不好？你的基准测试数据拿出来说话才对啊？ AP-CPU小于70%就是好事情？很有可能WEB服务器出现瓶颈了！感激恩查前端队列堆积吧...
注：此回复并没有其他意思，因为我们都是搞测试的，请仔细斟酌每一句话再说，或许真有新人把此当作教材去使用，误导了大家就不好了。
还有一件事，这些真的是经过51评比出来的精彩回答吗？

作者: 快乐的布丁 时间: 2009-6-25 17:43
具体业务和环境的影响不太好回答，一般都会考虑服务器的可供应带宽来考量

作者: BigBC 时间: 2011-12-14 13:34
学习了

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)