|
|
|
7i24.Com不停为您服务
MS的白皮书
摘要
本文为您说明在 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 使用的容量。
附注：「ASP Script Engine Cache」设置应至少等于服务器上 CPU 个数加上 1，再乘上 AspProcessorThreadMax 设置的值。
此外，您应考虑调整IIS File Cache的默认值。您可以将这些设置添加到注册表中，以修改 IIS 5.0 的默认行为。您应考虑增加的第一个设置是 MemCacheSize 对象；如果它不存在于注册表中，则默认行为允许缓存最大增至可用物理内存的一半。这样才能确保 IIS 可以与非专用Web服务器上的应用程序适当地交互。尝试增加此限制 (以 MB 为单位指定) 并监视性能来看看是否能获得好处。您应考虑增加的第二个注册表对象是 MaxCachedFileSize。这个 IIS 默认行为允许缓存中的最大文件大小为 256KB。如果您的网站中有数个经常存取的大型 .jpg 文件，则可以提高这个限制，以测试大于 256KB 的缓存文件能否在您的站点上运行。请注意，如果文件大小是大约 200 到 300KB，则当您存取它们时，所得的性能提升将逐渐变小。对于较小的文件，从磁盘读取的负担比从「IIS 文件缓存」读取的负担来得更大。对于较大文件来说，您不会获得太多性能上的提升；只会浪费内存。IIS 会定期从最近未被请求的缓存文件中清除 (默认是最近 30 秒内)。此临界点是由ObjectCacheTTL (TTL 代表存留时间) 注册表设置决定的；此对象默认不出现在注册表中。如果您有足够的内存，则将此 TTL 调高会很有效。
关于 IIS 及 ASP 如何使用缓存来处理连接请求的讨论，请参阅〈附录 3︰ASP 缓存〉。
进程隔离
IIS 4.0 介绍了在进程外执行 Web 应用程序的概念。这个功能为 Web 服务器建立了更高的稳定性，但也产生相当大的性能成本。在 IIS 5.0 中，进程外(out-of-process)应用程序的性能已获得改善，尤其是对 APS 更明显。不过，相较于 IIS 5.0 进程内(in-process)的应用程序，还是有些性能降级的现象。除了更高的性能外，在进程外(out-of-process)执行应用程序的概念也有所延伸。您现在可以在一个缓冲池的(pooled)进程外环境中执行 Web 应用程序。
在 Web 服务进程中执行的应用程序 (Inetinfo.exe) 能产生更高的性能，但是因不良应用程序而导致 Web 服务无法使用的风险也更高。建议的设置是让 Inetinfo.exe 在自己的进程中执行、让负担重要任务的应用程序在自己的进程中执行 (高度保护)，并让剩余的应用程序在一个共享的缓冲池进程 (中度保护) 中执行。若要获得最佳性能和可靠性，请以中度保护执行 ASP 应用程序，并将所有 COM+ 组件设置为链接库应用程序，而非服务器应用程序。
如果决定在单独的进程中执行您的应用程序，或在单一的进程中执行其它应用程序，则必须从 ][主目录] 或 [虚拟目录] 属性页上的 [应用程序保护]下拉列表中选取 [高 (隔离的)] 或 [中 (缓冲池的)]。您应先建立一个应用程序目录并将它指定为「主目录」或「虚拟目录」(如果尚未这样做的话)。所有新应用程序默认会以中度保护执行。
这些注册表设置及 Metabase 内容的相关信息，请参阅〈附录 1︰性能设置〉。本节中所提功能的相关信息，请参阅 IIS 5.0 及 Windows 2000 联机文档。
调整及疑难排除的建议
如果您判定需要处理特定硬件驱动的性能问题，请考虑使用下列建议。
· 升级到较大的「L2 缓存」。如果判定需要添加或升级处理器，请选择有大型 (L2) 缓存的处理器。例如 IIS 等服务器应用程序可以从大型处理器缓存中获益，因为它们的指示路径牵涉到许多不同的组件，而且它们必须存取大量资料。若想提升执行 IIS 5.0 的服务器的性能，建议您使用大量处理器缓存(如果是处理器外部的缓存，建议使用 2 MB 或以上，如果在 CPU 芯片上，则请使用可用的最大值)。
· 升级到更快的 CPU。网络应用程序特别能从更快的处理器获益。
· 设置「活动的连接超时时间」。若要尽可能地抵抗网络等待时间，请设置活动的连接超时时间。如果您执行的是高传输量的网站，这将是非常重要的。开启的连接会使性能降级。ConnectionTimeout Metabase 内容默认会设为 15 分钟。此内容的相关信息，请参阅〈附录 1︰性能设置〉。
· 使用「过期标题」。在所有静态及动态内容上设置「过期」标题，让这两种内容可以存放在客户端的缓存中。如此可加快响应时间、减少服务器上的负载及网络上的传输量。例如，您可以建立一个标题，指定如果用户已经造访过您的站点时，不要下载您公司的标帜 .jpg 檔。若要为静态内容设置「过期」标题，请使用 [HTTP 标题] 内容页。若要为动态内容设置「过期」标题，请使用 Response.AddHeader 方法。此方法的相关信息，请参阅 IIS 5.0 联机文档。
· 确定已启用「ASP Buffering」。「ASP 缓冲处理」默认会在全新安装 Windows 2000 之后启用。如果是从 Windows NT 4.0 及 IIS 4.0 升级，您可能需要手动启用它。「ASP 缓冲处理」可让所有来自应用程序的输出在通过网络传给客户端浏览器之前，先收集在缓冲区中。 如此可以降低网络传输量及响应时间。虽然缓冲处理可以降低响应时间，但可能会让用户察觉网页的速度变慢，因为除非网页已完成执行，否则用户看不见任何信息。审慎地使用 Response.Flush 可以改善交互的感觉。Response.Flush 方法的相关信息，请参阅 IIS 5.0 联机文档。相关信息，请参阅〈附录 1︰性能设置〉中的 AspBufferingOn Metabase 项目。
· 延长连接队列及使用 HTTP Keep-Alives。如果您判定您服务器的带宽不足以满足需要，并且正计划增加请求负载，则可以通过执行两个动作让网络带宽的使用更理想︰延长连接队列，及确定HTTP Keep-Alives 已启用。
每一个 IIS 5.0 服务都有一个连接队列，而且皆设为 15 个项目。如果这个数字在负载量下不符合您的需求，则通过将 ListenBackLog 参数添加到注册表中，并将此值设置为需要服务器维持的最大连接请求数目，即可增加它。相关信息，请参阅〈附录 1︰性能设置〉。
HTTP Keep-Alives 会保持客户端与服务器之间的连接，即使初始请求已完成也是如此。这个功能可以缩短等待时间、减少 CPU 负荷，及最佳化带宽。HTTP Keep-Alives 是默认启用的。如果它们已停用，但您又想启用它们，请在 [Internet 服务管理员] 中选取一个站点，开启该站点的 [属性] 页，并按一下 [性能] 选项卡后，再选取 [HTTP Keep-Alives] 复选框。
· 缩小文件大小。您可以通过缩小服务中的文件大小来增进Web服务器的性能。图像文件应以适当的压缩格式存放。尽可能限制图像及其它大型文件的数目。通过缩减 HTMP 及 ASP 程序代码也可以缩小文件大小。从 ASP 页中删除不必要的程序代码区块，并确定您的 HTML 文件编写得很有效率。
· 将记录文件存放在个别的磁盘上，并删除不需要的信息。如果您的服务器控制了多个站点，则每一个站点会建有个别的日志文件；这些日志文件在向磁盘写入时会在您的服务器上造成瓶颈。您应该将日志存放在不同于 Web 服务器的磁盘分区或磁盘上。另一个减少磁盘瓶颈的方法是避免记录不重要的信息。例如，您可以将所有图像文件放在一个虚拟目录 (例如 /images) 中，并停用该目录的日志。若要这样做，请开启该目录的内容页，清除 [日志查阅次数] 复选框，并按一下 [确定]。您也可以使用脚本文件或 ISAPI 过滤器来执行这项调整作业。如果您的站点是特别忙碌的大型站点，那么这项作业可以为您省下每天好几千兆的磁盘空间，以及大量的日志后处理时间。
· 使用 RAID 及等量分配。若要增加磁盘存取，请使用 RAID 及等量磁盘组。您也许要考虑使用一个有较大 RAM 缓存的磁盘驱动器控制器。如果您的站点倚赖频繁的数据库存取，则请将数据库移到另一台计算机上。
· 需要时才使用「CPU 限制」。IIS 5.0 介绍两种处理不良应用程序的新功能︰一个是进程记录，它会记录网站使用的 CPU 及其它资源；另一个是进程限制，它会限制网站可以使用的资源数量。
进程记录及进程限制适用于 CGI (Common Gateway Interface) 应用程序及在进程外(out-of-process)执行的应用程序。您无法为进程内(in-process)的应用程序或在新 IIS 5.0 进程外缓冲池 (中度保护) 中执行的应用程序启动记录。
若要启用进程记录
1. 在 [Internet 服务管理器] 中选取您要建立进程记录的网站。
2. 开启站点的属性页，并按一下 [主目录] 选项卡。
3. 在 [应用程序保护] 方块中选取 [高 (独立的)]。
4. 在站点的内容页上按一下 [Web站点] 选项卡，并确定选取 [启用记录]。
5. 在 [Web站点] 内容页上按一下 [属性] 按钮，并选取[扩充内容] 的 [处理帐户]。
前两个步骤会将网站设置为在进程外执行，后两个步骤会启动该站点的进程记录。
例如，如果您是 ISP，且您的某个用户站点正在使用的 CPU 时间超过它应有的部份，您就可以启动程序处理记录并延长记录，以记下「工作对象」计数器的数值。有了从进程记录收集到的信息之后，您就可以决定是否要在您的安装中升级服务器、调整这位特殊用户的费用，或限制该站点可以使用的资源数量。
在决定该用户的站点正在使用的资源数量之后，您可能想要限制这位用户只能使用您的可用资源中某个百分比的数量，这样可以释放资源供其它用户使用。若要限制站点的资源，请在进程外执行站点应用程序，然后按下列方式启用进程限制︰
1. 在站点的内容页上按一下 [性能] 选项卡。
2. 选取 [启用作业限制设置]。
3. 在 [最大 CPU 使用] 方块中，设置该站点专用的 CPU 资源的百分比。
4. 选取 [强行限制]。
当站点达到预先设置的限制时，它会采取已定义的动作，例如降低进程优先级、中止进程，或中止站点。请注意，如果位于一个受限制站点内的虚拟目录是设置为程序中或缓冲池型程序的应用程序，则该站点实际上可能会超过表面上的处理器使用限制。进程内及缓冲池型程序的应用程序不会受到处理器限制的影响，而且不会含在处理帐户记录的统计中。
· 下列技术可协助您判定是否需要使用处理器限制︰记录「Processor︰% Processor Time」、「Web Service: Maximum CGI Requests」及「Web Service: Total CGI Requests」计数器；启用处理帐户记录，让「工作对象」计数器包含在 IIS 记录中；以及检查 Dllhost 对象计数器以判定进程外(out-of-process) WAM 及 ISAPI 请求的数目。
您应注意作业限制有时会带来相反的结果。因为受限制的 Dllhost 进程是以较低的优先级执行，所以不会快速地响应来自Inetinfo 进程的请求。这会使得许多 I/O 线程受阻，于是降低了服务器的整体响应能力。如往常一样，只要做过任何一种改变之后，您都需要仔细地监视您的服务器在设置了启用作业限制之后，对性能带来哪些效果。
测试、试验及正式启用
在您利用 Windows 2000 的 IIS 5.0 当你的 Web 服务器之前，很重要的一点是必须先在一个尽可能仿真真实情况的环境中测试您提出的设计。如此不但能帮助您找出服务器及您打算在这些服务器上运用的 Web 应用程序可能存在的问题，也可保护您的线上服务器免受突发问题的干扰。最理想的状态是您可以在一个受控制的环境中进行测试 (例如实验室)，并将不相关的流量隔离在服务器外。将测试服务器集中在测试您的硬件的设置状态及 Web 应用程序能承受多大的压力。
在您从 IIS 4.0 成功升级到 IIS 5.0 的过程中，测试扮演了极重要的角色。在您的测试环境中，可以发现到可能会在您的真实站点上造成严重状况的各类问题。其中包括将会影响 Web 服务器性能的问题。您也许会发现必须添加更多 RAM，或您打算在升级 IIS 5.0 时一起运用的 ASP 应用程序有太多问题，无法在网络上执行。如果能在测试阶段尽可能地解决这些问题，则顺利升级的几率就越大。
建议您采用的做法是有计划地从 IIS 4.0 升级到 IIS 5.0。这牵涉到了在 IIS 4.0 建立一套测试，执行这些测试，然后再将性能调整到最佳状态，并且在 IIS 5.0 上执行相同的测试。这样做不但能让您找出任何与性能相关的问题，也可以让您估计可以从升级获得的性能增益。您可以使用例如「系统监视器」及「Web 应用程序压力」等工具在测试期间分别监视性能和产生测试实例。
一旦测试完成，建议您设置一个 IIS 5.0 系统。这表示在一个比实验室更接近真实状态的环境中，让可以协助您测试服务器及应用程序压力的用户先试用您的服务器。使用公司内部网络是试验一个新部署的理想环境。在试验期间，您是在一个受控制的真实环境中测试您的设计，在此环境中的用户会使用新功能来执行他们的正常业务。请记住在整个试验期间继续监视服务器的性能。设计测试及试验部署的详细资料，请参阅 Windows 2000 Deployment Planning Guide。
虽然测试及试验都是绝佳的作法，但是它们都无法完全复制您的 Web服务器将面临的使用类型及负载。总之，测试及试验是在一个受控制的环境中发生，其中网络等待时间是最短的，而且早已知道生产中的请求种类及数量。当您的服务器及应用程序正式启用时，您会将它们暴露于整个 Internet 及它的用户面前。
在将 IIS 5.0 部署到生产计算机之后，继续监视您的服务器是很重要的。如同本文先前所说的，这样才能让您建立用来判定性能高低与否的基准性能记录。每当您在生产服务器上进行更新后，不要忘记将新的数字拿来与基准数字作比较，这样才可以了解您的改变对于性能产生哪些影响。最好是能够一次做一个改变；否则会无法辨识出哪个改变产生哪种影响。如果一次作了多个改变，则很难判定出每一个改变的效果。如果性能没有如您预计的提升效果，请继续分析资料并按指示作调整。监视应定期进行，但调整性能设置值会随着时间增长逐渐变得不需要。
(附录1)
附录 1：性能设置
您可以调整 IIS Metabase 内容及注册表设置来调整 Web 服务器的性能。如果打算改变注册表，则除非没有其它方法可用，否则请勿使用注册表编辑器。注册表编辑器会忽略系统管理工具提供的标准安全设置。这些安全设置可防止您输入冲突的设置值，或可能降低性能或损害系统的设置值。直接编辑注册表会导致严重且难以预计的后果，会导致系统无法启动，而必须重新安装 Windows 2000。使用 adsutil 公用程序 (可在 Inetpub\AdminScripts 目录中找到) 来改变 IIS 也会发生同样的状况。若要设置或定制 Windows 2000 及 IIS 5.0，请尽量使用 [控制面板] 或 Microsoft Management Console (MMC)。
Metabase 设置
这份清单包括用来调整 Web 服务器最重要的 Metabse 设置。使用 ADSI 接口可以获取及改变它们。这些设置大多会在重新启动 Web 服务之后才生效。相关信息，请参阅说明 IISReset 公用程序的小节。
AppAllowDebugging-这个属性会指定服务器上是否启用了 ASP 侦错。如果启用，则IIS 应用程序线程将序列化，这表示每个应用程序一次只能执行一条线程。这会对 Web 服务器的性能产生不利的影响。您可以在所有生产服务器上将这个属性设为 FALSE (默认)。
AspAllowSessionState-默认值是 TRUE。将它调整为 FALSE 可产生更高的性能。一旦改变后，开发人员必须明确地在需要使用「有效期」对象的页面上置换这个设置。若要改变单一页面上的默认设置，开发人员可以使用页面顶端的<% @EnableSessionState=False %>。若要改变这个选项，请务必通知开发人员。
AspBufferingOn-默认值是 TRUE。这个属性的默认行为是允许所有来自应用程序的输出在缓冲区被转存到客户端浏览器之前，先收集在缓冲区中。如果这个属性被设置为 FALSE，则来自 ASP 脚本文件的输出会在客户端使用浏览器时，写入该客户端浏览器。您必须确定这个属性在所有生产环境 Web 服务器上都设置为 TRUE。详细信息，请参阅本文中的〈调整及疑难排除的建议〉小节。
AspThreadGateEnabled (默认值是 FALSE) 及 AspProcessorThreadMax (默认值是 25)- 当您将 AspThreadGateEnabled 设为 TRUE 时，便会启用线程传送，而且 IIS 5.0 会动态地改变工作线程的数目，以响应改变的工作量。IIS 允许每一个 ASP 进程拥有的最大工作线程数目是 AspProcessorThreadMax乘以您服务器上的 CPU 数目。请调低此值，并监视性能。如果性能降低，请调回 AspProcessorThreadMax 值。相关信息，请参阅本文中的〈线程传送〉小节。
AspRequestQueueMax-在 IIS 5.0 中，队列中的默认请求限制已增加到 3,000个。这个设置的作用会根据应用程序的行为而定。如果请求的执行时间很短，而且在队列中的时间将很短，则增加此限制是合理的作法。
AspQueueConnectionTestTime-这是 IIS 5.0 的新设置，对于 Web 应用程序的性能帮助很大。在 IIS 4.0 中，一个请求是当它从队列中删除时无条件地开始执行。在 IIS 5.0 中，如果有个请求在队列中存留的时间超过队列连接测试时间，则服务器在开始执行之前，会先检查该客户端是否仍在连接中。这个功能可以处理不耐久候的用户在同一页上多次尝试而用满请求队列的问题。默认值是 3 秒。根据您的服务器正在执行的 Web 服务器类型，决定是否改变这个值。执行时间很长的 ASP 页也会使用 Response.IsClientConnected 方法来检查客户端是否仍在等待页面的剩余部份。执行时间很长的页面应谨慎地使用 Response.Flush，以确定用户能知道该页仍在执行中，而且正在执行生产性的工作。「响应」对象方法的相关信息，请参阅 IIS 5.0 联机文档。
AspSessionMax 及 AspSessionTimeout-其默认行为是将单一有效期的长度限制为 20 分钟，而不限制并行有效期的数目。在利用有效期的应用程序上缩小「有效期等候超时」以减少服务器所需的负担时要特别小心，但是如果并行有效期增加到难以处理的比例，就会产生增加「有效期最大值」的需要。
AspScriptEngineCacheMax-在内存中缓存的脚本文件引擎之最大数目的新默认值是 125。这不包含目前执行的脚本文件引擎。请根据应用程序中的内容类型调整此值。如果有几千个不同的页面，则增加缓存大小可能会有些效果，因为最常请求的网页可以随时供人存取。存取脚本文件引擎可以免去将模板重新编译为字节程序代码。
在设置这个 Metabase 属性之前，您应了解 ASP 使用「ASP Script Engine Cache」及「ASP Template Cache」的方法。进一步讨论，请参阅〈附录 3：ASP 缓存〉。
AspScriptFileCacheSize-这个属性会指定要存放在「ASP Template Cache」中预先编译的脚本文件个数。如果是 0，则不会有任何脚本文件可缓存。若是 -1，则所有请求的脚本文件都会被缓存。默认值是 250 个。如果您有许多不同的 ASP 页，请增加此值。请勿将此属性的值设为 0。这会关闭所有 ASP 缓存，并严重地损害服务器的性能。
AspTrackThreadingModel-这个 Metabase 属性会指定 IIS 是否将检查您的应用程序瞬间产生之任一组件的线程处理模式。如果让这个 Metabase 属性保持它的默认值 (FALSE)，则可避免由于追踪 ASP 的线程处理模式所造成的负担，而您可以在您的 ASP 应用程序中看见性能的提升。不过，如果这个属性是设为 FALSE，则您打算设置「应用程序」范围而建立的任何组件，必须聚集为不用线程处理的 Marsaller。如果没有聚集 Marshaller，则当您尝试瞬间产生该组件时，ASP 就会产生错误。此外，如果这个属性是 FALSE，则缺少 OnStartPage 或 OnEndPage 方法且瞬间在您 ASP 应用程序中产生的所有对象，会在该释放的时间前释放。这应该可以提高应用程序的可扩展性。这个属性在 IIS 4.0 中的默认值是 TRUE。相关信息，请参阅 IIS 5.0 联机文档。
CacheISAPI-这个属性显示 ISAPI 扩展 在使用之后是否会缓存在内存中。如果这个属性的值是 TRUE，则 .dll 文件会留在缓存中，直到服务器停止为止。如果此值为 FALSE，则一旦不再使用该 .dll 文件，便会从内存中卸载它。是否会缓存 ISAPI 扩展，是依据将它们加载内存供使用时其属性值而定。因此，如果这个属性在扩展已经被加载且缓存之后才改变，则此改变对该扩展不会有影响。
将这个属性设为 FALSE 会对侦错有帮助，但请确定这个属性在所有生产 Web 服务器上都设为 TRUE。为每一个请求重新加载 ISAPI extension .dll 文件，不但相当昂贵而且会降低性能。
ConnectionTimeout-这个属性会指定服务器在中断一条非使用中的连接之前，将等待的秒数。默认值是 900 (15 分钟)。因为开启的连接会降低性能，所以请考虑降低此值，并监视您的服务器在改变之后会有什么效果。
MaxEndpointConnections-这个属性会指定「听取」通讯端的最大数目，该通讯端会聚集在网络端点上。例如，如果将此值设为 15，则单一连接点可以建立最多 15 条连接，即使连接到此连接点的域超过一个。这个属性值的下限及 ServerListenBackLog 属性的值，决定了在您的服务器上聚合的通讯端数目。请将它设成高数字，并监视性能。默认值是 100 个。
ServerListenBackLog-这个属性会指定可以由队列处理的额外通讯端数目。这个属性值的下限及 MaxEndpointConnections 属性值，决定了在您的服务器上聚合的通讯端数目。请将它设成高数字，并监视性能。默认值是根据AcceptEx 操作系统参数及指定在 ServerSize Metabase 内容中的服务器大小而定。如果将 ServerSize 设为 1，则这个属性的默认值是 40。如果将 ServerSize 设为 2，则这个属性的默认值是 100。这个属性的有效值范围是 5 到 1000。
ServerSize-这个属性会从每天处理的客户端请求数目观点来指定服务器的规模。值 0 表示一个预计每日接收少于 10,000 个请求的小型网站；值 1 表示每日处理10,000 到 100,000 个请求的中型网站；值 2 则指定一天处理超过 100,000 个请求的大型站点。由于默认值为 1，所以若想最大化您的服务器可以处理的请求数目，请将这个属性设为 2。您可以使用 UI 来调整此设置。请开启您站点的内容表，并选取 [性能] 选项卡后，将 [性能调整] 滑动杆调整为[100,000 以上]。
注册表设置
本节列出当您在调整Web服务器时，应该特别注意的注册表设置。其中包括设置的注册表路径 (存放在同一位置上)，以及设置的名称、范围、默认值及每一个设置的作用说明。您必须在您的服务器上重新启动网络服务，才能使新的 Inetinfo 设置生效。相关信息，请参阅本文中的〈IISReset 公用程序〉小节。
Registry Path:
HKEY_LOCAL_MACHINE\SYSTEM
\CurrentControlSet
\Services
\Inetinfo
\Parameters
DisableMemoryCache REG_DWORD
范围： 0, 1默认：0
请确定此参数在所有生产服务器上全都设为 0。如果将此参数设为 1，则会停用缓存。虽然在侦错时停用缓存是很有用的，但却会严重损害生产服务器的性能。这个参数无法通过 IIS 管理单元设置。
ListenBackLog REG_DWORD
范围： 1 到 300默认：15
这个参数会指定在一个队列中，等待服务器处理的最大使用中连接数目。增强的 IIS 功能通常会免去使用或修改这个项目的需要，但是如果遇到超大量的使用率，则你可以将此值调整到 300。
MaxPoolThreads REG_DWORD
范围： 0 - 无限制默认：4
这个参数会指定每一个处理器要建立的缓冲池线程数目。一条缓冲池线程会看守一个网络请求并处理它。MaxPoolThreads 计数不包括 ISAPI 应用程序使用的线程。在默认情况下，只有 4 个 CGI 应用程序可以同时执行。如果执行很多个 CGI 应用程序，则必须增加此值才能提高生产力。您可以将 UsePoolThreadForCGI 值 (在 ..\Services\W3SVC\Parameters 下)设为 FALSE (0)；但是因为它在 CGI 应用程序高用量期间会明显地降低性能，所以有点危险。一般来说，最好不要为每一个处理器设置超过 20 条线程。
MaxCachedFileSize REG_DWORD
范围： 0 - 无限制 (以字节测量)默认：262,144 字节 (256KB)，如果注册表中没有值的话。
这个参数会决定能放在缓存中的最大文件大小。IIS 不会缓存大于 MaxCachedFileSize 字节的文件。如果您正在执行大型的专用 Web 服务器，则可以将此值添加到注册表，以增加缓存可以保留的文件大小。
MemCacheSize REG_DWORD
范围： 0 MB - 总计 MB 的可用 RAM默认：50% 的可用内存，如果注册表中没有值的话
这个参数会指定 IIS 将用于其本身文件缓存的最大内存容量。如果 IIS 不需要这么多内存，则剩余的内存可供其它应用程序使用。如果注册表中没有此值，则 IIS 最多只会使用到 Web 服务器上可用内存的一半(此容量是每 60 秒动态计算一次)。如果您正在执行大型的专用 Web 服务器，则可以将此值添加到注册表，并增加 IIS可以使用的内存容量。将此对象添加到注册表时，必须以 MB 为单位指定大小。
ObjectCacheTTL REG_DWORD
范围： 0 - 无限制默认： 30 秒
这个参数会控制「存留时间」(TTL) 设置，其定义了对象 (包括文件) 保留在高速缓存中的时间长度。如果内存缓存中有个对象经过一段定义的时间之后，都没有被引用，则该对象会从缓存中被清出。这个值默认并不包括在注册表中。如果想要改变它，则必须手动添加。如果系统内存有限，或服务器的内容是动态的，则可使用较低的 TTL 来防止系统内存被用于缓存大量的短暂对象。将此值设为 0xFFFFFFFF 会停用对象缓存回收程序，并让缓存的对象保留在缓存中，直到被覆盖为止。如果您的服务器有充足的系统内存，而且您的资料大多是静态的，则停用缓存回收程序会很有用。
PoolThreadLimit REG_DWORD
范围： 0 - 无限制默认： 2 * # MB
这个参数指定可以在系统中建立的最大缓冲池线程数目。一条缓冲池线程会看守一个网络请求并处理它。PoolThreadLimit 是包括所有 IIS 线程的硬件限制。PoolThreadLimit 恒大于或等于 MaxPoolThreads。
Registry Path:
HKEY_LOCAL_MACHINE\SYSTEM
\CurrentControlSet
\Control
\SecurityProviders
\SCHANNEL
ServerCacheTime REG_DWORD
范围： 0 - 无限制 (以毫秒测量)默认： 300,000 毫秒 (5 分钟)
这个参数会决定一个 SSL 有效期持续的时间量。一旦建立一个 SSL 有效期，客户端要重新连接到此有效期只需花费初始连接来源成本的一小部份。如果 SSL 有效期到期，则必须完整建立一个新的 SSL 有效期。这个参数默认不存在。若要改变它的行为，必须将它添加到注册表。您必须评估您预计 SSL 有效期持续的时间，然后将此参数设为较长一些。不要将超时时间设置得远大于预计时间，否则这个缓存会开始储存旧资料。如需进一步讨论，请参阅本文中的〈安全性〉小节。
(附录2)
附录 2：Windows 2000 Web Server 性能最佳化的技巧
· 升级 Windows 2000 之前，您必须先卸除 Inoculan、PCAnywhere 及 Veritas 的安装。您可以在安装 Windows 2000 之后再次安装它们。
· 请以新的默认中度保护模式 (缓冲池的 out-of-process) 执行您大部分的应用程序。当应用程序在缓冲池时，它们会共享相同的程序，因此降低了内存的负担。而且在中度保护下执行比在低保护 (in-process) 下执行应用程序会有更大的可靠性。
· 检查「事件记录文件」，以寻找在本机及远程服务器上是否有大量的服务重新启动情形。如果应用程序经常失败，性能将非常差，但因为 IISReset 公用程序会自动地执行可靠的重新启动，所以您可能不会察觉失败。
· 按时在您的服务器上执行磁盘整理。经过一段时间后，在服务器上的文件及目录会变得破碎。当这种情况发生时，因为需要许多额外的磁盘读取来搜集各个片段，所以 Windows 需要花较长的时间来存取文件及目录。关于「Windows 2000 磁盘整理工具」的信息，请参阅 Windows 2000 联机文档。
· 如果您使用 SSL，请确定已启用 License Logging Service，即使匿名用户正在存取您的 Web 服务器也一样。
· 不要例行或定期地重新启动 IIS 服务器，而应使用 IISReset.exe 公用程序。服务器重新开机应该是不得已而为之的手段。而且一旦发现任何蓝屏错误都应该向 PSS 报告并解决，不要忽略不管。
· 使用下列方法之一将 IIS 4.0 升级到 IIS 5.0︰
轮流升级︰在将整群服务器升级之前先测试升级一台服务器，然后再升级其它计算机。
系统化的升级︰先建立一组 IIS 4.0 测试，然后在升级到 IIS 5.0 之前先在您的计算机上执行测试。升级到 IIS 5.0 之后再执行一次测试，并测量旧系统与新系统间的性能差异。
· 可能的话，使用自动安装脚本文件来简化升级。
· 如果您使用 Visual Basic 对象，您在 Apartment 线程处理的应用程序或使用通用领域的同步呼叫上，将看不见性能提升。
· 在 Windows 2000 及 IIS 5.0 中使用 Index Server 3.0 必须对注册表作部份改变。相关信息，请参阅 Windows 2000 联机文档。
· 如果您在 Windows NT 4.0 上使用磁盘映像，请确定执行下列事项︰
在升级前先备份，在升级到 Windows 2000 时保持 Windows NT 4.0 的镜像原封不动。如此可以让您保有以前的磁盘映像。
确定您的磁盘驱动器是动态的。Windows 2000 需要这样做。在将磁盘驱动器转换成动态之前，磁盘末端必须有大约 1MB 的可用空间。因为磁盘整理时可能会需要它。相关信息，请参阅 Knowledge Base 文件。Q197738 Not Enough Space Available to Upgrade to a Dynamic Disk。
为了建立新镜像，在升级到 Windows 2000 之前请先重新规划分割区的大小。
请参阅这些额外的 Knowledge Base 文章︰Q175761 Dynamic vs. Basic Storage in Windows 2000 及Q231376 Legacy FT Sets Regenerate During a Windows 2000 Upgrade。
· 阅读本文中〈资源〉小段中所列的文件。
(附录3)
使用 IIS 5.0 调整 Web服务器的艺术与科学(附录3)
「ASP Template Cache」储存模板︰纯文字格式的预先编译 ASP 页 (已经演算 #includes等等)。它的大小是由在 Metabase 中的 AspScriptFileCacheSize 设置所控制，默认值为 250。「ASP Script Engine Cache」会保留已经被编译成字节程序代码的 ASP 模板。它的大小是由在 Metabase 中的 AspScriptEngineCacheMax 设置所控制，默认值为 125。两者间的关系是︰ASP 页会在模板缓存处理中被缓存一次，但如果它在许多线程上同时被执行，它可以在 Script 引擎缓存处理中出现多次。一个拥有许多内存及经常接到存取次数的个别 ASP 页的站点可能需要增加 AspScriptFileCacheSize (使用「系统监视程序」监视 ASP 计数器来诊断)。增加 AspScriptEngineCacheMax 的需求则小得多；主要原因是默认值对于有 8 个或以上处理器的机器而言不适用。AspScriptEngineCacheMax 的 Metabase 值应等于或大于 CPU 的数量再加上 1，再乘上 AspProcessorThreadMax。AspProcessorThreadMax 默认值为 25。
每个主控 ASP 的处理会拥有其本身的「ASP 模板」及「Script 引擎缓存处理」。因为 ASP 应用程序在缓冲池的 Dllhost 处理中会以中度隔离方式执行，所以默认只有一个进程。
当 ASP 接收到页请求时，它会先检查「ASP 模板缓存处理」。如果有该页缓存的例项时，请求会被转发到「Script 引擎缓存处理」。如果请求的页不在「模板缓存处理」中，则它会被编译成模板，并转发到「ASP Script 引擎缓存处理」。如果页例项在「Script 引擎缓存」中缓存，并准备执行，则该引擎会执行。如果没有，但有一个已经在执行中的页例项，则 ASP 会复制该执行中引擎并执行该复制。如此可以节省重新将模板分析为字节程序代码的成本。如果没有与页面相关的 Script 引擎，ASP 会从「ASP 模板缓存处理」使用预先编译的模板、建立新 Script 引擎，并使它将模板编译成字节程序代码后执行。当页面结束执行时，Script 引擎会被放在可用清单的最前面。如果可用清单增加到大于 AspScriptEngineCacheMax，则最久未被使用的 Script 会被删除。在 Script 引擎缓存处理中的一次存取，表示 ASP 可以避免重新将模板编译成字节程序代码。
关于在本讨论中所提的 Metabase 设置的相关信息，请参阅<附录 2︰性能设置>。
使用 IIS 5.0 调整 Web服务器的艺术与科学(附录4)
一般信息
· Killelea, Patrick。Web 性能调整。Cambridge, Massachusetts: O'Reilly & Associates, 1998。内容也可以在下列网站获得 http://www.patrick.net。
· Microsoft Corporation (编辑器)。Microsoft Windows 2000 Server Resource Kit、Microsoft Internet Information Services 5.0 资源指引 。Redmond, Washington: Microsoft Press, 2000.. 特别是参阅〈Capacity Planning〉及〈Monitoring and Tuning Your
Server〉两节。
· 使用 Microsoft Windows DNA 平台配置网站的蓝图，网址是http://msdn.microsoft.com/msdn-online/start/features/dnablueprint.asp 。
· Microsoft Site Server 3.0 容量及性能资源清单在下列网址可找到 http://www.microsoft.com/siteserver/ssrk/rk_list_all_capperf.htm。
· Internet 交易的容量模式 ，位于http://www.microsoft.com/siteserver/ssrk/docs/rk_TCA.doc。
· IIS 的 Microsoft TechNet 站点位于http://www.microsoft.com/technet/iis/default.asp。
硬件调整
· 测量网站的硬件性能，Kathy Ferguson 所著，位于http://www.microsoft.com/technet/iis/meashd.htm。
· 计数器快速指引，由 Kathy Ferguson 所著，位于http://www.microsoft.com/technet/iis/qguide.asp。
工具
· Web 应用程序重点工具及其使用说明，可到http://webtool.rte.microsoft.com/default.htm 取得。
· 大部分在文件中讨论的工具可以在 Windows 2000 Resource Kit CD 上获得，或已内建到操作系统中。关于后者的信息，请参阅 Windows 2000 联机文档。
Windows 2000 及 IIS 性能及调整
· 如何使用 Internet Information Server 5.0 及 Windows 2000 来设置可靠的 Web 服务器，位于http://www.microsoft.com/SERVAD/events/fall/tnq20005/html/default.htm。
· 监视及最佳化 Internet Information Server，位于http://www.microsoft.com/technet/iis/c06.asp。
· 调整 Internet Information Server 性能，作者：Mike Moore ，位于http://www.microsoft.com/isn/whitepapers/tuningiis.asp。
· Windows 2000 性能及基准 (在报告及白皮书标题下，位于http://www.microsoft.com/windows2000/guide/platform/performance/default.asp。
· 性能推进器︰调整后的 Windows 2000 IIS"磐石"，Frank J. Ohlhorst 及 John Yacono 合著， 位于http://www.crn.com/supersite/reviews/reviews.asp?RSID=CRN&ArticleID=12731。
· 浏览 Web 服务器性能最佳化设置的途径，Todd C. Wanke 所著，位于http://www.microsoft.com/backstage/whitepaper.htm。
· IIS 4.0 调整参数以达成高容量站点，Michael Stephenson 所著，位于http://msdn.microsoft.com/workshop/server/feature/tune.asp。
测试及调整 Web 应用程序
· 提升性能与样式的 15 个 ASP 技巧，位于http://msdn.microsoft.com/workshop/server/asp/asptips.asp。
· Homer、 Alex 及其它。Professional Active Server Pages 3.0. London: Wrox Press, 1999. 特别是使 ASP 性能最佳化的章节。
· 严重的性能及缩放性杀手，George Reilly 所著，位于http://msdn.microsoft.com/workshop/server/iis/tencom.asp。
· ASP 的最佳作法，George Reilly 所著，位于http://support.microsoft.com/support/activeserver/AspBestPractices.ppt。
· 最佳化您的 Active Server Pages 性能，Nancy Winnick Cluts 所著，位于http://msdn.microsoft.com/workshop/server/asp/maxperf.asp。
· 已取得任何缓存了吗？ Nancy Winnick Cluts 所著，位于http://msdn.microsoft.com/workshop/server/feature/cache.asp。
· 提升 ASP 应用程序性能的技巧，Srinivasa Sivakumar 所著，位于http://www.15seconds.com/issue/000106.htm。
· 测量您的 ASP Script 的执行时间，Mike Shaffer 所著，位于http://www.4guysfromrolla.com/webtech/122799-1.shtml。
· 测试您的 Web 应用程序的性能，Matt Odhner 所著，位于http://www.microsoft.com/technet/iis/wastip.asp。
· 增进 MDAC 应用程序的性能，Suresh Kannan 所著，位于http://www.microsoft.com/data/impperf.htm。
安全性议题
· Microsoft Internet Information Server 4.0 安全性检查清单，位于http://www.microsoft.com/security/default.asp。
· 网络攻击的安全性考虑，位于http://www.microsoft.com/technet/security/dosrv.asp。
|
|
|
