摘要
本文为您说明在 windows 2000 server 上执行 internet information service 5.0 时，如何调整web服务器。同时进一步讨论系统性能监视及测试的重要性，并且说明软件、硬件，以及工具软件的相关注意事项。其中『windows 2000 及 iis 5.0 中的功能及设置』一节特别说明iis 和 windows 2000 中新的功能与设置。附录中另外还提供许多实用的技巧、关于metabase 的注册表与设置，以及供您参考的各种资源。虽然这份文件主要是针对 iis 5.0，不过其中许多题材对 iis 4.0 的管理员也很有参考价值。
此白皮书中所含之信息代表此文件发表日当天，microsoft 公司对其中所讨论议题的当前观点。因为 microsoft 必须响应市场的变化，因此它不应被解读为 microsoft 的承诺，而且在发表日之后，microsoft 不保证其中任何信息的正确性。
本白皮书仅供信息参考。在此文件中，microsoft 不作任何明示或暗示的保证。
microsoft、windows 及 windows nt 是 microsoft corporation 在美国及 (或) 其它国家中的注册商标或的商标。
文件中所提之其它产品及公司名称，则可能为该公司所有之商标。
microsoft corporation o one microsoft way o redmond, wa 98052-6399 o usa
目录
1、简介
2、将性能调整当作一种艺术
3、为什么要调整 web 服务器？
4、要调整的内容
监视硬件
内存
处理器容量 (processor capacity)
网络容量、等待时间及带宽
磁盘最佳化
安全性
监视网络应用程序
调整 web 应用程序
监视及测试服务器性能的工具
windows 2000 及 iis 5.0 中的功能及设置
调整及疑难排除的建议
5、测试、试探及正式启用
附录 1：性能设置
metabase 设置
注册表设置
附录 2：windows 2000 web server 性能最佳化的技巧
附录 3：asp 缓存处理
附录 4：资源
简介
microsoft windows 2000 server 的 internet information services (iis) 5.0 可让您的 web 服务器提供性能增强及更高的可用性。通过操作系统及 iis 之间更紧密的集成，您现在可以调整服务器，让它比之前的版本更快且更有效率地执行。
这份文件是针对负责监视及调整在 windows 2000 及 iis 上执行的网站的 web服务器管理员而设计的。虽然其中涵盖一些 web 应用程序测试及调整的讨论，但是这份文件的主要阅读者并不包含 web 应用程序开发人员。
这份文件讨论了调整 web 服务器性能的方法。它也讨论了为什么调整性能很重要，同时还讨论在调整 iis 5.0 web服务器时会牵涉到的硬件、软件及测试问题。最后，它还包括一段针对可用来监视及测试服务器性能的工具所作的简短讨论。虽然其中有段讨论是与调整网络应用程序时会发生的问题比较有关，但这份文件不会就此议题深究。如需此议题或其它主题的链接及参照，请参阅这份文件的〈资源〉小节。
将性能调整当作一种艺术
调整服务器性能的方式就像 internet 上的网站一样的多。根据贵公司想要在 web上如何呈现所作的选择而定，您可能必须负责将您的 web 服务器调整成最适合于提供静态的网页或动态编译的应用程序页。每一种站点会有不同的硬件、应用程序的需求，以及 windows 2000 和 iis 性能调整选项。另一个需要考虑的是您实际上希望网络处理的传输量，特别是尖峰负载期间。负载量会影响web服务器的性能，而不同的商业活动 (例如贵公司宣传活动的频繁程度) 会决定您的网站必须处理的用户请求数目。您应该清楚知道这些负载的内容，并且在让它们上线之前，先在网络上仿真它们。有几个原因可以说明为什么没有任何关于如何调整web服务器而提出的金玉良言。
调整web服务器的性能应该被视为一种艺术，而不是一种科学：尝试及错误是决定何种设置及硬件对您的网站需求最适合的重要手法。虽然了解本文所讨论的技术性设置很重要，但了解您的应用程序或网站的设置文件，以及它们在不同状态下会如何运行也同样重要。就像一位画家用炭笔简单绘出一种他想如何完成一幅画的感觉，您同样应备有一个计划来评估您网站服务器的性能。第一个步骤是在您要测试的网站上建立一个受控制的环境、并进行预测负载的性能分析，然后在让 web 服务器在 internet上发布之前，先测量该环境中的性能。因为服务器的性能会因不同期间存取您网站的浏览器传输量产生明显的差异，所以请确定在不同负载下观察与记录您的网站测试，以获取网络上活动的真实画面。在此期间，您可能要有一份备份计划，以防止您的网站在部署前后因任何问题造成停机。
若要提高服务器性能，请检查系统的每一部份，以找出潜在的瓶颈。造成瓶颈的原因可能是硬件设置不恰当或不正确，或是 iis 或 windows 2000中的软件设置所致。完善的监视计划会检查各方面的性能。
一旦得知您的服务器执行的情形，便可开始针对提高性能作响应的改变。您应该一次作一个改变，并且先有个经过测试的恢复计划，否则想评估个别改变的影响会变得困难。
在完成每一个改变之后，请继续观察此改变是否已达到预计的效果。如果发现非预计的副作用产生时，你就可以执行恢复程序，将服务器还原成它的上一个状态。由于对一个资源所作的改变会引发其它区域出现瓶颈，所以在改变后检查所有资源的性能是很重要的。一旦评估完一个改变的影响之后，便可以决定有无必要作进一步的改变。
为什么要调整 web 服务器？
调整您的 web 服务器有几个有利于商业上的考虑。第一，因调整而提高性能，进而缩短了等待服务器响应的时间，可让用户获得更好的经验。调整将有助于避免使用上的瓶颈，并可让你的硬件使用更久，并且不用经常升级或是拉长为你的 web farm 购置新服务器时间。如此能让您在真正需要购买例如内存、处理器或网卡等零件时还有预算。
除了这些商业上的考虑之外，还有一些技术上的原因与调整web 服务器性能有关。调整可让您充分利用既有的硬件，并决定此时及日后要执行哪些升级。通过调整 web 服务器，您可以最大化网络应用程序的生产力并最小化响应时间，同时判定其中哪几个应用程序正按请求处理高负载。
需要调整的内容
调整 web 服务器的困难之一是如何精确地知道要调整什么。基于这个理由，在调整设置、硬件、web 服务器，或甚至升级到 windows 2000及 iis 5.0 之前，先监视 web 服务器是很重要的。这点是再怎么强调都是不够的：收集关于您服务器的基准信息可让您了解它们的行为，并精确制定出web 服务器性能的目标。您可以使用内建在操作系统及 iis 中的 [性能监视器] 及 [性能计数器] 来建立此基准。一旦收集基准信息后，请分析它们以判定在作一个改变 (不论是添加 ram 或调整内部 iis 设置也好) 之前，可能会有哪些性能问题的潜在原因。一旦作了改变，请记得再次监视服务器。您所作的改变可能会在您系统的其它组件上造成无法预测的影响。
这个主题分成五小节：硬件调整议题、web 应用程序调整议题、用来监视及压力测试系统的工具、安全性考虑、影响 web 服务器性能的 windows 2000 及iis 5.0 内部设置。
请注意，这些议题相互之间并无关联。要从升级硬件来修改内部设置的话，调整web 服务器将需要您仔细地监视任何改变对web 服务器性能的影响。
监视硬件
内存
通常系统中所发生的问题是由于内存不足所导致出来的问题，这是较常见的。您应该先监视内存，确认您的服务器有足够的内存，再于其它组件上增减。若要执行 windows 2000 上的 iis 5.0，一个专用web 服务器所需 ram 的最小容量是 128mb，但最好是 256mb 到 1gb。额外的内存对于电子商务站点、含大量内容的站点、处理高传输量的站点尤其适用。因为「iis 文件缓存」默认是使用最多一半可用的内存，因此您备有的内存越多，「iis 文件缓存」就越多。
附注：windows 2000 advanced server 最多可支持 8gb 的 ram，但是「iis文件缓存」将不会利用 4gb 以上的 ram。
若要判定服务器上目前的内存容量是否能满足您的需求，请使用内建在windows 2000 中的 [性能] 工具 (先前称为 perfmon)。属于 [性能] 工具一部份的 [系统监视器] 会随着计数器指数的改变而以图形显示。
此外，请留意您的缓存设置--只添加内存不一定能够解决性能问题。您必须留意 iis 缓存处理设置以及它们如何影响服务器的性能。如果这些设置对放置在服务器上的负载并不适当的话，则可能不是发生内存不足，而是造成性能瓶颈。这些缓存设置的相关信息，请参阅本文中〈iis 设置〉及〈附录 1：性能设置〉两节中的说明。如需关于使用 asp 及 iis 缓存的讨论，请参阅〈附录 3：asp 缓存处理〉。
附注：在使用 [性能] 计数器来监视性能时，可以在 [添加计数器]对话框中任选一个计数器，并按一下 [说明] 来查看该计数器的说明。
请记录下列计数器，以判定是否有和内存相关的性能瓶颈：
· 内存︰可用的字节。试着保留至少 10% 的可用内存，以供尖峰时间使用。请记住 iis 5.0 默认最多会使用 50% 的可用内存，供文件缓存使用。
· 内存︰page faults/sec、memory︰pages input/sec及memory︰page reads/sec。如果有个程序请求内存中的一页，但系统无法在所需的位置上找到它，就会构成一个分页错误。如果此页位于内存中的其它位置，则此错误便称为软件分页错误。如果必须从磁盘获取此页，则此错误便称为硬件分页错误。大部分的处理器可以处理大量的软件错误而不会引起任何后果。但是，硬件错误却会导致严重的延迟。「page faults/sec」是指处理器处理错误页 (包括硬件及软件分页错误) 的整体速度。「pages input/sec」是指为了解决硬件分页错误而从磁盘读取的总页数。「pages reads/sec」是指为了解决硬件分页错误而读取磁盘的次数。「pages input/sec」会大于或等于「page reads/sec」，并且能够清楚地让您了解硬件分页错误率。如果这些数字都很低，则服务器应该可以快速地响应请求。如果很高，则可能是因为您用了太多的内存在缓存处理上，而没有留足够的内存供系统的其它部份使用。您可能必须在服务器上添加 ram 的容量，但是降低缓存的大小也是可行的。
· 内存︰cache bytes、internet information services global︰file cache hits %、internet information services global︰file cache flushes，及 internet information services global︰file cache hits。第一个计数器「memory : cache bytes」显示「文件系统缓存」的大小，其默认为最多使用 50% 的可用物理内存。由于当缓存的内存快要不足时，iis 会自动调整它，所以请留意这个计数器行进的方向。第二个计数器是缓存存取次数与缓存请求总数的比例，它会反应出此「iis 文件缓存」的设置表现的好不好。对于主要由静态文件组成的网站来说，80% 以上的缓存存取次数应是个不错的数字。请比较最后两个计数器的记录文件「iis global: file cache flushes」及「iis global︰file cache hits」，以判定您是否正以适当的速度将对象从您的缓存清除。如果清除发生太快，则对象可能会比其应有的频率更常从缓存中清除出来。如果清除发生太慢，就会浪费内存。请参阅〈附录 1︰性能设置〉中关于objectcachettl、memcachesize及 maxcachedfilesize 对象的说明。
· page file bytes : total。这个计数器反应出系统上分页文件的大小。分页文件越大，系统提供给它的内存就越多。windows 2000 会自动在系统磁盘驱动器上建立一个分页文件；您可以在每一个逻辑磁盘上建立一个分页文件，并改变现有文件的大小。事实上，将一个分页文件等量分配到不同物理硬盘上可提升分页文件的性能 (请使用不含您的网站内容或记录文件的硬盘)。请记住，系统磁盘驱动器上的分页文件至少应是物理内存的两倍大，这样系统才能在发生当机时，将整个 ram 的内容写入磁盘中。
· memory: pool paged bytes, memory: pool nonpaged bytes, process: pool paged bytes: inetinfo, process: pool nonpaged bytes: inetinfo, process: pool paged bytes: dllhost#n, and process: pool nonpaged bytes: dllhost。「memory : pool pages bytes」及「memory : pool nonpaged bytes」会监视服务器上所有进程的缓冲池空间。这里列出的其它计数器会监视由 iis 5.0 直接使用的缓冲池空间，不管是用于您服务器上进行的 inetinfo 进程 (即 iis 在其中执行的进程)，或是 dllhost 进程 (即把 web 应用程序从 inetinfo 隔离或把 web 应用程序放在缓冲池中一起执行的进程)。请确定监视服务器上所有 dllhost 例项的计数器；否则您将无法取得 iis 使用的缓冲池空间的正确数值。系统的内存缓冲池会保留应用程序及操作系统建立及使用的对象。内存缓冲池的内容只能在专用模式下存取。换言之，只有操作系统的核心才能直接使用内存缓冲池；用户进程则无法使用。在执行 iis 5.0 的服务器上，服务连接的线程是与该服务使用的其它对象 (例如文件句柄及通讯端) 一起存放在未分页的缓冲池中。
除了添加更多 ram 外，请尝试下列技巧以增强内存性能︰改进数据组织、尝试映像或等量划分磁盘、以 isapi 或 asp 应用程序取代 cgi 应用程序、加大分页文件、重新计数「iis 文件缓存」、删除不需要的功能，以及将「文件系统缓存」的平衡值改成「iis 5.0 工作设置」。其中最后一个技巧将在本文稍后详细说明。
若想取得影响这些计数器数字的 windows 2000 及 iis 5.0 设置的详细讨论，请参阅〈附录 1︰性能设置〉。
处理器容量 (processor capacity)
随着用户请求从网站获得快速的响应时间，以及在这些网站上不断增加的动态内容，更加需要利用到快速、有效的处理器用量。当一或多个进程几乎耗尽所有处理器时，就会发生瓶颈。这会迫使准备好执行的进程线程必须在队列中等待处理器时间。添加诸如内存、磁盘或网络连接等其它硬件，以试图克服处理器瓶颈的无效，反而会让状况更加恶化。
windows 2000 server 上的 iis 5.0 能有效地调配二至四个处理器。如果您正在考虑添加额外的处理器，请衡量您网站的业务需求。例如，如果您在服务器上主控的大多是静态内容，则备有两个处理器的计算机应已足够。如果主控的是会动态生成的内容，则备有四个处理器的安装可以解决您的问题。不过，如果站点上的工作量需要大量的 cpu，则单一计算机将无法符合请求的数量。如果您的站点是这种情况，则应将它调配成跨多台服务器。如果已经在多重服务器上执行您的站点，请考虑添加更多服务器。
不过，您应该明了 windows 2000 及 iis 5.0 的最大性能增益来自于解决内存问题。在决定改变web 服务器上处理器的个数之前，请先排除内存问题，再监视下列「性能计数器」。
· system : processor queue length。这个计数器显示了在由系统上所有处理器共享的队列中，等候执行的线程数目。如果这个计数器提供了两个或以上的自变量值，则表示手边就有一个处理器瓶颈。
· processor : %processor time。处理器瓶颈的特征是︰当网络适配卡及磁盘 i/0 仍保持正常的低容量时，「处理器︰% 处理器时间」的数字却很高。在多处理器的计算机上检查「processor : %processor time」计数器来找出任何不平衡的情况是个很好的作法。
· thread : context switch/sec:dllhost#n, thread: context switchs/sec:inetinfo=>thread#, system: context switches/sec。如果决定增加线程缓冲池的大小，便应该监视这里列出的三个计数器。增加线程数目可能会增加内容切换的数目，因而造成性能不增反降。每一个请求有 10 个或以上内容切换就已经是相当高的数字了；如果出现这些数字，请考虑降低线程缓冲池大小。想通过测量连接及请求来得出线程及整体性能之间的平衡点是不容易的。每次当您调整线程时，请接着监视整体性能，以检查性能是增进还是降低。若要判定是否应该调整线程计数，请将进程中的每一个线程数目和处理器时间拿来和总处理器时间作比较。如果线程持续忙碌，但并没有使用全部的处理器时间，则建立更多线程对性能会有帮助。不过，如果所有线程都很忙，而且处理器已快接近最大容量，则最好将载量分配给更多服务器，而不要增加线程的数目。请参阅本文中〈附录 1︰性能设置〉的aspthreadgateenabled 及 aspprocessorthreadmax metabase 属性。
· processor: interrupts/sec 及 processor: %dpc time 。使用这些计数器来判定处理器应花多少时间在中断及延缓的过程调用上 (dpc)。有两个因素可能是处理器上负载的其它来源。客户端请求是这两个因素的主要来源。有些新型网络适配卡包括中断减缓，也就是说当中断程度太高时，它会将中断累积在缓冲区中。
跨多台计算机调配
如果处理器问题持续存在，请尝试使用 network load balancing (nlb) 或硬件负载平衡器跨多台计算机调配您的站点。虽然使用其中一种方法来设置 web farm 会增加一层复杂性，并产生一些其它问题，但如果您的网站规模够大的话，这个操作可能会替您解决一些性能问题。nlb 的相关信息，请参阅 network load balancing technical overview。
网络容量、等待时间及带宽
基本上，网络是客户端向服务器传送请求的线路。它花在您的服务器上来回传递这些请求及响应的时间，对用户能察觉的服务器性能来说是个最大限制因素之一。这种请求-响应的循环时间就称为等待时间，等待时间对于web 服务器管理员来说几乎是无法控制的。例如，您对 internet 上速度缓慢的路由器，或是客户端及服务器之间的物理距离所能作的处理实在不多。
在主要是由静态内容组成的站点上，网络带宽最有可能是性能瓶颈的来源。即使是一般的服务器也可能用满一条 t3 连接 (45mbps) 或 100mbps fast ethernet 连接。您可以通过调整当前的连接，或尽可能最大化有效的带宽来改善这些问题。
测量有效带宽最简单的方法是判定您的服务器是以哪个速度传送及接收资料的。有一些「性能」计数器可以测量您的服务器上许多组件中的数据传输。包括 web、ftp 及 stmp 服务、tcp 对象、tp 对象及「网络接口」对象上的计数器。每一个计数器都会反应不同的 open system interconnectivity (osi) 层。这些计数器及其分析的详细清单，请参阅随 windows 2000 server resource kit 一起发行的《internet information services 5.0 资源指引》。请特别参阅〈监视及调整服务器〉该章中的〈网络 i/o〉小节。不过，若要开始使用下列计数器︰
· network interface: bytes total/sec。若要判定您的网络连接是否正在存在瓶颈，请比较「network interface: bytes total/sec」计数器与您的网络适配卡总带宽。若要在传送量中留些空间供尖峰时间用，则不应常使用超过 50% 的容量。如果这个数字十分接近连接的容量，而处理器及内存的使用都很适中，则此连接也会是个问题。
· web service: maximum connections 及 web service: total connection attempts 。如果您正在计算机上执行的其他服务也使用网络连接，则应监视「web service: maximum connections」及「web service: total connection attempts」计数器，以检查您的web服务器是否能够尽可能地使用它需要的连接数目。请记得将这些数字与内存及处理器使用量作比较，如此才能确定连接就是问题，而不是其它组件有问题。
磁盘最佳化
因为 iis 5.0 会将记录文件写入磁盘上，所以在一般磁盘活动中，甚至会有高达 100 % 的客户端缓存存取次数。一般来说，如果有记录以外的大量磁盘读取活动，即表示系统上有其它区域需要调整。例如，硬件分页错误会导致大量的磁盘活动，但它们表示 ram 不足。
存取内存比存取磁盘快约 1 百万倍；无疑地，通过搜寻硬盘来响应请求将降低性能。您主控的网站类型对硬磁盘搜寻的频率影响很大。如果您的网站上有个随机存取的超大型文件集、如果网站上的文件大多是超大型，或如果 ram 的容量很小，则 iis 便无法在 ram 中维护文件的复本，供更快速的存取。
当您的服务器忙碌时您通常会使用「physical disk」计数器来监视，磁盘读取次数的允许范围。如果 ram 够大，则大部分的连接会导致缓存存取，除非您有个存放在同一台服务器上的数据库，而且用户端正在提出不同的查询。这种情况会阻止缓存处理。请注意记录也会导致磁盘瓶颈。如果您的服务器上没有明显与大量磁盘有关的问题，但却看见大量的磁盘活动，则应立即检查服务器上的 ram 容量，以确定是否有足够的内存。
若要确定磁盘存取的频率，请记录下列计数器︰
· processor: % processor time, network interface connection: bytes total/sec及physicaldisk: % disk time。如果这三个计数器的值都很高，则硬盘不会引起站点的瓶颈。但是，如果「% disk time」的值很高，但处理器及网络连接并没有饱和，则硬盘可能会造成瓶颈。如果在您的服务器上没有启用「physical disk」计数器，请开启指令行，并使用diskperf -yd 指令。
安全性
在性能与用户关心的web服务器安全性之间找出平衡点是您将面对的重要问题之一，尤其是当您经营电子商务网站更是如此。因为安全的网络通讯比不安全的网络通讯需要更多资源，所以知道何时应使用不同的安全技术 (如 ssl 通讯协议或 ip 地址检查)，以及何时不该使用它们是很重要的。例如，您的首页或一个搜寻结果页几乎不需要通过 ssl 执行。但是，当用户进入一个结帐或采购网页时，您就需要确定该页是安全的。
如果使用 ssl，则请注意，建立初始连接比重新连接已经在 ssl 有效期缓存中的安全信息的成本要高上五倍。ssl 有效期缓存的默认超时时间，已经从 windows nt 4.0 中的 2 分钟改变为在 windows 2000 中的 5分钟。一旦这个资料被清除时，客户端及服务器就必须建立一条全新的连接。如果打算支持长时间的 ssl 有效期，则可利用 servercachetime 注册表设置来延长这个超时时间。如果预计会有几千位用户使用 ssl 连接到您的站点，则较安全的方式是预估需要 ssl 有效期持续的时间，然后将 servercachetime 参数设成比您预估的时间稍长一些。请勿将超时时间设置值超过此参数，否则您的服务器会在缓存中留下旧的资料。此外， 请确定 http keep-alives 已启用。除非浏览器明确地关闭连接，否则 ssl 有效期与 http keep-alives 并用时不会超时。
除了具备高性价比的所有安全性技术外，windows 2000 及 iis 5.0 安全性服务也整合到一些操作系统服务中。这表示您无法从这些服务的其它领域个别监视安全性性能。反之，测量安全性是否消耗系统资源最常用的方式是执行测试，分别比较有安全性功能及没有安全性功能时的服务器性能有何不同。此测试在进行时必须使用固定的工作量及固定的服务器设置，让安全性功能成为唯一的变量。在测试期间，您可能需要测量下列项目︰
· 处理器活动及处理器队列︰验证、ip 地址、检查、ssl 通讯协议，及加密安全性是需要特别处理的安全性功能。您可能会在专用模式或用户模式中看见增加的处理器活动，以及内容切换与中断的比率增加。如果服务器中的处理器不足，无法处理增加的负载，便可能形成队列。密码加速器之类的硬件在这里可能会有所帮助。
· 如果正在使用 ssl 通讯协议，则 lsass.exe 可能会耗用惊人的 cpu 容量。这是因为 ssl 进程是在这里进行。这表示习惯在 windows nt 中监视 cpu 使用情况的管理员会看见 inetinfo.exe耗用较少的处理器，但 isass.exe 却耗用很多。
· 使用的物理内存︰安全性需要系统存放及获取更多用户信息。此外，ssl 通讯协议可以使用长识别码-40 位到 1,024 位-来加密及解密信息。
· 网络传输量：您也可能会在 iis 5.0 的服务器，及用来验证登入密码并验证 ip 地址的域控制站之间，看见增加的传输量。
· 等待时间及延迟︰复杂的安全性特性 (如 ssl) 导致最明显的性能降级就是花在加密及解密的时间和精力，因为这两者会使用大量的处理器循环。从使用 ssl 通讯协议的服务器上下载文件比不使用 ssl 的服务器下载文件会慢上10 到 100 倍。
如果服务器不仅用来执行 iis 5.0，还作为域控制站使用，则域服务所耗用的处理器用量、内存、网络及磁盘活动的比例可能会因为这些资源上而带来明显的增加。增加的活动足以让 iis 5.0 服务无法有效地执行。强烈建议您避免在域控制站上执行 iis 5.0。
监视网络应用程序
使用一个设计完善且已彻底测试过的应用程序来升级或替换一个撰写不佳的应用程序，可以显著地增强性能 (有时可增加到三倍)。不过，请记住您的网络应用程序可能会受到后端等待时间的影响 (例如 a4/400 等较传统系统)。远程资料来源会引起性能问题的原因很多。如果开发人员将应用程序设计成从另一个网站上取得资料，但目标网站却出现当机，则该应用程序会在您的服务器上造成瓶颈。如果应用程序正在存取远程 sql 服务器的数据库，则该数据库可能无法跟上传送给它的请求。因为您可能是自己站点的 sql 数据库管理员，所以要监视这些位于远程的服务器可能会有困难。更糟的是，您可能没有这些数据库服务器或其它后端服务器的控制权。如果可以的话，请监视与您的应用程序一起使用的后端服务器，并将它们调整得与您的web服务器一样的好。
若要判定您的 web 服务器是否正在您的服务器上造成瓶颈，请监视下列性能计数器︰
· active server pages︰requests/sec、active server pages︰requests executing、active server pages︰request wait time、active server pages︰request executing time 及 active server pages︰requests queued。如果正在服务器上执行 asp 应用程序，则这些计数器可让您了解这些应用程序执行的状况有多好。「active server pages︰requests/sec」不含静态文件或其它动态内容的请求，它会根据 asp 网页的复杂度及您 web 服务器的容量明显地变动。如果这个计数器在服务器上的传输量处于尖峰期间出现低值的话，则您的应用程序可能会导致瓶颈。「requests executing」显示目前正在执行的请求数目；「request wait time」显示最近的请求在队列中等待的毫秒数；「request execution time」显示最近的请求花在执行上的毫秒数。理想的状态是「requests queued 」及「request wait time」应保持接近 0，但它们会在不同的载量下起伏变动。最大「requests queued」数目是由 asprequestqueuemax 的 metabase 设置来决定。如果达到此限制，则客户端浏览器将显示 [http 500/ 服务器太过忙碌]。如果这些数字大幅偏离了预计的范围，则您的 asp 应用程序可能必须重写才能提高性能。由于「request execution time」并非一个平均值，所以会有些误差。例如，如果您固定会接收一页 30 个请求，每页是以 10 毫秒到 500 毫秒的速度执行每一个请求，则即使平均执行时间超过 25 毫秒，但是计数器可能会显示 10 毫秒。要为「requests executing」说出一个最适当的值很难。如果页面执行得很快，而且不会等待 i/o (加载文件或提出数据库查询)，则这个数字可能会比较低 (比机器忙碌时的处理器个数低一些)。如果页面必须等待 i/o，则执行的页数可能会较高 (接近 aspprocessorthreadmax 乘以处理器个数的值)。如果「requests executing」的值是高的、「requests queued」是大的，而 cpu 的使用率是较低的，则可能必须增加 aspprocessorthreadmax。启用时，传送的线程会试着最佳化「requests executing」。用户的响应时间会与「request wait time」加「request execution time」加网络等待时间的和成比例。
· web service: cgi requests/sec及 web servcie: isapi extension requests/sec 会报告您的服务器是以哪个速度处理 cgi 及 isapi 应用程序请求。如果这些值在负载增加时降低，则可能必须请求应用程序开发人员重新检查他们的程序代码。
附注-asp 是个「isapi extension」，包含在第二个计数器中。
· web service: get requests/sec及web service: post requests/sec 反应这两个常见 http请求类型是以哪个速度出现在您的服务器上。「post request」通常是用于窗体，并传送到 isapi (包括 asp) 或 cgi。「get request」会记录几乎所有来自浏览器的其它请求，并包括静态文件、aps 与其它 isapi 的请求，以及 cgi 请求。
