LoadRunner负载测试之Windows常见性能计数器分析服务器性能瓶颈.docx
《LoadRunner负载测试之Windows常见性能计数器分析服务器性能瓶颈.docx》由会员分享，可在线阅读，更多相关《LoadRunner负载测试之Windows常见性能计数器分析服务器性能瓶颈.docx（31页珍藏版）》请在冰豆网上搜索。
LoadRunner负载测试之Windows常见性能计数器分析服务器性能瓶颈
LoadRunner监视的性能计数器
今天，我先把我整理的一些计数器及其阈值要求等贴出来，这些计数器是针对我对windows操作系统，C/S结构的sql
server数据库及WEB平台.net产品测试时的一些计数器；大家可以继续补充，作过unix平台上oracle数据库测试及J2EE架构及WEBLOGIC方面测试的朋友，也希望把自己使用的计数器贴出来，让大家分享。
好了，先说这些了，希望通过这个专题，最终能让大家对自己的测试结果进行分析。
Memory:
内存使用情况可能是系统性能中最重要的因素。
如果系统“页交换”频繁，说明内存不足。
“页交换”是使用称为“页面”的单位，将固定大小的代码和数据块从
RAM移动到磁盘的过程，其目的是为了释放内存空间。
尽管某些页交换使Windows2000
能够使用比实际更多的内存，也是可以接受的，但频繁的页交换将降低系统性能。
减少页交换将显著提高系统响应速度。
要监视内存不足的状况，请从以下的对象计数器开始：
b5E2RGbCAP
AvailableMbytes:
可用物理内存数.如果AvailableMbytes的值很小<4MB
或更小），则说明计算机上总的内存可能不足，或某程序没有释放内存。
page/sec:
表明由于硬件页面错误而从磁盘取出的页面数，或由于页面错误而写入磁盘以释放工作集空间的页面数。
一般如果pages/sec持续高于几百，那么您应该进一步研究页交换活动。
有可能需要增加内存，以减少换页的需求<你可以把这个数字乘以4k就得到由此引起的硬盘数据流量）。
Pages/sec
的值很大不一定表明内存有问题，而可能是运行使用内存映射文件的程序所致。
pageread/sec:
页的硬故障，page/sec的子集，为了解读对内存的引用，必须读取页文件的次数。
阈值为>5.
越低越好。
大数值表示磁盘读而不是缓存读。
由于过多的页交换要使用大量的硬盘空间，因此有可能将导致将页交换内存不足与导致页交换的磁盘瓶径混淆。
因此，在研究内存不足不太明显的页交换的原因时，您必须跟踪如下的磁盘使用情况计数器和内存计数器：
p1EanqFDPw
PhysicalDisk\\%DiskTime
PhysicalDisk\\Avg.DiskQueueLength
例如，包括PageReads/sec和%DiskTime及Avg.DiskQueueLength。
如果页面读取操作速率很低，同时
%DiskTime和Avg.DiskQueue
Length的值很高，则可能有磁盘瓶径。
但是，如果队列长度增加的同时页面读取速率并未降低，则内存不足。
要确定过多的页交换对磁盘活动的影响，请将PhysicalDisk\\Avg.Disksec/Transfer和Memory\\
Pages/sec计数器的值增大数倍。
如果这些计数器的计数结果超过了
0.1，那么页交换将花费百分之十以上的磁盘访问时间。
如果长时间发生这种情况，那么您可能需要更多的内存。
Page
Faults/sec:
每秒软性页面失效的数目<包括有些可以直接在内存中满足而有些需要从硬盘读取）较page/sec只表明数据不能在内存的指定工作集中立即使用。
DXDiTa9E3d
CacheBytes：
文件系统缓存如IIS5.0
运行内存不够时，它会自动整理缓存。
需要关注该计数器的趋势变化
如果您怀疑有内存泄露，请监视Memory\\AvailableBytes和Memory\\Committed
Bytes，以观察内存行为，并监视您认为可能在泄露内存的进程的Process\\PrivateBytes、Process\\Working
Set和Process\\HandleCount。
如果您怀疑是内核模式进程导致了泄露，则还应该监视Memory\\PoolNonpaged
Bytes、Memory\\PoolNonpagedAllocs和Process（process_name>\\Pool
NonpagedBytes。
Pagespersecond:
每秒钟检索的页数。
该数字应少于每秒一页。
Process：
%ProcessorTime:
被处理器消耗的处理器时间数量。
如果服务器专用于sqlserver,可接受的最大上限是80-85%
PageFaults/sec:
将进程产生的页故障与系统产生的相比较，以判断这个进程对系统页故障产生的影响。
Workset:
处理线程最近使用的内存页，反映了每一个进程使用的内存页的数量。
如果服务器有足够的空闲内存，页就会被留在工作集中，当自由内存少于一个特定的阈值时，页就会被清除出工作集。
RTCrpUDGiT
Inetinfo:
Private
Bytes:
此进程所分配的无法与其它进程共享的当前字节数量。
如果系统性能随着时间而降低，则此计数器可以是内存泄漏的最佳指示器。
Processor：
监视“处理器”和“系统”对象计数器可以提供关于处理器使用的有价值的信息，帮助您决定是否存在瓶颈。
%ProcessorTime:
如果该值持续超过95%，表明瓶颈是CPU。
可以考虑增加一个处理器或换一个更快的处理器。
%UserTime:
表示耗费CPU的数据库操作，如排序，执行aggregate
functions等。
如果该值很高，可考虑增加索引，尽量使用简单的表联接，水平分割大表格等方法来降低该值。
%PrivilegedTime：
如果该参数值和"Physical
Disk"参数值一直很高，表明I/O有问题。
可考虑更换更快的硬盘系统。
另外设置TempdbinRAM，减低"maxasyncIO"，"max
lazywriterIO"等措施都会降低该值。
此外，跟踪计算机的服务器工作队列当前长度的ServerWorkQueues\\QueueLength
计数器会显示出处理器瓶颈。
队列长度持续大于4则表示可能出现处理器拥塞。
此计数器是特定时间的值，而不是一段时间的平均值。
%DPCTime:
越低越好。
在多处理器系统中，如果这个值大于50%并且Processor:
%Processor
Time非常高，加入一个网卡可能会提高性能，提供的网络已经不饱和。
Thread
ContextSwitches/sec:
（实例化inetinfo和dllhost进程>
如果你决定要增加线程字节池的大小，你应该监视这三个计数器<包括上面的一个）。
增加线程数可能会增加上下文切换次数，这样性能不会上升反而会下降。
如果十个实例的上下文切换值非常高，就应该减小线程字节池的大小。
5PCzVD7HxA
PhysicalDisk:
%DiskTime%:
指所选磁盘驱动器忙于为读或写入请求提供服务所用的时间的百分比。
如果三个计数器都比较大，那么硬盘不是瓶颈。
如果只
%DiskTime比较大，另外两个都比较适中，硬盘可能会是瓶颈。
在记录该计数器之前，请在Windows2000
的命令行窗口中运行diskperf-yD。
若数值持续超过80%，则可能是内存泄漏。
Avg.DiskQueueLength:
指读取和写入请求（为所选磁盘在实例间隔中列队的>的平均数。
该值应不超过磁盘数的1.5~2
倍。
要提高性能，可增加磁盘。
注意：
一个RaidDisk实际有多个磁盘。
AverageDiskRead/WriteQueueLength:
指读取（写入>请求（列队>的平均数。
DiskReads（Writes>/s:
物理磁盘上每秒钟磁盘读、写的次数。
两者相加，应小于磁盘设备最大容量。
AverageDisksec/Read:
指以秒计算的在此盘上读取数据的所需平均时间。
AverageDisksec/Transfer:
指以秒计算的在此盘上写入数据的所需平均时间。
NetworkInterface：
BytesTotal/sec:
为发送和接收字节的速率，包括帧字符在内。
判断网络连接速度是否是瓶颈，可以用该计数器的值和目前网络的带宽比较
SQLServer性能计数器：
AccessMethods（访问方法>用于监视访问数据库中的逻辑页的方法。
FullScans/sec（全表扫描/秒>
每秒不受限的完全扫描数。
可以是基本表扫描或全索引扫描。
如果这个计数器显示的值比1或2高，应该分析你的查询以确定是否确实需要全表扫描，以及SQ
L查询是否可以被优化。
Pagesplits/sec（页分割/秒>由于数据更新操作引起的每秒页分割的数量。
BufferManager（缓冲器管理器>：
监视Microsoft®。
SQLServer?
如何使用：
内存存储数据页、内部数据结构和过程高速缓存；计数器在SQLServer从磁盘读取数据库页和将数据库页写入磁盘时监视物理I/O。
监视SQL
Server所使用的内存和计数器有助于确定：
是否由于缺少可用物理内存存储高速缓存中经常访问的数据而导致瓶颈存在。
如果是这样，SQLServer
必须从磁盘检索数据。
是否可通过添加更多内存或使更多内存可用于数据高速缓存或SQLServer内部结构来提高查询性能。
SQLServer需要从磁盘读取数据的频率。
与其它操作相比，例如内存访问，物理I/O会耗费大量时间。
尽可能减少物理I/O
可以提高查询性能。
.PageReads/sec：
每秒发出的物理数据库页读取数。
这一统计信息显示的是在所有数据库间的物理页读取总数。
由于物理I/O
的开销大，可以通过使用更大的数据高速缓存、智能索引、更高效的查询或者改变数据库设计等方法，使开销减到最小。
.PageWrites/sec（.写的页/秒>每秒执行的物理数据库写的页数。
.BufferCacheHitRatio.在“缓冲池” Pool）中没有被读过的页占整个缓冲池中所有页的比率。
可在高速缓存中找到而不需要从磁盘中读取的页的百分比。
这一比率是高速缓存命中总数除以自SQL
Server
实例启动后对高速缓存的查找总数。
经过很长时间后，这一比率的变化很小。
由于从高速缓存中读数据比从磁盘中读数据的开销要小得多，一般希望这一数值高一些。
通常，可以通过增加
SQLServer可用的内存数量来提高高速缓存命中率。
计数器值依应用程序而定，但比率最好为90%
或更高。
增加内存直到这一数值持续高于90%，表示90%以上的数据请求可以从数据缓冲区中获得所需数据。
LazyWrites/sec（惰性写/秒>惰性写进程每秒写的缓冲区的数量。
值最好为0。
CacheManager（高速缓存管理器>对象提供计数器，用于监视Microsoft®。
SQLServer?
如何使用内存存储对象，如存储过程、特殊和准备好的Transact-SQL语句以及触发器。
CacheHitRatio（高速缓存命中率，所有Cache”的命中率。
在SQLServer中，Cache可以包括Log
Cache，BufferCache以及ProcedureCache，是一个总体的比率。
>高速缓存命中次数和查找次数的比率。
对于查看SQL
Server高速缓存对于你的系统如何有效，这是一个非常好的计数器。
如果这个值很低，持续低于80%，就需要增加更多的内存。
Latches（闩>用于监视称为闩锁的内部SQLServer资源锁。
监视闩锁以明确用户活动和资源使用情况，有助于查明性能瓶颈。
AverageLatchWaitTime（ms>（平均闩等待时间（毫秒>>一个SQL
Server线程必须等待一个闩的平均时间，以毫秒为单位。
如果这个值很高，你可能正经历严重的竞争问题。
LatchWaits/sec（闩等待/秒>在闩上每秒的等待数量。
如果这个值很高，表明你正经历对资源的大量竞争。
Locks（锁>提供有关个别资源类型上的SQLServer锁的信息。
锁加在SQLServer
资源上<如在一个事务中进行的行读取或修改），以防止多个事务并发使用资源。
例如，如果一个排它（X>
锁被一个事务加在某一表的某一行上，在这个锁被释放前，其它事务都不可以修改这一行。
尽可能少使用锁可提高并发性，从而改善性能。
可以同时监视Locks
对象的多个实例，每个实例代表一个资源类型上的一个锁。
NumberofDeadlocks/sec（死锁的数量/秒>导致死锁的锁请求的数量
AverageWaitTime（ms>（平均等待时间（毫秒>>线程等待某种类型的锁的平均等待时间
LockRequests/sec（锁请求/秒>每秒钟某种类型的锁请求的数量。
Memorymanager:
用于监视总体的服务器内存使用情况，以估计用户活动和资源使用，有助于查明性能瓶颈。
监视SQLServer
实例所使用的内存有助于确定：
是否由于缺少可用物理内存存储高速缓存中经常访问的数据而导致瓶颈存在。
如果是这样，SQLServer必须从磁盘检索数据。
是否可以通过添加更多内存或使更多内存可用于数据高速缓存或SQLServer内部结构来提高查询性能。
Lockblocks:
服务器上锁定块的数量，锁是在页、行或者表这样的资源上。
不希望看到一个增长的值。
Totalservermemory：
sqlserver服务器当前正在使用的动态内存总量.
监视IIS需要的一些计数器
InternetInformationServicesGlobal:
FileCacheHits%、FileCacheFlushes、FileCacheHits
FileCacheHits%是全部缓存请求中缓存命中次数所占的比例，反映了IIS
的文件缓存设置的工作情况。
对于一个大部分是静态网页组成的网站，该值应该保持在80%左右。
而FileCache
Hits是文件缓存命中的具体值，FileCacheFlushes
是自服务器启动之后文件缓存刷新次数，如果刷新太慢，会浪费内存；如果刷新太快，缓存中的对象会太频繁的丢弃生成，起不到缓存的作用。
通过比较File
CacheHits和FileCacheFlushes
可得出缓存命中率对缓存清空率的比率。
通过观察它两个的值，可以得到一个适当的刷新值<参考IIS的设置ObjectTTL、MemCacheSize
、MaxCacheFileSize）
WebService:
BytesTotal/sec:
显示Web服务器发送和接受的总字节数。
低数值表明该IIS正在以较低的速度进行数据传输。
ConnectionRefused：
数值越低越好。
高数值表明网络适配器或处理器存在瓶颈。
NotFoundErrors：
显示由于被请求文件无法找到而无法由服务器满足的请求数
Loadrunner性能测试一个实例
随着测试越来越重要，其中的性能测试也受到越来越多的关注。
比较普遍的性能测试工具是Loadrunner7.51，但是很多人对此性能工具不是很熟悉。
本人也是总结心得体会，将做过的性能测试实例以饷大家，希望对各位做测试的朋友有所帮助。
该方案是针对某公司试卷库的性能测试。
该试卷库是用来对公司内部员工培训结果的一个考核。
试卷库在公司内部web服务器上，假设开设50个账号和密码可供50个考生同时参加考试。
要求，每台机器只能由一个用户使用，每个用户只能使用各自不同的账号登录考试系统，做完题目后，要求提交考试结果，若在制定的时间内不提交，则系统强制提交考试结果。
但是，一般测试部门不可能有50台机器同时进行测试的。
所以，可以借Loadrunner7.51模拟IP地址，修改脚本来协助测试。
但是，为了保证测试结果，建议搜罗公司中所有可用的机器进行复测，因为有时候是不可以完全信赖工具的。
现场测试环境
硬件：
50台PC机，Web服务器
软件：
Loadrunner7.0，Win2000，IE5.0和IE6.0
人员：
质控部2人，执行现场测试
工程部22人，提供现场环境
技术部各1人，提供技术支持
测试要求
50个用户拥有独立IP地址，不同的用户及密码登录，试卷完成后各自同时提交。
测试内容
50个用户以不同的用户名和密码登录试卷库。
试卷完成后，提交考试结果。
测试考试结果是否能正常提交以及正确评分。
测试方案
1、完全20台实际的PC机进行现场测试。
<1）
准备工作，并做计划。
第一轮测试执行三遍，设定用户考试内容全部同时提交，第一遍全部使用IE5.0，第二遍10台使用IE5.0，10台使用IE6.0，第三遍全部使用IE6.0
<2）At9：
00，20个用户同时登录系统
<3）At9：
05，20个用户同时全部提交
<4）分别记录第一轮测试<三遍）的结果
<5）第二轮测试准备工作，设定15个用户考试内容同时提交，另外5个用户延时5分钟提交，全部使用IE5.0
<6）At9：
15，20个用户同时登录系统
<7）At9：
20，15个用户同时提交
<8）At9：
25，剩余5个用户同时提交
<9）记录第二轮测试结果
<10）第三轮测试准备工作，设定15个用户考试内容同时提交，另外5个用户延时5分钟提交，全部使用IE6.0
<11）At9：
15，20个用户同时登录系统
<12）At9：
20，15个用户同时提交
<13）At9：
25，剩余5个用户同时提交
<14）记录第三轮测试结果
<15）第四轮测试准备工作，设定15个用户考试内容同时提交，另外5个用户延时5分钟提交，正常提交用户使用IE5.0，延时提交用户使用IE6.0
<16）At9：
15，20个用户同时登录系统
<17）At9：
20，15个用户同时提交
<18）At9：
25，剩余5个用户同时提交
<19）记录第四轮测试结果
<20）第五轮测试准备工作，设定15个用户考试内容同时提交，另外5个用户延时5分钟提交，正常提交用户使用IE6.0，延时提交用户使用IE5.0
<21）At9：
15，20个用户同时登录系统
<22）At9：
20，15个用户同时提交
<23）At9：
25，剩余5个用户同时提交
<24）记录第五轮测试结果
<25）
第六轮测试准备工作，设定15个用户考试内容同时提交，另外5个用户延时5分钟提交，正常提交用户其中10个使用IE5.0，5个使用IE6.0，延时提交用户使用IE5.0
<26）At9：
15，20个用户同时登录系统
<27）At9：
20，15个用户同时提交
<28）At9：
25，剩余5个用户同时提交
<29）记录第六轮测试结果
<30）第七轮测试准备工作，设定10个用户考试内容同时提交，另外10个用户分两次分别延时5分钟、15提交
<31）At9：
35，20个用户同时登录系统
<32）At9：
40，10个用户同时提交
<33）At9：
45，剩余的其中5个用户同时提交
<34）At9：
55，剩余的5个用户同时提交
<35）记录第七轮测试结果，参见第二轮测试－第六轮测试过程分别对IE5.0和IE6.0的情况进行测试
<36）第八轮测试准备工作，设定其中10个用户不提交，由系统强行提交
<37）At10：
10，20个用户同时登录系统
<38）At10：
15，10个用户同时提交
<39）其余用户的内容由系统强行提交
<40）记录第八轮测试结果，参见第二轮测试－第六轮测试过程分别对IE5.0和IE6.0的情况进行测试
<41）第九轮测试准备工作，设定其中10个用户同时提交，5个用户延时5分钟提交，其余用户由系统强行提交
<42）At10：
25，20个用户同时登录系统
<43）At10：
30，10个用户同时提交
<44）At10：
35，剩余的其中5个用户同时提交
<45）剩余5个用户系统强制提交
<46）记录第九轮测试结果，参见第二轮测试－第六轮测试过程分别对IE5.0和IE6.0的情况进行测试
2、模拟20个用户进行测试。
其中，10台
升级会员 