使用 IIS 5.0 调整 Web服务器的艺术与科学--2

为什么要调整 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 指令。

原文转自：http://www.ltesting.net