如何使用Loadrunner进行资源占用率的分析？（08-12-29）（获奖名单已公布）

jmtest

来学习一下，刚刚接触

saran

观众

angelna

对象   :System  

度量    : %Total Processor Time                                          

描述 :                 
系统上所有处理器都忙于执行非空闲 线    程的平
均时间的百分比。在多处理器系统上，如果所
有处理器始终繁忙，此值为 100%，如果所有
处理器为 50% 繁忙，此值为 50%，而如果这
些处理器中的四分之一是 100% 繁忙的，则
此值为 25%。它反映了用于有用作业上的时
间的比率。每个处理器将分配给空闲进程中的
一个空闲线程，它将消耗所有其他线程不使用
的那些非生产性处理器周期
度量:
File Data Operations/sec
描述:
计算机对文件系统设备执行读取和写入操作的
速率。这不包括文件控制操作
度量rocessor Queue Length
描述:
线程单元中的处理器队列的即时长度。如果您
不同时监视线程计数，则此计数始终为 0。所
有处理器都使用单一队列（线程在该队列中
等待处理器进行循环）。此长度不包括当前正
在执行的线程。一般情况下，如果处理器队列
的长度一直超过二，则可能表示处理器堵塞。
此值为即时计数，不是一段时间的平均值
对象rocessor
度量:%Processor Time
描述:
处理器执行非空闲线程的时间百分比。此计数
器为反映处理器活动的一个主要指示器。它是
通过度量处理器在每个采样间隔中执行空闲进
程的线程所花费的时间比率，然后从 100%
中减去此值来计算的。（每个处理器都有一个
空闲线程，它在没有其他线程准备运行时消耗
处理器周期。）它可以反映有用作业占用的采
样间隔的百分比。该计数器显示在采样期间所
观察到的繁忙时间的平均百分比。它是通过监
视服务处于非活动状态的时间，然后从 100%
中减去此值来计算的


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

lanbiers

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

本文就“维护网络应用性能是战胜这些电子商务挑战并创造更多收入的关键”这一观点进行了阐述，讨论了维护网络应用对于保证客户满意度的重要性，以及负载测试对于网站成功启动和管理具有重要意义的原因。另外，本文还调查了不同类型的负载测试，详细讨论了负载测试流程和可靠测试工具所应具有的特性。最后，本文对全球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

分析这东西岂是将这些指标列出来这么简单。

duola1119

在论坛混了这么久，包括我在内，没有人能够把这道题完全的答出来。

huangcm

个人感觉要逐步细化分析，
先可以监控一些常见衡量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

o ，如果是自己总结的，很不错……
具体还要看架构，和业务需求。

jxibicf

不是很清楚

waley.qian

有没有关于服务器一些性能监控结果的分析？比如NMON

liuyanerfly

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

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

Fin

原帖由 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评比出来的精彩回答吗？

快乐的布丁

具体业务和环境的影响不太好回答，一般都会考虑服务器的可供应带宽来考量

BigBC

学习了