摘要
本文为您说明在 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 请求。
调整 Web 应用程序
IIS 5.0 对于服务静态 HTML 网页及配上默认的设置值基本就已足够了。如果您的站点主要是静态内容，则许多性能问题可能会与硬件有关。IIS 5.0 为 Web 应用程序提供不错的性能，但若想获得最佳的性能，还需要一些额外的调整。当然，不管服务器软件如何增强，与 Web 应用程序设计及程序代码有关的最佳经验方法的问题依然会存在。虽然本文没有试图讨论调整 Web 应用程序的细节，但本节仍提供一些使它们执行更快的指导及建议。在规划及测试您的 Web 应用程序时，请先考虑下列事项，然后再到实际联机运行的服务器上执行它们。
第一，ISAPI 应用程序比 Active Server Pages (ASP) 应用程序执行得更快，虽然 ASP 的开发费用远比 ISAPI 低。这两种应用程序都比 CGI 应用程序执行得更快。
第二，因为静态文件不会有动态文件才有的处理负载，或引起磁盘活动，所以您应该尽可能使用它们。除了使用静态文件外，您的应用程序应尽可能将处理负载推到客户端，以避免网络等待时间。如此也能节省服务器端的资源，并让更新在很段时间内完成。有个常用的范例是加一个客户端的小程序代码，来检查电子邮件地址组成是否正确。
另一个技巧是确定在您的实际上线运行服务器上已关闭 ASP 的侦错功能。如果启用侦错，则必须将 AppAllowDebugging Metabase 属性设为 FALSE。相关信息，请参阅〈附录 1︰性能设置〉。
尽可能地为所有图像及 HTML 设置「过期」标题，让它们可以存放在客户端的缓存中。相关信息，请参阅本文中的〈调整及疑难排除的建议〉小节。
如果 Microsoft Visual Basic_ 对象是以 Apartment 线程处理的(非 Java 或大部分 C++ 对象)，请从「ASP 应用程序及有效期」状态中删除它们。
只有在必要时才使用 Secure Sockets Layer (SSL)。使用 HTTPS 通讯协议比使用标准 HTTP 贵很多。请确定传送中的信息 (可能是敏感资料如信用卡号) 的价值是否值得您付出增加的费用。安全性调整问题的相关信息，请参阅本文中的〈安全性〉小节。
进程隔离也会影响 Web 应用程序的性能。IIS 5.0 Web 应用程序默认是在进程外的缓冲池 (中度保护) 中执行。接受进程隔离对性能的影响总比冒着服务器停机或资料遗失的风险来的安全，例如因应用程序当机而破坏它与 IIS 5.0 共享的 Ientinfo 进程时就会导致这些风险。有关这个主题的深入讨论，请参阅本文中的〈进程隔离〉小节。
若要增进生产环境中的数据库驱动性能，请使用 Microsoft SQL Server。由于 IIS 及 SQL Server 在足够的内存下执行的情况最好，因此请尝试将资料库存放在不同于 Web 服务的服务器上。在这种情况下，经由网络跨计算机通讯通常比单一计算机上的通讯还快。当 SQL Server 及 IIS 存放在同一台服务器上时，就会经常因为内存不足或循环不够而导致性能降低。此外，请务必建立及维护适当的索引。如此才能最小化数据库查询的输入和输出。最后一点，请尽量多利用被存储的过程(stored procedured)。它们比设计来执行相同工作的 ASP 脚本文件所需的执行时间更少，而且更容易撰写。
一般来说，如果您有个超过 100 行 (使用 #include 指令来计算添加文件中的程序代码行数) 的 ASP 脚本文件，请考虑建立一个 COM+ 组件来提供相同的功能。如果能撰写得很有效率，并且经过正确地的测试，则 COM++ 组件可以为同一动态页提供 20 到 30 倍处理一个脚本文件的速度。使用 #includes 测量 ASP 脚本文件最简单的方式是将扩展名从 .asp 改为 .stm，并使用您的浏览器开启 .stm 檔。您的浏览器会显示此 .asp 文件，以及来自该已包含文件(included file)中的程序代码。
若要最佳化动态网络应用程序的性能，很重要的一项工作是让您的应用程序正式在站点上启用前，先测试它们。执行这项工作有个很好用的工具--Web Application Stress (WAS) 工具，您可以从 Microsoft Web Application Stress Tool 站点 下载它。在这个站点上还包括专为此工具提供的教学指南及知识库。WAS 也内含在 Windows 2000 Resource Kit 附随 CD 上。本 CD 上亦有。
测量网站服务器及应用程序所需工具的相关信息，请参阅本文中的〈用来监视及测试服务器性能的工具〉小节。如需网络应用程序性能及测试该性能所需工具的链接及参照清单，请参阅本文中的〈资源〉小节。
监视及测试服务器性能的工具
为了支持您的性能调整及测试需求，Microsoft 提供几个工具︰有些内含在 Windows 2000 及 IIS 5.0 中、有些位于 Windows 2000 Resource Kit CD中，剩下的内容则可从 Microsoft 网站下载。「系统监视器」(先前称为 PerfMon) 内建在 Windows 2000 中，它对于监视服务器的各种性能而言是必要的。「进程及线程状态」(pstat.exe) 会显示所有执行中的进程及线程的状态。「进程树状目录」(ptree.exe) 可让您查询进程的继承树状目录，及删除本机或远程计算机上的进程。这些工具都提供在 Windows 2000 Server Resource Kit 附随 CD 上。提供在 Windows 2000 Resouce Kit 附随 CD 上的「HTTP 监视工具」会监视服务器上的 HTTP 活动，而且会在活动容量发生改变时通知您。「网络监视器」是个您可以用来维持固定网络传输量的 Windows 2000 管理工具。它不包含在默认安装中，不过使用 [控制面板] 的 [添加/删除程序] 功能可以安装它。NetStat 是个指令行工具，会侦测关于服务器目前网络连接的信息。
这些工具的中心是内建在 IIS 5.0 及 Windows 2000 操作系统中的「性能计数器」。开发人员也可以在他们编写的 ISAPI DLLS 或 COM 组件中添加自定义的的「性能计数器」。这些计数器可以由以上提到的一些工具直接读取，包括「系统监视器」及「Web 应用程序压力工具」和 WCAT。其中有些计数器在本文前面已作过说明，但了解哪些会关系到您的监视及测试需求是很重要的。
「系统监视器」是一个在Web服务器上建立性能基准，并监视您对软硬件所作的任何改变，对性能将产生哪些影响的最重要工具。「系统监视器」提供一个用户接口，让您在监视或记录时能看见性能计数器的指数。它也能让您以图形方式记录计数器活动，并设置将出现在 [事件查看器] 中的警告。「系统监视器」提供系统中每一计数器的记录。
「Web 应用程序压力」工具是专门为了仿真多个浏览器同时向一个网站送出网页请求而设计的。您可以使用这个工具来收集关于 Web 应用程序性能及稳定性的信息，以及服务器执行状况的信息。这个工具可以仿真利用少数的客户端机器向 Web 服务器送出大量的请求时的状态。其目的是为了建立一个与生产环境尽可能相似的环境。如此才能让您在将 Web 服务器及应用程序部署到联机运行的服务器上之前，先找出并消除其中存在的问题。
以上任一工具的相关信息，请参阅内含在 Windows 2000 Resource Kit 中的联机IIS 5.0 文件。指向其它信息来源的链接则内含在本文的〈资源〉小节中。
windows 2000 及 IIS 5.0 中的功能及设置
如果您目前正在含 IIS 4.0 的 Windows NT Server 4.0 上执行一个经过适当调整的站点，则该站点在 Windows 2000 Server 及 IIS 5.0 上应可顺利地执行。相关信息请参阅 Windows 2000 Performance Test by ZD Labs。 当进行迁移时，您还是要监视你的服务器及站点。您将会注意到在 Windows 2000 及 IIS 5.0 中有些针对增强性能及简化管理而设计的新功能。此外，在 IIS 4.0 中的默认的设置值到了 IIS 5.0 之后已有所改变。本节将讨论这些功能及变化。
将 Windows 2000 设置为应用程序服务器
如果打算将服务器主要当作Web服务器使用，则将服务器计算机设为应用程序服务器是提高性能的最快方法。如此可让您利用较高的 SMP 缩放性、更高的网络性能，及更多 Web 应用程序物理内存的支持。对于执行 COM 的应用程序，则使用 Windows 2000 当作应用程序服务器也会对COM+ 有更多好处。此外，您可以将 COM+ 的交易处理功能当作一个交易监视器使用，以提高数据库应用程序的性能。Windows 2000 Server 会默认安装成文件服务器，因此您必须确定在安装过程中选择了应用程序服务器。不过，即使没有选取，在安装之后再将服务器设为应用程序服务器也很容易。若要选取︰
1. 按一下 [开始]，并指向 [设置] 后，再按 [网络和拨号连接]。
2. 选取 [区域连接]，并开启它的属性。
3. 选取 [File and Printer Sharing for Microsoft Networks]，并开启它的属性。
4. 在 [服务器最佳化] 选项卡上选取 [网络应用程序的数据传输量最大化]。
此设置将于重新启动服务器之后才生效。
IISReset 公用程序
IIS 5.0 提供一些新功能及默认设置，使得执行 IIS 5.0 的站点更加可靠且容易管理。其中第一个功能是新的 IISReset.exe，它是一个让您不必重新开机就能停止及重新启动 IIS 服务的公用程序。IISReset 在默认情况下会在它们失败时重新启动您的服务。您也可以使用 IISReset 从远程启动、停止或暂停您的服务，或视需要重新启动您的服务器计算机。您应该在没有办法时才重新启动。如果使用 IISReset 重新启动您的网络服务，用户会遭遇短暂暂停，此时他们只要按一下重新整理即可取得新网页。如果重新启动整台计算机，则无法使用的时间会更久。您也可以隔离您要停止的服务。例如，如果是在和Web服务器相同的计算机上执行 SMTP 服务器，则可选择只要停止并重新启动您的 Web 服务，而不是连SMTP 服务也跟着停止。
您必须知道如果经常重新开机及重新启始(按Reset键)会有损于性能资料的完整性。如果使用 IISReset 自动重新启动服务，就比较不会发生这个问题，因此您应该不断地监视 [事件记录文件]，以获取重新开机的情况。
IIS 设置
[AspProcessorThreadMax Metabase 的内容已改变。它原本在 IIS 4.0 中是称为 ProcessorThreadMax，而且是存在注册表(Registry)中，其默认值为 10。在 IIS 5.0 中的新默认值是 25 。这个设置是指每个处理器及每一进程︰在双 CPU 的系统上，每一进程中的工作线程数目可达 AspProcessorThreadMax 值的两倍之高，或高达 50 个工作自变量 (这是指在双 CPU 上的默认值的数目)。如果正在执行多个高度隔离的 ASP 应用程序，则每一个进程会有一组独立的工作线程。
附注︰ASP 会以 CPU 个数加上 7 的工作线程数目开始。当 ASP 请求队列的大小超过某个临界值时，它会建立更多线程。
AspThreadGateEnabled 内容已添加到 Metabase 中。它在默认值是关闭的。如果开启此内容，则 IIS 会执行线程传送，从而动态地控制当前线程的个数，以响应不同的负载状态。当 CPU 用量降到 50% 以下时，可能表示线程被阻断 (例如正在等待外部数据库传回查询的结果)，或纯粹表示负载量低， IIS 5.0 会增加使用中的线程数目，以便实时服务其它请求。当处理器用量超过 80% 时 (代表高负载量)，IIS 5.0 会撤消线程，以减少内容切换的数量。您可以设置上限及下限︰AspThreadGateLoadLow 默认是 50%；AspThreadGateLoadHigh 默认是 80 %。不管AspThreadGateEnabled 的值如何，ASP 进程的工作线程一定不会超过 CPU 个数乘以AspProcessorThreadMax。
对于需要处理大量 ASP 的站点，最好是通过开启及关闭线程传送来测试它的性能，看看会有什么效果。根据您的观察作最后决定。对于主要是由静态文件组成的站点，请开启设置并监视服务器性能，看看传输量及响应时间是否有改善。
IIS 5.0 也改变了 ASP Template Cache的默认行为。在 IIS 4.0 中，「ASP Template Cache」的限制默认为 -1。使用这个设置，缓存会增加到无限大。在含有大量 ASP 内容的网站上，「ASP Template Cache」常会用满服务器上所有的 RAM。相反地，IIS 5.0 默认限制是 250 个文件。因为每一个站点都有自己的需求，所以您应重设此限制，以符合您站点的特殊需要。或许要完成这项工作最简单的方式就是监视您在增减此值时，服务器的性能会有什么变化。因为在这个缓存中的一个项目可以指向「ASP Script Engine Cache」中一个或多个项目，只有在「ASP Script Engine Cache」中能找到 ASP 页中的脚本文件时才会达到最佳性能，所以绝对不要将「ASP Template Cache」的限制设为零。这样做可防止发生存取「ASP Script Engine Cache」的情况，因为要参照特定 .asp 文件的「ASP Script Engine Cache」项目只能通过此样本做到。因此，如果没有缓存任何模板，则「ASP Script Engine Cache」等于毫无作用。存取「ASP Script Engine Cache」的性能高于存取「ASP Template Cache」的性能，因此如果阻断了存取「ASP Script Engine Cahce」的机会，则除非您所有的网页都是静态网页，否则性能会严重受损。在从 IIS 4.0 迁移到 IIS 5.0，「ASP Script Engine Cache」的限制已从 30 个文件增加到125 个文件。若要判定是否需要改变缓存设置，应留意响应时间、队列中的 ASP 请求个数、内容切换的数目，以及 CPU 使用的容量.
本文为您说明在 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 请求。
调整 Web 应用程序
IIS 5.0 对于服务静态 HTML 网页及配上默认的设置值基本就已足够了。如果您的站点主要是静态内容，则许多性能问题可能会与硬件有关。IIS 5.0 为 Web 应用程序提供不错的性能，但若想获得最佳的性能，还需要一些额外的调整。当然，不管服务器软件如何增强，与 Web 应用程序设计及程序代码有关的最佳经验方法的问题依然会存在。虽然本文没有试图讨论调整 Web 应用程序的细节，但本节仍提供一些使它们执行更快的指导及建议。在规划及测试您的 Web 应用程序时，请先考虑下列事项，然后再到实际联机运行的服务器上执行它们。
第一，ISAPI 应用程序比 Active Server Pages (ASP) 应用程序执行得更快，虽然 ASP 的开发费用远比 ISAPI 低。这两种应用程序都比 CGI 应用程序执行得更快。
第二，因为静态文件不会有动态文件才有的处理负载，或引起磁盘活动，所以您应该尽可能使用它们。除了使用静态文件外，您的应用程序应尽可能将处理负载推到客户端，以避免网络等待时间。如此也能节省服务器端的资源，并让更新在很段时间内完成。有个常用的范例是加一个客户端的小程序代码，来检查电子邮件地址组成是否正确。
另一个技巧是确定在您的实际上线运行服务器上已关闭 ASP 的侦错功能。如果启用侦错，则必须将 AppAllowDebugging Metabase 属性设为 FALSE。相关信息，请参阅〈附录 1︰性能设置〉。
尽可能地为所有图像及 HTML 设置「过期」标题，让它们可以存放在客户端的缓存中。相关信息，请参阅本文中的〈调整及疑难排除的建议〉小节。
如果 Microsoft Visual Basic_ 对象是以 Apartment 线程处理的(非 Java 或大部分 C++ 对象)，请从「ASP 应用程序及有效期」状态中删除它们。
只有在必要时才使用 Secure Sockets Layer (SSL)。使用 HTTPS 通讯协议比使用标准 HTTP 贵很多。请确定传送中的信息 (可能是敏感资料如信用卡号) 的价值是否值得您付出增加的费用。安全性调整问题的相关信息，请参阅本文中的〈安全性〉小节。
进程隔离也会影响 Web 应用程序的性能。IIS 5.0 Web 应用程序默认是在进程外的缓冲池 (中度保护) 中执行。接受进程隔离对性能的影响总比冒着服务器停机或资料遗失的风险来的安全，例如因应用程序当机而破坏它与 IIS 5.0 共享的 Ientinfo 进程时就会导致这些风险。有关这个主题的深入讨论，请参阅本文中的〈进程隔离〉小节。
若要增进生产环境中的数据库驱动性能，请使用 Microsoft SQL Server。由于 IIS 及 SQL Server 在足够的内存下执行的情况最好，因此请尝试将资料库存放在不同于 Web 服务的服务器上。在这种情况下，经由网络跨计算机通讯通常比单一计算机上的通讯还快。当 SQL Server 及 IIS 存放在同一台服务器上时，就会经常因为内存不足或循环不够而导致性能降低。此外，请务必建立及维护适当的索引。如此才能最小化数据库查询的输入和输出。最后一点，请尽量多利用被存储的过程(stored procedured)。它们比设计来执行相同工作的 ASP 脚本文件所需的执行时间更少，而且更容易撰写。
一般来说，如果您有个超过 100 行 (使用 #include 指令来计算添加文件中的程序代码行数) 的 ASP 脚本文件，请考虑建立一个 COM+ 组件来提供相同的功能。如果能撰写得很有效率，并且经过正确地的测试，则 COM++ 组件可以为同一动态页提供 20 到 30 倍处理一个脚本文件的速度。使用 #includes 测量 ASP 脚本文件最简单的方式是将扩展名从 .asp 改为 .stm，并使用您的浏览器开启 .stm 檔。您的浏览器会显示此 .asp 文件，以及来自该已包含文件(included file)中的程序代码。
若要最佳化动态网络应用程序的性能，很重要的一项工作是让您的应用程序正式在站点上启用前，先测试它们。执行这项工作有个很好用的工具--Web Application Stress (WAS) 工具，您可以从 Microsoft Web Application Stress Tool 站点 下载它。在这个站点上还包括专为此工具提供的教学指南及知识库。WAS 也内含在 Windows 2000 Resource Kit 附随 CD 上。本 CD 上亦有。
测量网站服务器及应用程序所需工具的相关信息，请参阅本文中的〈用来监视及测试服务器性能的工具〉小节。如需网络应用程序性能及测试该性能所需工具的链接及参照清单，请参阅本文中的〈资源〉小节。
监视及测试服务器性能的工具
为了支持您的性能调整及测试需求，Microsoft 提供几个工具︰有些内含在 Windows 2000 及 IIS 5.0 中、有些位于 Windows 2000 Resource Kit CD中，剩下的内容则可从 Microsoft 网站下载。「系统监视器」(先前称为 PerfMon) 内建在 Windows 2000 中，它对于监视服务器的各种性能而言是必要的。「进程及线程状态」(pstat.exe) 会显示所有执行中的进程及线程的状态。「进程树状目录」(ptree.exe) 可让您查询进程的继承树状目录，及删除本机或远程计算机上的进程。这些工具都提供在 Windows 2000 Server Resource Kit 附随 CD 上。提供在 Windows 2000 Resouce Kit 附随 CD 上的「HTTP 监视工具」会监视服务器上的 HTTP 活动，而且会在活动容量发生改变时通知您。「网络监视器」是个您可以用来维持固定网络传输量的 Windows 2000 管理工具。它不包含在默认安装中，不过使用 [控制面板] 的 [添加/删除程序] 功能可以安装它。NetStat 是个指令行工具，会侦测关于服务器目前网络连接的信息。
这些工具的中心是内建在 IIS 5.0 及 Windows 2000 操作系统中的「性能计数器」。开发人员也可以在他们编写的 ISAPI DLLS 或 COM 组件中添加自定义的的「性能计数器」。这些计数器可以由以上提到的一些工具直接读取，包括「系统监视器」及「Web 应用程序压力工具」和 WCAT。其中有些计数器在本文前面已作过说明，但了解哪些会关系到您的监视及测试需求是很重要的。
「系统监视器」是一个在Web服务器上建立性能基准，并监视您对软硬件所作的任何改变，对性能将产生哪些影响的最重要工具。「系统监视器」提供一个用户接口，让您在监视或记录时能看见性能计数器的指数。它也能让您以图形方式记录计数器活动，并设置将出现在 [事件查看器] 中的警告。「系统监视器」提供系统中每一计数器的记录。
「Web 应用程序压力」工具是专门为了仿真多个浏览器同时向一个网站送出网页请求而设计的。您可以使用这个工具来收集关于 Web 应用程序性能及稳定性的信息，以及服务器执行状况的信息。这个工具可以仿真利用少数的客户端机器向 Web 服务器送出大量的请求时的状态。其目的是为了建立一个与生产环境尽可能相似的环境。如此才能让您在将 Web 服务器及应用程序部署到联机运行的服务器上之前，先找出并消除其中存在的问题。
以上任一工具的相关信息，请参阅内含在 Windows 2000 Resource Kit 中的联机IIS 5.0 文件。指向其它信息来源的链接则内含在本文的〈资源〉小节中。
windows 2000 及 IIS 5.0 中的功能及设置
如果您目前正在含 IIS 4.0 的 Windows NT Server 4.0 上执行一个经过适当调整的站点，则该站点在 Windows 2000 Server 及 IIS 5.0 上应可顺利地执行。相关信息请参阅 Windows 2000 Performance Test by ZD Labs。 当进行迁移时，您还是要监视你的服务器及站点。您将会注意到在 Windows 2000 及 IIS 5.0 中有些针对增强性能及简化管理而设计的新功能。此外，在 IIS 4.0 中的默认的设置值到了 IIS 5.0 之后已有所改变。本节将讨论这些功能及变化。
将 Windows 2000 设置为应用程序服务器
如果打算将服务器主要当作Web服务器使用，则将服务器计算机设为应用程序服务器是提高性能的最快方法。如此可让您利用较高的 SMP 缩放性、更高的网络性能，及更多 Web 应用程序物理内存的支持。对于执行 COM 的应用程序，则使用 Windows 2000 当作应用程序服务器也会对COM+ 有更多好处。此外，您可以将 COM+ 的交易处理功能当作一个交易监视器使用，以提高数据库应用程序的性能。Windows 2000 Server 会默认安装成文件服务器，因此您必须确定在安装过程中选择了应用程序服务器。不过，即使没有选取，在安装之后再将服务器设为应用程序服务器也很容易。若要选取︰
1. 按一下 [开始]，并指向 [设置] 后，再按 [网络和拨号连接]。
2. 选取 [区域连接]，并开启它的属性。
3. 选取 [File and Printer Sharing for Microsoft Networks]，并开启它的属性。
4. 在 [服务器最佳化] 选项卡上选取 [网络应用程序的数据传输量最大化]。
此设置将于重新启动服务器之后才生效。
IISReset 公用程序
IIS 5.0 提供一些新功能及默认设置，使得执行 IIS 5.0 的站点更加可靠且容易管理。其中第一个功能是新的 IISReset.exe，它是一个让您不必重新开机就能停止及重新启动 IIS 服务的公用程序。IISReset 在默认情况下会在它们失败时重新启动您的服务。您也可以使用 IISReset 从远程启动、停止或暂停您的服务，或视需要重新启动您的服务器计算机。您应该在没有办法时才重新启动。如果使用 IISReset 重新启动您的网络服务，用户会遭遇短暂暂停，此时他们只要按一下重新整理即可取得新网页。如果重新启动整台计算机，则无法使用的时间会更久。您也可以隔离您要停止的服务。例如，如果是在和Web服务器相同的计算机上执行 SMTP 服务器，则可选择只要停止并重新启动您的 Web 服务，而不是连SMTP 服务也跟着停止。
您必须知道如果经常重新开机及重新启始(按Reset键)会有损于性能资料的完整性。如果使用 IISReset 自动重新启动服务，就比较不会发生这个问题，因此您应该不断地监视 [事件记录文件]，以获取重新开机的情况。
IIS 设置
[AspProcessorThreadMax Metabase 的内容已改变。它原本在 IIS 4.0 中是称为 ProcessorThreadMax，而且是存在注册表(Registry)中，其默认值为 10。在 IIS 5.0 中的新默认值是 25 。这个设置是指每个处理器及每一进程︰在双 CPU 的系统上，每一进程中的工作线程数目可达 AspProcessorThreadMax 值的两倍之高，或高达 50 个工作自变量 (这是指在双 CPU 上的默认值的数目)。如果正在执行多个高度隔离的 ASP 应用程序，则每一个进程会有一组独立的工作线程。
附注︰ASP 会以 CPU 个数加上 7 的工作线程数目开始。当 ASP 请求队列的大小超过某个临界值时，它会建立更多线程。
AspThreadGateEnabled 内容已添加到 Metabase 中。它在默认值是关闭的。如果开启此内容，则 IIS 会执行线程传送，从而动态地控制当前线程的个数，以响应不同的负载状态。当 CPU 用量降到 50% 以下时，可能表示线程被阻断 (例如正在等待外部数据库传回查询的结果)，或纯粹表示负载量低， IIS 5.0 会增加使用中的线程数目，以便实时服务其它请求。当处理器用量超过 80% 时 (代表高负载量)，IIS 5.0 会撤消线程，以减少内容切换的数量。您可以设置上限及下限︰AspThreadGateLoadLow 默认是 50%；AspThreadGateLoadHigh 默认是 80 %。不管AspThreadGateEnabled 的值如何，ASP 进程的工作线程一定不会超过 CPU 个数乘以AspProcessorThreadMax。
对于需要处理大量 ASP 的站点，最好是通过开启及关闭线程传送来测试它的性能，看看会有什么效果。根据您的观察作最后决定。对于主要是由静态文件组成的站点，请开启设置并监视服务器性能，看看传输量及响应时间是否有改善。
IIS 5.0 也改变了 ASP Template Cache的默认行为。在 IIS 4.0 中，「ASP Template Cache」的限制默认为 -1。使用这个设置，缓存会增加到无限大。在含有大量 ASP 内容的网站上，「ASP Template Cache」常会用满服务器上所有的 RAM。相反地，IIS 5.0 默认限制是 250 个文件。因为每一个站点都有自己的需求，所以您应重设此限制，以符合您站点的特殊需要。或许要完成这项工作最简单的方式就是监视您在增减此值时，服务器的性能会有什么变化。因为在这个缓存中的一个项目可以指向「ASP Script Engine Cache」中一个或多个项目，只有在「ASP Script Engine Cache」中能找到 ASP 页中的脚本文件时才会达到最佳性能，所以绝对不要将「ASP Template Cache」的限制设为零。这样做可防止发生存取「ASP Script Engine Cache」的情况，因为要参照特定 .asp 文件的「ASP Script Engine Cache」项目只能通过此样本做到。因此，如果没有缓存任何模板，则「ASP Script Engine Cache」等于毫无作用。存取「ASP Script Engine Cache」的性能高于存取「ASP Template Cache」的性能，因此如果阻断了存取「ASP Script Engine Cahce」的机会，则除非您所有的网页都是静态网页，否则性能会严重受损。在从 IIS 4.0 迁移到 IIS 5.0，「ASP Script Engine Cache」的限制已从 30 个文件增加到125 个文件。若要判定是否需要改变缓存设置，应留意响应时间、队列中的 ASP 请求个数、内容切换的数目，以及 CPU 使用的容量.
