http://kuaibao.qq.com/s/AZTK00?refer=cp_1026分享分享快讯到朋友圈分享快讯到 QQ分享快讯到 QQ 空间分享快讯到微博复制快讯链接到剪贴板您所在位置： &
&nbsp&&nbsp&nbsp&&nbsp
基于 Load Runner 的性能测试论文.doc 57页
本文档一共被下载：
次 ,您可全文免费在线阅读后下载本文档。
下载提示
1.本站不保证该用户上传的文档完整性，不预览、不比对内容而直接下载产生的反悔问题本站不予受理。
2.该文档所得收入(下载+内容+预览三)归上传者、原创者。
3.登录后可充值，立即自动返金币，充值渠道很便利
计算机 211大学 毕业设计
你可能关注的文档：
本科毕业论文（设计）
基于 Load Runner 的性能测试
基于Load Runner 的性能测试
摘要：在软件出现的早期，并没有软件测试这个概念。因为那时的软件都是基于少量用户的，没有形成规模。但是随着计算机的迅速发展，软件的使用者越来越多，对软件的功能和性能的要求也越来越高。这就出现了软件质量保证这一个名词，而软件的质量是通过测试来保证的。软件测试在软件生命周期中占有重要的地位。近年来，软件工程界趋于一种新的观点，即认为软件生命周期的每一个阶段中都包含测试。测试从软件开发的过程按阶段可以划分有：单元测试、集成测试、确认测试、系统测试和验收测试。而性能测试就属于软件系统级测试，其目的就是保证产品发布后系统的性能满足用户需求，在所有的性能测试工具中，Load Runner 是比较成熟的。
中国软件这几年发展迅速，很大部分原因是借鉴了国外优秀企业的经验技术，从无到有，学习了国外企业的一整套做事的规范，的确是一种快速成长方法。当然软件测试也应该如此，从不重视到重视，更应该多学习一下如何制定测试流程，缺陷管理以及测试用例设计等优秀理念。
Load Runner是一种预测系统行为和性能的工业级标准性能测试负载测试工具。通过模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题，Load Runner 能够对整个企业架构进行测试。通过使用Load Runner ，企业能最大限度地缩短测试时间，优化性能和加速应用系统的发布周期。
关键字：，，，Performance Test
Abstract:Appeared early in the software ,there was no concept of Software Testing.As in that days,most of the software was based on a small number of users and hardly development in the market .However ,with the swift development of computer ,the users of software were increased as well as the requirements of the software functionality and quality .Then ,SQA(Software quality assurance) was emerged . And the quality of software was ensured though Software testing . Software testing occupy an important position in software lifecycle .In recent years,there is a new point of view in the software engineerring that Software testing should be included in every stage of software lifecycle . From the process of software development ,testing can be divided into five periods: unit testing ,integration testing ,validation testing ,system testing and acceptation test .Performance test is belong to system testing and its purpose is to secure the performance of system can meet the demands of user . Among all the Performance Test Instrument ,LoadRunner is comparative maturity .
Chinese software has developed rapidly these years, we have learned from many excellent foreign co
正在加载中，请稍后...转载：Loadrunner 接口测试的两种方法 - wq的个人空间 - 51Testing软件测试网 51Testing软件测试网-中国软件测试人的精神家园
转载：Loadrunner 接口测试的两种方法
& 17:59:13
/ 个人分类：
其实无论用那种方法，的原理是通过测试程序模拟客户端向服务器发送请求报文，服务器接收请求报文后对相应的报文做出处理然后再把应答报文发送给客户端，客户端接收应答报文这一个过程。　　方法一、用实现接口测试　　大家都知道LoadRunner是一种工具，但它也可以用在我们做接口测试的时候。开发人员开发出来的接口，提供给测试人员详细的接口使用说明书，该说明书最基本的要求如下：　　接口测试地址：/SNS/Publish　　请求报文参数说明：参数名称参数描述字符类型字符值SNSID社区IDString6UserID用户IDString10CommentsTypeID评论类型IDString2CommentsID评论IDString10AuthorID作者IDString10CommentsContent评论内容String50　　请求报文格式：&?xml version="1.0" encoding="ISO-8859-1"?&& Publish &　　&SNSID&123&/SNSID&　　&UserID&456&/ UserID &　　&CommentsTypeID&2&/ CommentsTypeID &　　&CommentsID&123&/CommentsID&　　&AuthorID&456&/AuthorID&　　&CommentsContent&Don't forget the meeting!&/CommentsContent &&/Publish&　　应答报文的参数接口说明：参数名称参数描述字符类型字符值UserID用户IDString10CommentsTypeID评论类型IDString2CommentsID评论IDString10CommentsContent评论内容String50StatusCode返回值Int0代表pass,非0代表failStatusText返回信息描述String&?xml version="1.0" encoding="ISO-8859-1"?&& Publish &　　&UserID&456&/ UserID &　　&CommentsTypeID&2&/ CommentsTypeID &　　&CommentsID&123&/CommentsID&　　&CommentsContent&Don't forget the meeting!&/CommentsContent &　　&StatusCode&0&/StatusCode&　　&StatusText&发送成功一条评论&/StatusText&&/Publish&　　有了上述的说明书之后，测试人员可以根据文档的描述在LoadRunner书写相应的接口测试脚本。　LoadRunner中涉及到向服务器发送请求的API方法包括：web_url()，web_submit_form()，web_submit_data()，web_custom_request()。下面介绍两种我常用的方法：　　方法一：使用web_submit_data()web_submit_data("insert",&&&&& "Action=http://116.211.23.123/SNS/Publish.htm ",&&&&& "Method=POST",&&&&&&"Referer=http://116.211.23.123/SNS/Publish.htm ",&&&&&& "Mode=HTML",&&&&& ITEMDATA,&&&&& "Name= SNSID ","Value=6601",ENDITEM,&&&&& "Name= UserID ","Value=123",ENDITEM,&&&&& "Name= CommentsTypeID ","Value=1",ENDITEM,&&&&& "Name= CommentsID ","Value=456",ENDITEM,&&&&&& "Name= AuthorID","Value=789",ENDITEM,&&&&&& "Name= CommentsContent ","Value=Just for testing",ENDITEM,&&&&&&&&&&&&&& LAST);　　方法二：使用web_custom_request()char str[1000];strcpy(str,"SNSID=7999&UserID=1&CommentsTypeID=1&CommentsID=1&AuthorID=1&CommentsContent=1");web_custom_request("Publish",&&&&&&&&&&&&&&&&& "Url= http://116.211.23.123/SNS/Publish.htm",&&&&&&&&&&&&&&&&& "Method=POST",&&&&&&&&&&&&&&&&& "Referer=http://116.211.23.123/SNS/Publish.htm ",&&&&&&&&&&&&&&&&& "Mode=HTTP",&&&&&&&&&&&&&&&&& str,&&&&&&&&&&&&&&&&& LAST);　　这也是一种写法，可以跟web_submit_data互换。这种写法更利于拼接参数。　　方法一适合一些xml结构的根元素下的子元素同处于根元素下面，且子元素数目较少的情况下，如果xml结构比较复杂，比如说根元素下面有多级子元素，或者xml树结构分叉较多的时候，我们可以先把xml拼接成一个字符串然后通过web_custom_request()向服务器发送请求。　　我们在做接口的时候会很注意接口的应答报文的信息，这时候我们可以通过LoadRunner的信息查看或者可以通过web_reg_find()或者web_find()这样的API函数来统计接口的运行结果，推荐使用web_reg_find()，web_reg_find()和web_find()区别请大家一下，详细信息太多，在这里不便叙述。　　因为web_reg_find()是注册型函数，所以应该放在web_submit_data()或者web_custom_request()的前面。　　如：web_reg_find("Text=&StatusCode&0&/StatusCode&",//应答报文里边的信息"SaveCount= StatusCodeCount", //统计查询字段的信息，如果找到值为1，如果未找到值为0LAST);　　在脚本的最后我们可以对查询字段的信息进行统计// Check resultif (atoi(lr_eval_string("{StatusCodeCount }")) & 0){ //判断如果Welcome字符串出现次//数大于0lr_output_message("Send out the comment successfully."); }//在日志中输出Send out //the comment successfullyelse{ //如果出现次数小于等于lr_error_message("Send out the comment unsuccessfully."); //在日志中输出Send out //the comment successfullyreturn(0);}　　总结：用LoadRunner做接口测试无法做到把接口参数和程序分理，接口的参数可以通过参数化的方法来实现对同一个参数多个数据的测试。参数化后的测试数据保存在此脚本的保存位置下。　　方法二、通过Java + Fitnesse实现接口功能测试　　什么是Fitnesse？　　FitNesse是一套协作工具　FitNesse是帮助大家加强软件开发过程中的协作的工具。能够让客户、测试人员和开发人员了解软件要做成什么样，帮助建议软件最终是否达到了设计初衷。　　FitNesse是一套工具　从另外一个角度看，FitNesse是一个轻量级的、开源的框架，能够帮助开发团队方便的定义验收测试（Acceptance Tests），通过在页面上简单的输出和预计输出的表格就可实现，并且可以运行这些测试以确定是否通过。　　FitNesse是wiki可以很方便的创建和编辑页面　FitNesse是一个web服务器不用过多的安装配置，很方便使用。　　我习惯使用Eclipse集成开发工具写测试代码，用fitnesse准备接口的测试数据，由此实现接口的测试数据和测试程序的分离。　　关于Fitnesse的使用大家可以参考官方网址。Fitnesse的四种常见表格是：　　ColumnFixture，ActionFixture，Decision Table，ScriptTable。在中ColumnFixture用的最多。　　下面的程序使用的是ColumnFixture表格。// Java fixturespackage info.fitnesse.import fit.ColumnFpublic class PublishTest extends ColumnFixture {&&& //通过url向服务器发送请求的程序段省略&& public StringSNSID; //对应列名|first part|&& public StringUserID; //对应列名|second part|&& private StringCommentsTypeID;&& private StringAuthorID;private StringCommentsCprivate StringUserID;//对参数的set和get方法省略}ColumnFixture表格里边的测试数据是：//省略设置表格的存储位置信息　　总结：上述两种方法都是对接口做功能测试的方法，使用LoadRunner做接口测试的时候可以不用让开发人员提供测试人员相应的UI测试页面，直接调用接口做测试，但是测试程序和数据的依赖性太强；使用Fitnesse做接口测试的时候可以实现测试程序和数据的分离，只用点击Fitnesse界面的按钮就可以实现测试，测试消耗时间比使用LoadRunner做接口测试少。具体实例教你如何做LoadRunner结果分析_软件学园_科技时代_新浪网
具体实例教你如何做LoadRunner结果分析
LoadRunner
　　【IT168 技术文档】1.前言:　　LoadRunner 最重要也是最难理解的地方--测试结果的分析.其余的录制和加压测试等设置对于我们来讲通过几次操作就可以轻松掌握了.针对 Results Analysis 我用图片加文字做了一个例子,希望通过例子能给大家更多的帮助.这个例子主要讲述的是多个用户同时接管任务,测试系统的响应能力,确定系统瓶颈所在.客户要求响应时间是1 个人接管的时间在5S 内.　　2.系统资源:　　2.1 硬件环境：　　CPU：奔四2.8E　　硬盘：100G　　网络环境：100Mbps　　2.2 软件环境：　　操作系统：英文windowsXP　　服务器：tomcat 服务　　浏览器：IE6.0　　系统结构：B/S 结构　　3.添加监视资源　　下面要讲述的例子添加了我们平常测试中最常用到的一些资源参数.另外有些特殊的资源暂时在这里不做讲解了.我会在以后相继补充进来。　　Mercury Loadrunner Analysis 中最常用的5 种资源.　　1. Vuser　　2. Transactions　　3. Web Resources　　4. Web Page Breakdown　　5. System Resources　　在Analysis 中选择&Add graph&或&New graph&就可以看到这几个资源了.还有其他没有数据的资源,我们没有让它显示.　　　　如果想查看更多的资源,可以将左下角的display only graphs containing data 置为不选.然后选中相应的点&open graph&即可.　　打开Analysis 首先可以看的是Summary Report.这里显示了测试的分析摘要.应有尽有.但是我们并不需要每个都要仔细去看.下面介绍一下部分的含义：　　Duration(持续时间)：了解该测试过程持续时间.测试人员本身要对这个时期内系统一共做了多少的事有大致的熟悉了解.以确定下次增加更多的任务条件下测试的持续时间。　　Statistics Summary(统计摘要)：只是大概了解一下测试数据,对我们具体分析没有太大的作用.　　Transaction Summary(事务摘要)：了解平均响应时间Average单位为秒.　　其余的看不看都可以.都不是很重要.【注】&51Testing授权IT168独家转载，未经明确的书面许可，任何人或单位不得对本文内容复制、转载或进行镜像，否则将追究法律责任。
　　4.分析集合点　　在录制脚本中通常我们会使用到集合点,那么既然我们用到了集合点,我们就需要知道Vuser 是在什么时候集合在这个点上,又是怎样的一个被释放的过程.这个时候就需要观察Vuser-Rendezvous 图.　　　　图1　　可以看到大概在3 分50 的地方30 个用户才全部集中到start 集合点,持续了3 分多,在7 分30 的位置开始释放用户,9 分30 还有18 个用户,11 分10 还有5 个用户,整个过程持续了12 分.　　　　图2　　上面图2 是集合点与平均事务响应时间的比较图.　　注:在打开analysis 之后系统LR 默认这两个曲线是不在同一张图中的.这就需要自行设置了.具体步骤如下:　　点击图上.右键选择merge graphs.然后在select graph to merge with 中选择即将用来进行比较的graph.如图3:　　　　图3　　图2 中较深颜色的是平均响应时间,浅色的为集合点,当Vuser 在集合点持续了1分后平均响应时间呈现最大值,可见用户的并发对系统的性能是一个很大的考验.接下来看一下与事务有关的参数分析.下看一张图.　　　　图4　　这张图包括Average Transaction Response Time 和Running Vuser 两个数据图.从图中可以看到Vuser_init_Transaction(系统登录)对系统无任何的影响,Vuser 达到15 个的时候平均事务响应时间才有明显的升高,也就是说系统达到最优性能的时候允许14 个用户同时处理事务,Vuser 达到30 后1 分,系统响应时间最大,那么这个最大响应时间是要推迟1 分钟才出现的,在系统稳定之后事务响应时间开始下降说明这个时候有些用户已经执行完了操作.同时也可以看出要想将事务响应时间控制在10S 内.Vuser 数量最多不能超过2 个.看来是很难满足用户的需求了.　　做一件事有时候上级会问你这件事办得怎么样了.你会说做完一半了.那么这个一半的事情你花了多少时间呢?所以我们要想知道在给定时间的范围内完成事务的百分比就要靠下面这个图(Transaction Response Time(Percentile)　　　　图中画圈的地方表示10%的事务的响应时间是在80S 左右.80S 对于用户来说不是一个很小的数字,而且只有10%的事务,汗.你觉得这个系统性能会好么!　　实际工作中遇到的事情不是每一件事都能够在很短的时间内完成的,对于那些需要时间的事情我们就要分配适当的时间处理,时间分配的不均匀就会出现有些事情消耗的时间长一些,有些事情消耗的短一些,但我们自己清楚.LR 同样也为我们提供了这样的功能,使我们可以了解大部分的事务响应时间是多少?以确定这个系统我们还要付出多少的代价来提高它.　　Transaction Response Time(Distribution)-事务响应时间(分布)　　显示在方案中执行事务所用时间的分布.如果定义了可以接受的最小和最大事务性能时间,可以通过此图确定服务器性能是否在可接受范围内.　　　　很明显大多数事务的响应时间在60-140S.在我测试过的项目中多数客户所能接受的最大响应时间也要在20S 左右.140S 的时间!很少有人会去花这么多的时间去等待页面的出现吧!　　通过观察以上的数据表.我们不难看到此系统在这种环境下并不理想.世间事有果就有因,那么是什么原因导致得系统性能这样差呢?让我们一步一步的分析.　　系统性能不好的原因多方面,我们先从应用程序看.有的时候我不得不承认LR 的功能真的很强大,这也是我喜欢它的原因.先看一张页面细分图.　　　　一个应用程序是由很多个组件组成的,整个系统性能不好那我们就把它彻底的剖析一下.图片中显示了整个测试过程中涉及到的所有web 页.web page breakdown中显示的是每个页面的下载时间.点选左下角web page breakdown 展开,可以看到每个页中包括的css 样式表,js 脚本,jsp 页面等所有的属性.　　在select page to breakdown 中选择页面.　　　　见图.　　在 Select Page To Breakdown 中选择http://192.168.0.135:8888/usertasks 后,在下方看到属于它的两个组件,第一行中Connection 和First Buffer 占据了整个的时间,那么它的消耗时间点就在这里,我们解决问题就要从这里下手.　　　　　　也有可能你的程序中client 的时间最长.或者其他的,这些就要根据你自己的测试结果来分析了.下面我们来看一下CPU,内存.硬盘的瓶颈分析方法:　　首先我们要监视CPU,内存.硬盘的资源情况.得到以下的参数提供分析的依据.&&&&&& %processor time(processor_total):器消耗的处理器时间数量.如果服务器专用于sql server 可接受的最大上限是80% -85 %.也就是常见的CPU 使用率.　　%User time(processor_total)::表示耗费CPU的数据库操作，如排序，执行aggregate functions等。如果该值很高，可考虑增加索引，尽量使用简单的表联接，水平分割大表格等方法来降低该值。　　%DPC time(processor_total)::越低越好。在多处理器系统中，如果这个值大于50%并且Processor:% Processor Time非常高，加入一个网卡可能会提高性能，提供的网络已经不饱和。　　%Disk time(physicaldisk_total):指所选磁盘驱动器忙于为读或写入请求提供服务所用的时间的百分比。如果三个计数器都比较大，那么硬盘不是瓶颈。如果只有%Disk Time比较大，另外两个都比较适中，硬盘可能会是瓶颈。在记录该计数器之前，请在Windows 2000 的命令行窗口中运行diskperf -yD。若数值持续超过80%，则可能是内存泄漏。　　Availiable bytes(memory):用物理内存数. 如果Available Mbytes的值很小(4 MB 或更小)，则说明计算机上总的内存可能不足，或某程序没有释放内存。　　Context switch/sec(system): (实例化inetinfo 和dllhost 进程) 如果你决定要增加线程字节池的大小，你应该监视这三个计数器(包括上面的一个)。增加线程数可能会增加上下文切换次数，这样性能不会上升反而会下降。如果十个实例的上下文切换值非常高，就应该减小线程字节池的大小。　　%Disk reads/sec(physicaldisk_total):每秒读硬盘字节数.　　%Disk write/sec(physicaldisk_total):每秒写硬盘字节数.　　Page faults/sec:进程产生的页故障与系统产生的相比较，以判断这个进程对系统页故障产生的影响。　　Pages per second:每秒钟检索的页数。该数字应少于每秒一页Working set:理线程最近使用的内存页，反映了每一个进程使用的内存页的数量。如果服务器有足够的空闲内存，页就会被留在工作集中，当自由内存少于一个特定的阈值时，页就会被清除出工作集。　　Avg.disk queue length:读取和写入请求(为所选磁盘在实例间隔中列队的)的平均数。该值应不超过磁盘数的1.5~2 倍。要提高性能，可增加磁盘。注意：一个Raid Disk实际有多个磁盘。　　Average disk read/write queue length: 指读取(写入)请求(列队)的平均数Disk reads/(writes)/s:理磁盘上每秒钟磁盘读、写的次数。两者相加，应小于磁盘设备最大容量。　　Average disk sec/read:以秒计算的在此盘上读取数据的所需平均时间。Average disk sec/transfer:指以秒计算的在此盘上写入数据的所需平均时间。　　Bytes total/sec:为发送和接收字节的速率，包括帧字符在内。判断网络连接速度是否是瓶颈，可以用该计数器的值和目前网络的带宽比较Page read/sec:每秒发出的物理数据库页读取数。这一统计信息显示的是在所有数据库间的物理页读取总数。由于物理 I/O 的开销大，可以通过使用更大的数据高速缓存、智能索引、更高效的查询或者改变数据库设计等方法，使开销减到最小。　　Page write/sec:(写的页/秒)每秒执行的物理数据库写的页数。
　　1. 判断应用程序的问题　　如果系统由于应用程序代码效率低下或者系统结构设计有缺陷而导致大量的上下文切换(context switches/sec显示的上下文切换次数太高)那么就会占用大量的系统资源,如果系统的吞吐量降低并且CPU的使用率很高,并且此现象发生时切换水平在15000以上,那么意味着上下文切换次数过高.　　　　从图的整体看.context switches/sec变化不大,throughout曲线的斜率较高,并且此时的contextswitches/sec已经超过了15000.程序还是需要进一步优化.　　2. 判断CPU瓶颈　　如果processor queue length显示的队列长度保持不变(&=2)个并且处理器的利用率%Processortime超过90%,那么很可能存在处理器瓶颈.如果发现processor queue length显示的队列长度超过2,而处理器的利用率却一直很低,或许更应该去解决处理器阻塞问题,这里处理器一般不是瓶颈.　　　　%processor time平均值大于95,processor queue length大于2.可以确定CPU瓶颈.此时的CPU已经不能满足程序需要.急需扩展.　　3. 判断内存泄露问题　　内存问题主要检查应用程序是否存在内存泄漏,如果发生了内存泄漏,process\private bytes计数器和process\working set 计数器的值往往会升高,同时avaiable 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.DiskBytes/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 的值始终较高，可以考虑升级磁盘驱动器或将某些文件移动到其他磁盘或服务器。
电话：010-
不支持Flash}