LR结果分析-2.doc

LR结果分析通过场景完成负载后，我们完成了性能测试的执行过程，接着就是通过负载的结果来发现和定位性能瓶颈。在这里Analysis就好比一个数据分析中心或数据仓库，它将场景运行中所能得到的数据都整合在一起，能够对测试结果数据进行整理，并提供了一些方法可愿意进一步对结果数据进行分析，从而找出系统的性能指标和可能的瓶颈，最终生成报告。可以把Analysis看作一个股票分析软件，将股票的数据收集分析后生成K线图，而具体说明了什么，还要依赖于分析者自身。1.1 新建Analysis分析导入场景数据生成Analysis报告的方式有一下三种：1. 当场景运行结束后在场景直接运行Results菜单下的Analyze Results命令进入Analysis。2. 在Analysis中打开新建菜单，然后进入场景运行结束后的场景结果res目录，接着Analysis会对整个场景数据进行整理，给出简明报告及相关图表。3. 在场景结果目录中直接双击Mercury LoadRunner Result（.lrr）文件。1.2 Analysis Summary当Analysis导入场景数据后，首先看到的是统计表格Analysis Summary场景摘要，提供了对整个场景数据的简单报告。1.2.1 Analysis Summary（场景摘要）这里给出了场景的摘要，包括以下内容：Period：场景运行的起止时间Scenario Name：场景名称Results in Scenario：场景运行的结果目录Duration：场景运行的时间通过场景摘要可以了解场景执行的基本信息。1.2.2 Statistics Summary（场景状态的统计说明）场景状态的统计说明包含以下内容：Macimum Running Vusers：场景最大用户数Toal Thtoughput：总带宽流量Average Thtoughput：平均每秒带宽流量Total Hits：总点击数Average Hits per Second：平均每秒点击数单击View HTTP Responses Summary选项可以切换到报告的最下端查看HTTP请求的统计。1.2.3 Scenario Behavior Over Time（场景行为综述）这里列出了在场景中定义的事务在各个时间点上的错误数。1.2.4 Tansaction Summary（事务摘要）这里首先给出的是场景中所有事务的情况说明： Total Passed（事物的总通过数）Total Faild（事物的总失败数）Total Stopped（事物的总停止数）Average Response Time是一个链接，可以打开事务平均响应时间图表。下面给出每个具体事务的情况列表，可以看到以下数据项：Tansaction Name 事务名Minimum 事务最小时间Average 事务平均时间Maximum事务最大时间Std.Deviation 标准方差标准方差，这个数据是描述采样数据离散状态很重要的指标，它又分为以下两种：1.给定样本标准方差，它是估算给定样本而不是整个样本的标准方差，计算公式如下：主要考虑到采样量越大，越能反映真实的情况2.总体样本标准方差，它是估算整个采样样本的标准方差，计算公式如下：当采样数据足够大的时候，上述两种计算方式得出的偏差相差很小。标准方差相对与平均值越大，说明数据越离散，则分布状态相对于平均值波动很大；标准方差相对于平均值越小，说明数据分布越集中，曲线也越平稳。在性爱样值服从正态分布的条件下通过上面的指标结合平均值、最大值、最小值，可以比较清楚地知道采样数据的分布状态及其是否有较大的波动。90Percent（用户感受百分比）这个值说明的采样数据中有90的数据比它小，有10的数据比它大。它的主要作用就是来了解在某个响应时间内有百分之多少的用户。1.2.5 HTTP Responses Summary（HTTP响应摘要）这里给出了服务器返回的状态服务器返回HTTP请求状态HTTP请求返回次数每秒请求数通过Analysis Summary可以对整个性能测试的结果有一个直观的介绍，特别是设置的事务响应时间数据也会显示。Analysis保存后会生成Mercury LoadRunner Analysis Session文件。通过File菜单下的Session Infomation功能可以了解该Session文件的属性，而File菜单下的View Scenario Run Time Settings功能可以查看该报告场景的运行设置。当粗略了解了整个场景的情况后，根据场景之前的目标，可以对整个系统的性能有一定的了解，接着需要对关心的数据进一步的了解和分析。1.3 Graphs（数据图）在场景运行时可以看到一些图，这些图将场景中的数据转化为折线图，方便我们了解当前该数据的状态。在默认情况下，Analysis会自动打开以下几张图。这是系统最基本的几个图，这些图反映了在不同时间段相关计数器的数据变化情况，可以通过在Graphs上右键菜单中的Add New Graphs命令完成添加图的操作，添加后弹出Graphs管理器。在Open a New Graph窗口中，可以得到所有能添加的计数器图形，勾选左下角的Display only graphs containing data选项可以隐藏没有数据的计数器，有数据的计数器则会以蓝色显示在左侧区域。而选中具体的图，在右侧的Graph Description中会有更加详细的介绍。在Graphs Properties中还可以对生成的图表进行一定的属性设置，例如生成的图是使用整个场景的时间还是其中的某一部分时间。在图的下方，Legend窗口会显示途中对象说明信息以及相关数据。1.3.1 VusersVusers用户状态计数器组提供了产生负载的虚拟用户运行转改的相关信息，可以帮助我们了解负载生成的过程。Running Vusers该图可以反映系统形成负载的过程，随着时间的退役，虚拟用户数是如何变化的。Rendezvous当场景中设置了集合点后会出现这张图，该图反映了随着时间的推移各个时间点上并发用户的数目，方便我们了解并发用户数的变化情况。1.3.2 Errors当场景在运行中出现错误时，错误信息将会被保存在该计数器组中，通过Error信息可以了解错误产生的时间和错误的类型，帮助我们定位产生错误的原因。Errors per Second通过每秒错误数可以了解在每个时间点上错误产生的数目，该数据越小越好。通过这个图可以了解错误随负载的变化情况，定位何时系统在负载下开始不稳定甚至出错，配合系统日志可以定位产生错误的原因。1.3.3 Tansactions这里给出了所有和事务相关的数据统计，方便了解被测系统业务处理的响应时间和吞吐量。Average Tansaction Response Time这是我们比较关心的数据之一，反映随着时间的变化事务响应时间的变化情况，时间越小说明处理的速度越快。如果和前面的用户负载生成图合并在一起看，就可以发现用户负载增加对系统事务响应时间的影响规律。响应时间通常随着时间的推移，响应时间逐渐变长。事务的响应时间不应该超过用户的最大接受范围，否则会出现系统响应过慢的问题。Tansactions per Second另一个关键数据是TPS吞吐量，该数据反映了系统在同一时间内能处理业务的最大能力，这个数据越高，说明系统处理能力越强。Tansaction Summary该图给出事务的Pass和Fail的个数，了解负载的事务完成情况。通过的事务越多，说明系统的处理能力越强；失败的事务越少，说明系统越可靠。可以考虑结合前面的每秒错误数进一步分析为什么会出现错误，以及错误发生的时间和该时间产生错误的原因。Tansaction Performance Summary这里会给出事务的平均时间、最大时间、最小时间柱状图，方便分析事务响应时间的情况。柱状图的落差越小说明响应时间的波动较小，如果落差很大，那么说明系统不够稳定。Tansaction Response Time Under Load这里给出了在负载用户增长的过程中响应时间的变化情况，其实这张图也是将Vusers和Average Tansaction Response Time图做了一个Correlate Merge得到的，该图的线条越平稳，说明系统越稳定。Tansaction Response Time（Percentile）这里给出的是不同百分比下的事务响应时间范围，通过这个图可以了解有多少比例的事务发生在某个时间内，也可以发现响应时间的分布规律，数据越平稳说明响应时间变化越小。Tansaction Response Time（Distribution）该图给出的是每个时间段上的事务个数，响应时间较小的分类下的事务数越多越好。1.3.4 Web Resources（网页资源信息）这里给出的是对于Web操作的一些基本信息，这些信息在服务器端也能获得。当Controller的RunTime Setting中的Preferences下的Generated Web performance graphs选项处于开启状态时，该图表才会出现。Hits per Second每秒点击数提供了当前负载中对系统所产生的点击量记录。每一次点击相当于对服务器发出了一次请求，一般点击数会随着负载的增加而增加，该数据越大越好。Throughput这里给出了在当前系统负载下所使用的带宽，该数据越小说明系统带宽依赖越小，通过这个数据能确定是否出现了网络带宽瓶颈（注意这里实用的单位是字节）。HTTP Responses per Second这里给出了每秒钟服务器返回各种状态的数目，该数值一般和每秒点击量相同。点击量是指客户端发出的请求数，而HTTP响应数是指服务器返回的响应数。如果服务器返回的响应数小于客户端发出的点击数，那么说明服务器应答超出负载的连接请求。这个数据如果与前面的每秒点击数吻合，说明服务器能够对每一个客户端请求进行应答。Connections Per Second这里会给出两种不同状态的连接数，即中断的连接和新建的连接，方便用户了解当前每秒对服务器产生连接的数量。同时的连接数越多，说明服务器的连接池越大，当连接数随着负载上升而停止上升时，说明系统的连接池已满，无法连接更多的用户，通常这个时候服务器会返回504错误。可以通过修改服务器的最大连接数来解决该问题。1.3.5 Web Page Diagnostics当在场景中打开Diagnostics菜单下的Web Page Diagnostics功能，就能得到网页分析组图。通过这个图，可以对事务的组成进行抽丝剥茧的分析，得到组成这个页面的每一个请求时间分析，进一步了解响应时间中有关网络和服务器处理时间的分配关系。通过这个功能，可以实现对网站的前端性能分析，明确系统响应时间较长是由服务器端处理能力不足还是客户端连接到服务器的网络消耗导致的。Web Page Diagnostics添加给图先会得到整个场景运行后虚拟用户访问的Page列表，也就是所有页面下载时间列表。然后通过Select Page to Break Down命令选择具体的Page来获得每个请求的相关详细信息。在Diagnostics options选项中提供了以下4大块功能。Download Time这里可以得到组成页面的每个请求下载时间。Component（Over time）这里列出组成页面的每个元素，以及随着时间的变化所带来的响应时间变化。通过这个功能可以分析响应时间变长是因为页面生成慢，还是因为图片资源下载慢。Download Time（Over time）这里提供了针对每个组成页面元素的时间组成部分分析，方便确认该元素的处理时间组成部分。Time to First Buffer（Over time）这里会列出该元素所使用的时间分配比例，是受Network Time影响的多还是Server Time影响的多。Server Time是指服务器对该页面的处理时间，Network Time是指网络上的时间开销。通过分析这4个分析图，我们可以了解到对于事务的响应时间来说，服务器的处理时间不是组成响应时间的主要部分，而网络问题通常会占用超过70的时间，通过Web Page Diagnostics可以准确分析响应时间，避免由于网络延迟或者带宽问题而影响对响应时间的分析和瓶颈定位。Page Download Time Breakdown这张图显示了每个页面响应时间的组成分析，一个页面的响应时间一般由以下内容组成：Client Time：客户端浏览器接收所需要实用的时间，可以不用考虑。Connections Time：连接服务器所需要的时间，越小越好。DNS Resolution Time：通过DNS服务器解析域名所需要的时间，解析受到DNS服务器的影响，越小越好。Error Time：服务器返回错误响应时间，这个时间反映了服务器处理错误的速度，一般是Web服务器直接返回的，包含了网络时间和Web服务器返回错误的时间，该时间越小越好。First Buffer Time：连接到服务器，服务器返回第一个字节所需要的时间，反映了系统对于正常请求的处理时间开销，包含网络时间和服务器正常处理的时间，该时间越小越好。FTP Authentication Time：FTP认证时间，这是进行FTP登录等操作所需要消耗的认证时间，越短越好。Receive Time：接收数据的时间，这个时间反映了带宽的大小，带宽越大，下载时间越短。SSL Handshaking Time：SSL加密握手的时间。Page Download Time Breakdown（Over Time） 这里提供了随着时间的变化所有请求的响应时间变化过程。这里会将整个负载过程中每个页面的每个时间组成部分都做成单独的时间线，以便分析在不同的时间点上组成该页面的各个请求时间是如何变化的。首先找到变化最明显或者时间最高的页面，随后再针对这个页面进行进一步的分析了解时间片长或者变化较快的原因。Time to First Buffer Breakdown这里提供了组成页面时间请求的比例说明（客户端时间/服务器时间）通过这个图，我们可以直观的了解到整个页面的处理是在服务器端消耗的时间长，还是在客户端消耗的时间长，从而分析得到系统的性能问题是在前端还是在后端。Time to First Buffer Breakdown（Over Time）这里给出了在整个负载过程中，每一个请求的Server Time和Client Time随着时间变化的趋势，可以方便定位响应时间随着时间变化的原因到底是由于客户端变化导致的还是服务器端变化导致的。1.3.6 Network Monitor如果在Contoller中添加了Network Delay Time监控后会出现该数据图。这个功能很好但并不是非常直观和方便，建议使用第三方专门的路由分析工具进行网络延迟和路径分析。Network Delay Time这里会给出从监控机至目标主机的平均网络延迟变化情况。Network Sub-Path Time这里给出从监控机至目标机各个网络路径的平均时间。的那个客户端在连接一个远程服务器时，路径并不是唯一的，受到路由器的路由选择，可能会选择不同的路径最终访问到服务器。Network Segemnt Delay Time这里给出各个路径上的各个节点网络延迟情况。这里给出的是路由器和路由器之间网络延迟情况，针对连接而不是路径。1.3.7 Resources资源包括很多种，在Analysis中监控的都是各种系统的计数器，这些计数器反映了系统中硬件或者软件的运行情况，通过它可以发现系统瓶颈。System Resources这里给出了对操作系统计数器的监控，列出了在负载过程中系统的各种资源数据是如何变化的，该图需要在场景中设置了对应系统的监控才出现。Database Server Resources这里给出了数据库的相关资源在负载过程中的变化情况。Web Server Resources这里给出了Web服务器资源在负载过程中的变化情况。计数器分析接着介绍一下各种在性能测试中需要监控的常见计数器名称及其含义和出现瓶颈的特征。我们可以先通过第三方工具对系统进行负载，监控在该负载下各个计数器的最高值是多少。当我们使用LoadRunner进行负载时，如果极速器达到该数据，则可以shuoing这个计数器出现了瓶颈。例如：通过磁盘工具对物理磁盘进行压力测试，在这个过程中可以监控到物理磁盘的读写速度计数器峰值为X。当我们使用LoadRunner进行负载时，如果物理磁盘读写计数器数据逐步变大且最终达到X，就可以说明物理磁盘出现读写瓶颈。Memory 相关内存是第一个监视对象，确定系统瓶颈的第一个步骤就是排除内存问题。内存短缺的问题可能会引起各种各样的问题。Object （对象）Counters （计数器名称）Description（描述）参考值MemoryAvailable Mbytes物理内存的可用数（单位Mbytes）。默认情况下IIS5.0使用50%的可用物理内存，作为IIS的文件缓存（file cache）。IIS基本占用2.5MB，每个附加连接将在此基础上占用10KB左右。至少要有10%的物理内存值MemoryPage/secPage Faults/secPages Input/secPage Reads/secTransitionFaults/sec当处理器向内存指定的位置请求一页（可能是数据或代码）出现错误时，这就构成一个Page Fault。如果该页在内存的其他位置，该错误被称为软错误（用Transition Fault/sec计数器衡量）；如果该页必须从硬盘上重新读取时，被称为硬错误。许多处理器可以在有大量软错误的情况下继续操作。但是，硬错误可以导致明显的拖延。Page Faults/sec是处理器每秒钟处理的错误页（包括软错误和硬错误）。Pages Input/sec是为了解决硬错误页，从硬盘上读取的页数，而Page Reads/sec是为了解决硬错误，从硬盘读取的次数。如果Page Reads/Sec比率持续保持为5，表示可能内存不足。Pages/sec是指为解析硬页错误从磁盘读取或写入磁盘的页数。Page/sec推荐00-20（如果服务器没有足够的内存处理其工作负荷，此数值将一直很高。如果大于80，表示有问题）。这些计数器的值比较低，说明Web服务器响应请求比较快，否则可能是服务器系统内存短缺引起（也可能是缓存太大，导致系统内存太少）。Page Input/sec的值可以衡量出硬错误页发生的速率，通常它的值会大于或者等于PageReads/sec。MemoryCache Bytes文件系统缓存（File System Cache），默认情况下为50%的可用物理内存。如IIS5.0运行内存不够时，它会自动整理缓存。需要关注该计数器的趋势变化。默认情况下为50%的可用物理内存InternetInformationServicesGlobalFile Cache Hits %File CacheFlushesFile Cache HitsFile Cache Hits%是文件缓存命中全部缓存需求的比例，反映了IIS的文件缓存设置的工作情况。而File Cache Hits是文件缓存命中的具体值，File CacheFlushes是自服务器启动之后文件缓存刷新次数，如果刷新太慢，会浪费内存；如果刷新太快，缓存中的对象会太频繁的丢弃生成，起不到缓存的作用。通过File Cache Hits和File Cache Flushes可以得到一个适当的刷新值（参考IIS的设置ObjectTTL 、MemCacheSize 、MaxCacheFileSize）。（ 对于一个大部分是静态网页组成的网站）File Cache Hits%在80%左右属于非常好！MemoryPool Paged BytesPool NonpagedBytes这两个计数器监视服务器上各个进程的分页池字节数和非分页池字节数。在访问数比较固定的情况下， Pool Nonpaged Bytes是比较固定的，如果访问数逐步增加，该值会缓慢的增加。ProcessVirtual Bytes ( 实例inetinfo 、dllhost) Working Se （t 实例inetinfo 、dllhost）Dllhost#n 进程都要添加计数器Virtual Bytes计数器监视IIS5.0保留的虚地址空间的数量，实例化为inetinfo进程(IIS运行的核心)和Dllhost进程（隔离/ 连接池 的应用程序必需的）。Working Set计数器反映了每个进程使用的内存页的数量。系统的内存页（pool Page）只能由操作系统的核心模块直接访问，用户进程不能访问。运行IIS5.0的服务器上，负责web连接的线程以及它需要的一些对象都保存在未分页的池中（nonpaged pool），比如文件句柄和socket连接。ProcessPrivate Bytes指这个处理不能与其他处理共享的、已分配的当前字节数。MemoryCommittedBytesCommitted Byte是指以字节表示的确认虚拟内存。(确认内存是指为磁盘分页文件在磁盘上保留的空间以便在需要将其写回磁盘时使用)。推荐不超过物理内存的75%内存问题主要检查应用程序是否存在内存泄漏。如果发生了内存泄漏，ProcessPrivate Bytes计数器和ProcessWorking Set计数器的值往往会升高，同时Available Bytes的值会降低。内存泄漏应该通过一个长时间的，用来研究分析当所有内存都耗尽时，应用程序反应情况的测试来检验。Processor 相关Object（对象）Counters （计数器名称）Description（描述）参考值SytemProcessor QueueLengthProcessor Queue Length是指处理列队中的线程数。即使在有多个处理器的计算机上处理器时间也会有一个单列队。不象磁盘计数器，这个计数器仅计数就绪的线程，而不计数运行中的线程。如果处理器列队中总是有两个以上的线程通常表示处理器堵塞。小于2。显示在由Web服务器所有处理器共享的队列中等待执行的线程数。处理器瓶颈会导致该值持续大于2。Processor%Processor TimeCPU使用率。这是查看处理器饱和状况的最佳计数器。显示所有CPU的线程处理时间。如果一个或多个处理器的该数值持续超过 90%，则表示此测试的负载对于目前的硬件过于沉重。为多处理器服务器添加该计数器的0到x个实例。小于75%。排除内存因素，如果该计数器的值比较大，而同时网卡和硬盘的值比较低，那么可以确定CPU 瓶颈SystemContextSwitches/secContext Switches/sec指计算机上的所有处理器全都从一个线程转换到另一个线程的综合速率。当正在运行的线程自动放弃处理器时出现上下文转换，由一个有更高优先就绪的线程占先或在用户模式和特权(内核)模式之间转换以使用执行或分系统服务。它是在计算机上的所有处理器上运行的所有线程的Thread: Context Switches/sec的总数并且用转换数量衡量。在系统和线程对象上有上下文转换计数器。如果切换次数到5000*CPU个数和10000*CPU个数中，说明它忙于切换线程而不是处理ASP脚本。Processor%Privileged Time% Privileged Time是在特权模式下处理线程执行代码所花时间的百分比。当调用Windows系统服务时，此服务经常在特权模式运行，以便获取对系统专有数据的访问。在用户模式执行的线程无法访问这些数据。 对系统的调用可以是直接的(explicit)或间接的(implicit)，例如页面错误或中断。不像某些早期的操作系统，Windows除了使用用户和特权模式的传统保护模式之外，还使用处理边界作为分系统保护。某些由Windows为您的应用程序所做的操作除了出现在处理的特权时间内，还可能在其他子系统处理出现。ThreadContextSwitches/sec（ 实例化inetinfo和dllhost 进程如果你决定要增加线程字节池的大小，你应该监视这三个计数器（包括上面的一个）。增加线程数可能会增加上下文切换次数，这样性能不会上升反而会下降。如果十个实例的上下文切换值非常高，就应该减小线程字节池的大小。ProcessorInterrupts/sec%DPC Time这两个计数器能够反映处理器用在处理中断以及推迟处理调用的时间。Interrupts/sec指处理器每秒钟接收并维护的硬件中断的平均值。正常的线程操作在中断时悬停。大多数的系统时钟每隔10毫秒中断处理器一次，形成了间隔活动的后台。如果处理器使用率超过90%且 Interrupt Time大于15%，则处理器可能负荷过重，并发生中断。判断应用程序是否存在处理器瓶颈的方法：如果Processor Queue Length显示的队列长度保持不变（=2）个并且处理器的利用率%Processor Time超过90%，那么很有可能存在处理器瓶颈。如果发现Processor Queue Length显示的队列长度超过2，而处理器的利用率却一直很低，那么或许更应该去解决处理器阻塞问题，这里处理器一般不是瓶颈。如果系统由于应用程序代码效率低下或者系统结构设计有缺陷而导致大量的上下文切换（Context Switches/sec显示的上下文切换次数比较大），那么就会占用大量的系统资源。如果系统的吞吐量降低并且CPU的使用率很高，并且此现象发生时切换水平在15000以上，那么意味着上下文切换次数过高同时还可以比较Context Switches/sec和%Privileged Time来判断上下文切换是否过量。如果后者的值超过40%，且上下文切换的速率也很高，那么应该检查为什么会产生这样高的上下文切换。网络吞吐量以及带宽Object（对象）Counters （计数器名称）Description（描述）参考值NetworkInterfaceBytes Total/secBytes Total/sec为发送和接收字节的速率，包括帧字符在内。判断网络连接速度是否是瓶颈，可以用该计数器的值和目前网络的带宽比较该计数器的值和目前网络的带宽相除，结果应该小于50%MaximumConnections、Total ConnectionAttemptsMaximum Connections ：“最大连接数”是和Web服务同时建立起的最大连接数。Total Connection Attempts：“连接尝试总数”是从服务启动时利用Web服务尝试连接的总数。该计数器应用于全部所列的实例。磁盘相关Object（对象）Counters （计数器名称）Description（描述）参考值NetworkInterfaceBytes Total/secBytes Total/sec为发送和接收字节的速率，包括帧字符在内。判断网络连接速度是否是瓶颈，可以用该计数器的值和目前网络的带宽比较Processor%Processor Time% Privileged TimeCPU使用率该计数器对应于处理器执行Windows 2000内核命令（ 如处理SQL Server I/O请求）所用时间的百分比。如果 Physical Disk计数器的值很高时该计数器的值也一直很高，则考虑使用速度更快或效率更高的磁盘子系统。PhysicalDisk%Disk Time% Disk Time指所选磁盘驱动器忙于为读或写入请求提供服务所用的时间的百分比。如果三个计数器都比较大，那么硬盘不是瓶颈。如果只有%Disk Time比较大，另外两个都比较适中，硬盘可能会是瓶颈。在记录该计数器之前，请在Windows 2000的命令行窗口中运行 diskperf -yD。若数值持续超过 80%，则可能是内存泄漏。PhysicalDiskAverage DiskQueue Length指读取和写入请求(为所选磁盘在实例间隔中列队的)的平均数。PhysicalDiskAverage DiskRead QueueLength指读取请求(为所选磁盘在实例间隔中列队的)的平均数。PhysicalDiskAverage DiskWrite QueueLength指写入请求(为所选磁盘在实例间隔中列队的)的平均数。PhysicalDiskAverage Disksec/Read指以秒计算的在此盘上读取数据的所需平均时间。PhysicalDiskAverage Disksec/Transfer指以秒计算的在此盘上写入数据的所需平均时间。PhysicalDiskDisk Reads/sec指在此盘上读取操作的速率。PhysicalDiskDisk Writes/sec指在此盘上写入操作的速率。判断磁盘瓶颈的方法是通过以下公式来计算：每磁盘的I/O数= 读次数+（4 *写次数） / 磁盘个数如果计算出的每磁盘的I/O数大于磁盘的处理能力，那么磁盘存在瓶颈。Web 应用程序这里以ASP.NET开发的Web应用程序为例进行说明。Object（对象）Counters （计数器名称）Description（描述）参考值ASP.NETApplicationsRequest/SecRequest Executing每秒执行的请求数。当前执行的请求数。如果Request/Sec的值比较小，你的Web程序可能是瓶颈ASP.NETRequest WaitTimeRequest ExecutingTimeRequest Queued最近的请求在队列中等待的毫秒数。执行最近的请求所用的毫秒数。等候处理的请求数。该计数器应保持接近0。超过IIS队列长度会出现“服务器太忙”错误。Request WaitTime和RequestQueued在理想状况下应该接近0，如果这两个值太大，那么需要重写代码提高性能IIS5.0Object（对象）Co