IIS 7.0 中的 10 大性能改进

　　IIS 7.0 中的 10 大性能改进

　　当我与计划采用 IIS 7.0 的公司会面交谈时，每次都要提到的一个问题就是迁移到 IIS 7.0 是否会改善服务器或应用程序的性能。答案

　　通常是肯定的，但如果在将应用程序刚刚迁移到 IIS 7.0 时并没有看到任何性能改善，也请不要感到惊讶。

　　要 理解这一点，您需要了解最新版本自身的一些特点。IIS 6.0 是工程版本，旨在实现以下三个目标：更强的安全性、更高的可靠性以及改进的性能。相比之下，IIS 7.0 是一个平台版本。它的目的是将其前身所拥有的高质量基本 Web 服务器核心转换成支持重要最新部署和管理方案的模块化和可扩展平台。

　　体 系结构的许多变更和新增功能实际上可能会对 Web 服务器的性能产生负面影响 —例如，假定有一个关键变更，它将经过严格优化的 Web 服务器代码路径拆分成了多个独立模块，这会导致这些模块将不再受到 Web 服务器的特殊对待。但是 IIS 7.0 则不然，它不但保留了其前身的出色性能，在某些领域甚至有所突破，这一切都应归因于 IIS 团队在性能方面所做的大量卓有成效的工作。根据我在 Web 服务器核心和集成管道方面的工作经验，我可以负责任地说，要实现这一目标需要大量的独创性设计，还需要在实现产品时付出艰辛的劳动。

　　尽管如此，与之前的其他 IIS 版本相比，IIS 7.0 还是极有可能会提供显著的性能改进并减少服务器场的性能相关成本。

　　您大可不必只为了解这些优点而迁移到 IIS 7.0，您可以通过某些环境进行了解。例如，Microsoft.com 的 CPU 效率出现了 10% 的改进（可在 Microsoft.com 团队博客上找到完整的分析，网址为 go.microsoft.com /fwlink/?LinkId=122497）。您可能还会发现在某些特定领域也有显著的改进，例如安全套接字层 (SSL) 和 Windows 身份验证（现在二者均在内核中执行），此外在多核和多处理器计算机中它也可以提供更出色的垂直可伸缩性。

　　但 是，真正的 IIS 7.0 动力并不是来自于对现有功能的增量性能改进。相反，应该说这些改进源自于您会主动使用的新增功能。这些功能通常来源于平台的灵活性和可扩展特性以及一些新的性能特性。在本文中，我将向您展示通过迁移到 IIS 7.0 可以实现的 10 个最重要的性能改进。

　　进一步瘦化 Web 服务器

　　部 署瘦 IIS 7.0 服务器的能力借用的是服务器的模块化体系结构。实际上，所有 Web 服务器功能都是以模块化组件的形式实现的，可以单独进行添加或删除。这样一来，您可以将那些对于应用程序的操作而言并非必需的所有服务器功能删除，这可以带来一些明显的益处，包括极大地减少受攻击的机会、减少操作内存占用量以及改善性能。

　　完 整的 IIS 7.0 Web 服务器功能集由 44 个模块组成，包括为集成管道提供服务的本机 IIS 模块和 ASP.NET 模块。这些模块可以提供多种服务，如身份验证（Windows 身份验证和摘要身份验证模块）、应用程序框架支持（FastCGI 模块）、应用程序服务（会话状态模块）、安全性（请求过滤模块）和性能（输出缓存模块）。对于仅提供静态内容的最小 Web 服务器，它只需要 2 个模块就可以正常运行！

　　对于那些不必要的模块，其开销可能会相当显著 —例如请求记录和失败请求跟踪模块。将此类模块从不需要它们的环境中移除可得到更高的总吞吐量和更快的响应，因为这可以减少服务器工作负载收到第一个字节的时间 (TTFB) 和收到最后一个字节的时间 (TTLB) 度量。

　　图 1显示了在使用完整功能集时、使用工作负载的默认功能集时以及使用工作负载必需的最小功能集时，针对 HTML 文件（静态工作负载）和 hello world ASP.NET 页面（ASP.NET 工作负载）进行简单吞吐量测试所得到的结果。尽管大部分不必要的功能在“完整”配置中已被禁用，但在“最小”配置中完全移除它们仍可使静态工作负载和 ASP.NET 工作负载的吞吐量都得到大幅提升。

　　图 1 在具有 100 个并发客户端的三种不同配置情况下，静态工作负载和 ASP.NET 工作负载的吞吐率（单击图像可查看大图）

　　此外，您可能还会发现在内存占用量方面的改进和更高的站点密度，尤其是在共享托管环境或使用大量工作进程的情况下。这通常是由于向每个进程加载的 DLL 变少，同时还消除了在模块初始化和请求处理过程中所需的内存分配工作。图 2显示了在相同的吞吐量测试中内存的使用量（IIS 工作进程专用字节）。尽管在此示例中改进并不明显，但增长是符合预期的，因为 ASP.NET appdomain 的开销相对要高于移除模块所带来的基线节约开销。

　　图 2 在具有 100 个并发客户端的三种不同配置情况下，静态工作负载和 ASP.NET 工作负载的内存使用量（专用字节）（单击图像可查看大图）

　　IIS 7.0 可以对在应用程序级别启用哪些模块提供额外的控制，还可以通过模块预处理来根据工作负载控制模块使用量。尽管这需要高级的配置，但在多站点环境中或对于支持多个不同工作负载的应用程序，它可以提供更多的益处。

　　需要注意的一点是：确定所需功能时可能会比较棘手。您不但必须要考虑支持应用程序框架所需的最少功能，还必须考虑应用程序可能间接依赖的其他功能。例如，您的应用程序可能取决于特定的身份验证方法或依赖于各种 IIS 功能所提供的授权语义，这时如果移除它们可能会对应用程序的安全性产生负面影响。同样，您的应用程序可能依赖于某些模块来实现功能或性能效果，在这种情况下移除它们可能会导致错误的行为或性能损失。

　　构建在瘦操作系统上

　　Windows Server 2008 还提供了操作系统级别的组件化功能，可用于进一步减少 Web 服务器的外围应用。Server Core 是 Windows Server 2008 操作系统的最小安装选项，其中包含最小的核心操作系统子系统集。Server Core 是用于瘦 IIS 7.0 Web 服务器的理想环境。

　　但是，在评估 Server Core 时，要知道某些限制可能影响您的应用程序。Server Core 不提供对 Microsoft .NET Framework 的支持，这也意味着它不支持 ASP.NET、IIS 的 .NET 可扩展性以及 IIS 管理器。此外，由于没有 Microsoft 管理控制台 (MMC) 可供使用，因此本地管理任务需要使用命令行工具。从性能角度来看，如果您已正确利用 IIS 组件化，则在运行 Server Core 和完整的 Windows Server 实现时，您可能不会觉察到应用程序工作负载的内存占用量或吞吐量的差异。这是因为 IIS 和您的应用程序所执行的工作在两个平台上都是相同的。但是有一个地方可以看到差异：服务器的总占用量（包括磁盘空间和内存使用量）。

　　例如，图 3显示了针对完整的 Windows Server 2008 配置和 Server Core 执行静态工作负载测试后，内存占用量的差异。尽管在这两种情况下 IIS 的内存占用量实际完全相同，但 Server Core 的总操作系统内存占用量更低，因此相比而言只需更少的内存即可支持此工作负载。在实际当中，更低的内存占用量可允许在性能较差的硬件中部署应用程序工作负载，因为它关注的是应用程序的处理需求而非操作环境。当然，这也使得 Server Core 成为用于虚拟环境的首选。

　　图 3 执行静态工作负载测试后，完整的 Windows Server 2008 与 Server Core 的内存占用量（单击图像可查看大图）

　　专用的应用程序拓扑

　　优化应用程序工作负载时，可将工作负载分成多个不同的部分。例如，您可以在具有 10 个 Web 服务器、5 个应用程序服务器和 3 个代理服务器（用来执行缓存和压缩操作）的场中运行应用程序，而不是在具有 30 个相同 Web 服务器的场中运行它。

　　采纳特殊处理的原因有多种。首先，许多应用程序工作负载的性能在很大程度上都取决于应用程序的多个部分之间可以竞争得到的各种共享资源（如内存）。此类资源竞争可能产生瓶颈问题，导致各种资源无法充分利用每台服务器。通过分离应用程序的各个部分，可使其能够随时访问被竞争资源，从而使同样的硬件资源组发挥更高的效率。

　　其次，特殊处理可使应用程序获得更合适的缓存区域，从而改善其性能。这包括低级缓存（如虚拟内存转换旁路缓冲器 (TLB)）、文件系统缓存以及其他操作系统和应用程序缓存。另一种区域资源来自 CPU。通过仅关注应用程序的特定部分来减少所发生的并行活动数后，应用程序可减少上下文切换次数并将 CPU 的工作效率提高到最大。

　　第三，特殊处理可实现特定于工作负载的优化，从而使应用程序各个部分的工作效率更高。当在同一个服务器上支持整个应用程序时，由于应用程序的不同部分存在需求冲突，因此许多此类优化都无法实现。

　　一 个经常发生此类情况的位置是 IIS 和 ASP.NET 线程配置，它会对并发性产生直接的影响，并会间接影响许多应用程序的内存使用量、延迟时间和吞吐量。IIS 静态文件工作负载严重不同步，需要施加高并发请求限制，但它只需极少量的可用线程即可正常工作。另一方面，许多 ASP.NET 功能是同步的，但长时间处于阻塞状态，因此需要较高的线程数，而同时仍有其他一些功能需要较低的并发限制以降低对内存的影响。通过分离静态工作负载，将部分请求处理管道划分到不同的进程或服务器，可优化每个单独工作负载的并发性。

　　最后，通过允许应用程序分别独立扩展离散的工作负载或应用程序部件，特殊处理可以实现更出色的总体可扩展性。这可以使应用程序拓扑在最需要的位置提供更高的容量和冗余性，而不是要求您将相同的模板应用到整个应用程序。在这一模型中，专用资源可能是物理服务器、虚拟服务器甚至是同一台计算机中的应用程序池。

　　要评估在应用程序拓扑中特殊化可能带来的好处，首先应找出应用程序中占用大量进程或资源的瓶颈。这些方面应作为特殊化的首要候选对象，因为在隔离后它们可能具有显著的优化潜力，并且它们将会需要最高级别的横向扩展。接下来评估在隔离它们之后，应用程序的剩余部分是否能更有效地利用资源。最后，还需要评估将隔离的应用程序组件组合在一起所需的连接机制的开销。

　　改进的应用程序支持

　　IIS 7.0 可以通过 FastCGI 实现对应用程序框架的扩展支持，FastCGI 是一种受到许多开源应用程序框架支持的开放式协议，如果不使用 FastCGI，这些应用程序框架可能不支持与 IIS 稳定的、高性能的原生集成。与 IIS 长期以来一直支持的 CGI（通用网关接口）协议不同的是，FastCGI 可以在 Windows 平台上提供明显改善的性能。这主要得益于 FastCGI 可重用的进程体系结构，它免去了针对每个请求创建进程的繁重开销，使客户端可以利用永久保持活动状态的连接。

　　如果您现在是使用 CGI 或其他机制来使 IIS 支持应用程序框架，则迁移到 FastCGI 协议可能会得到更好的性能（有时还可以得到更好的稳定性）。

　　利 用此支持的第一个应用程序框架是 PHP。实际上，IIS 团队一直在与 Zend Technologies 进行直接的合作以确保 IIS FastCGI 实现能与 PHP 良好配合，并能够给 Windows 中的 PHP 框架带来性能的改进。（有关此项目的详细信息，请参阅我博客上的帖子，网址为 go.microsoft.com /fwlink/?LinkId=122509。）如果您使用的是混合 Web 服务器技术（例如运行在 IIS 上的 ASP 或 ASP.NET 应用程序，以及使用其他技术的 PHP 或与 FastCGI 兼容的其他应用程序框架），则可以在 IIS 7.0 平台上进一步巩固这些应用程序。

　　通 过将 PHP 和其他应用程序框架迁移到 IIS 7.0 和 FastCGI，您可以充分利用 IIS 7.0 的各种功能，包括 ASP.NET 集成管道。利用它可以通过 ASP.NET 服务非常方便地增强应用程序框架，而不必再将其转换到 ASP.NET。并且它还可以使那些使用不同框架的应用程序协同工作。有关如何使用它在不改动任何代码的情况下来增强现有应用程序并改善应用程序性能的示例，请参阅我撰写的《MSDN 杂志》文章“使用集成的 ASP.NET 管道增强应用程序”（网址为 msdn.microsoft.com/magazine/cc135973.aspx）。

　　增加应用程序密度

　　IIS 7.0 包括许多旨在增加可在单台服务器上托管的应用程序密度的增强功能。这些增强功能是 IIS 7.0 引入的用来改进共享托管质量的众多功能中的一部分，其中包括改进的站点置备和更好的应用程序隔离。

　　从性能角度看，这些改进主要关注在两个方面增加应用程序密度 —增加可在单台 IIS 7.0 服务器上置备的应用程序数量，以及增加可在给定时间内处于活动状态的应用程序数量。

　　请注意，IIS 7.0 能够在每台服务器上置备的应用程序数量要大幅超出以前，在某些内部测试中，单台服务器上最多可置备 100,000 个站点。这就为其赋予了创建和配置大量站点和应用程序的能力。

　　需 要注意的一点是：要实现高速置备，需要迁移到新的配置 API，因为较老的配置 API 无法实现这一点。此外，并非所有 IIS 配置 API 都提供相同的性能特性，因此必须仔细选择以确保实现高性能。如果有疑问，可使用直接利用最新 IIS 配置对象的配置选项，其中包括 Microsoft.Web.Administration 命名空间、AppCmd.exe 命令行工具以及 IIS COM 配置对象（可通过脚本、.NET 或 C++ 代码进行访问）。

　　在使用持久应用程序和工作进程来执行请求处理的 IIS 体系结构中，可置备的站点数和可处于活动状态的站点数之间的差别是一个非常重要的区别。在此模型中，活动的应用程序会消耗服务器上更多的资源，但同时它也会由于缓存和免去初始化成本等原因而提供更好的持续性能。

　　由于每个活动的应用程序都需要特定数量的内存和单独的工作进程（如果使用的是建议的应用程序隔离模型），所以活动应用程序的数量在很大程度上取决于应用程序的内存占用量。因此，对于仅提供静态内容的单个应用程序，其工作进程可能只需要 3MB 的内存（甚至还可以与其他静态内容应用程序共享同一个工作进程），但某些动态应用程序即使在低使用率情况下也可能需要 100MB 甚至更多的内存。这样一来，在定义最大的可能密度时，与应用程序的内存使用量相比，IIS 工作进程本身的内存开销就显得无关紧要了。

　　在典型的共享托管情形中，经常可以看到被称为 80/20 分布的现象，即 80% 的请求被转到 20% 的站点。这会导致少量站点始终处于活动状态。为允许更大数量的活动站点，IIS 7.0 提供了活动的生命周期管理。这可以帮助您从非活动应用程序回收内存以允许托管更多的活动应用程序。

　　IIS 7.0 引入了一种称为动态空闲的新算法，它可以根据服务器的可用内存主动调整工作进程的空闲超时时间。随着内存逐渐减少，删除空闲应用程序的速度会加快，因此允许托管更多的活动应用程序。但是，在有内存可用的情况下，此超时时间可维持一个比较大的数值，以提供更好的性能并维护应用程序状态。除了允许更多的应用程序处于活动状态外，动态空闲还有助于避免低内存状况出现，这种状况会由于超负荷而导致严重的性能降级。

　　要 实现大量活动应用程序的托管，还应采用 64 位操作系统，因为它允许操作系统处理超过 4GB 的内存。此外，您还可以将 IIS 工作进程配置为在 32 位模式 (SysWoW64) 下运行，此时它们本身消耗的内存更少，同时还允许操作系统比在 32 位环境中寻址更多的内存。

　　通过压缩来降低带宽

　　带宽成本是运行面向 Internet 的数据中心的首要成本之一，这一点不足为奇。此外，提供请求内容所需的带宽是应用程序感知响应中的一个关键因素。

　　减 少提供应用程序响应所需的带宽的其中一种最有效方法是使用 HTTP 压缩。它可以大幅减少响应的大小，对于容易压缩的文本内容（如 HTML），通常可减小到原来的 1/10。其最大优势在于所有桌面浏览器都支持它，并且与由于发送较少的数据而节省的延迟时间相比，桌面硬件的解压缩开销显得无关紧要。此外由于压缩是基于 HTTP 1.1 协议中所定义的内容编码协商，因此启用它对于不支持压缩的客户端而言是安全的 —这些客户端仅接收未压缩版本的内容。

　　IIS 7.0 也包含其前身引入的以下两个压缩功能：静态压缩和动态压缩。静态压缩会预压缩静态内容并将其保存在磁盘上，因此允许未来的请求无需压缩开销即可直接提供压缩后的内容。动态压缩会实时压缩响应，因此可以压缩由应用程序生成的响应。IIS 7.0 上的任意应用程序框架都可以利用动态压缩 —包括 ASP、ASP.NET 或 PHP。

　　动态压缩通常并没有令人望而却步的 CPU 开销，这一点让很多人感到疑惑。实际上，动态压缩一般只占用繁忙服务器上不到 5% 的总 CPU 使用率。动态压缩的部署不受限制，从而可以使应用程序工作负载节省尽可能多的带宽。

　　可 通过配置压缩强度进一步优化压缩开销，从而实现所需的压缩量与 CPU 开销之比。但还不只这些 —您还可以对应用程序进行配置以启用压缩内容缓存功能，这将可以通过提供已压缩的内容来避免出现对命中缓存的压缩开销。请注意，ASP.NET 和 IIS 输出缓存都进行了升级，现在既可以为支持压缩内容的客户端缓存压缩的内容，也可以处理来自需要未压缩内容的客户端的请求。

　　媒体比特率限制

　　随着越来越多的站点提供媒体内容，导致许多企业的带宽成本激增。更为糟糕的是，由于发送到客户端的媒体内容实际上根本没有被用到，因而浪费了大量的媒体带宽。为什么会发生这种情况？

　　想想上次浏览时您观看在线视频或视频广告的情形。您是否一直在观看视频直到结束？在浏览视频网站时，用户通常都是在观看视频的一部分后就转到了另一个视频或离开该页面。但是，对于使用渐进式下载方式来提供视频的 Web 服务器而言，它所发送的数据通常要远远多于这几秒播放时间所需的数据。大部分数据根本就没有使用到。

　　如果视频的观看时间平均只有 5 秒，但在这 5 秒钟内提供（缓存）了 30 秒钟的视频数据，则您可能浪费了超过 80% 的带宽！

　　一年前，为了帮助一位使用测试版 IIS 7.0 的客户解决这一问题，我编写了一个带宽限制模块，它可以自动检测视频比特率并确保服务器以大致相同的速率向客户端提供视频。IIS 媒体团队选择了这一称为“比特率限制模块”的模块（请参阅图 4），您可以在 iis.net 下载中心下载它 (iis.net/downloads/?tabid=34&g=6& i=1640)。有关详细信息，请参阅 Scott Guthrie 的博客（网址为 go.microsoft.com /fwlink/?LinkId=122514）。

图 4 比特率限制最小化带宽使用率（单击图像可查看大图）

　　“比特率限制模块”会自动检测最常见的视频类型的编码速率。您可以控制想要预发送到客户端以消除初始缓存延迟的数据量（快速启动）以及希望在提供内容时使用的编码率百分比。您还可以配置许多其他选项（如最大带宽和并发连接），并可以通过编程方式来控制模块。

　　输出缓存

　　一般而言，对于执行重复工作的应用程序而言，缓存是改善其性能的首选方法。与特定于应用程序的性能改善不同（它们通常需要花费大量的精力并不断耗用应用程序的处理开销），缓存可以免去重复请求相同内容的开销。

　　在 IIS 7.0 之前，IIS 和 ASP.NET 都以 IIS 内核缓存和 ASP.NET 输出缓存的形式提供缓存功能。IIS 内核缓存可提供最优的性能，但主要限于静态内容。ASP.NET 输出缓存是用于缓存动态内容的相当完善的解决方案，但其性能较低而且内存管理效率也不高。IIS 7.0 中新的输出缓存弥合了 IIS 内核缓存和 ASP.NET 输出缓存之间的沟壑。

　　IIS 7.0 输出缓存可缓存任意应用程序（包括 ASP、ASP.NET、PHP 以及与 IIS 7.0 兼容的任何其他应用程序框架）中的动态内容。通过提供对内容可变性和过期的基本支持，这一新功能可缓存 IIS 内核缓存无法缓存的内容。并且，它允许针对满足限制条件的内容使用内核缓存。

　　此外，对于不需要高级缓存功能（如缓存依赖关系或无效化）的 ASP.NET 内容，IIS 7.0 输出缓存还提供了比 ASP.NET 输出缓存性能更高的替代方案，但只能在 ASP.NET 输出缓存中使用。

　　说到输出缓存，最大的挑战通常在于如何定义正确的内容过期、无效化和可变性策略，从而在维持所需的缓存准确性和时效性的同时实现高效的响应缓存。大多数情况下，只需正确配置缓存规则即可做到这一点，但有时则需要一些取决于运行时信息的更加复杂的策略。为此，IIS 7.0 输出缓存提供了可用于确保所需的缓存行为的编程 API。这可以为本来不会从缓存受益的内容释放缓存性能潜力。此外，ASP.NET 集成管道可使非 ASP.NET 内容使用 ASP.NET 输出缓存。

　　部署动态内容的输出缓存可能会比较棘手，可能需要一个多层战略来利用 IIS 7.0 平台上各种缓存功能的效率和灵活性。这通常包括描述影响响应的多个参数，还包括首先定义过期和无效化战略以维持缓存的最新状态，然后再确定哪些缓存支持所需的语义。

　　尽管比较复杂，但还是值得为此付出的。通过实现 IIS 7.0 输出缓存，应用程序的总吞吐量可获得多个数量级的改进，并且数据库和业务层组件的负载也会相应减少。

　　将 ISAPI 代码转换成 IIS 7.0 模块

　　IIS 7.0 引入了一个新的服务器 API，所有 IIS 7.0 模块均以其作为基础。它取代了先前版本的 IIS 中使用的传统 ISAPI 过滤器和 ISAPI 扩展 API。对于不需要支持先前版本的新模块，新的 API 更易于使用、可帮助生成更可靠的服务器端代码并且功能会更强大。

　　但是，IIS 7.0 为此提供了一个选项，允许通过利用可选 IIS 7.0 模块实现的兼容性层来支持现有的 ISAPI 过滤器和扩展。这将允许现有 ISAPI 组件无需重写代码即可在 IIS 7.0 上运行。

　　尽 管使用现有的 ISAPI 投资可降低 IIS 7.0 迁移的门槛，但必须要充分考虑如何将传统 ISAPI 代码导入到新的 IIS 7.0 API 中。这样做可免去 ISAPI 兼容性层的开销，并产生 ISAPI 组件不具备的一些性能优势。这些性能优势可能会十分显著，具体视 ISAPI 组件所执行工作的而定。例如，对于缓存配置元数据以及与站点、应用程序和 URL 相关联的任何其他数据，IIS 7.0 模块 API 都提供内置的支持，这可以明显加快组件的内部操作速度。

　　此 外，IIS 模块 API 允许模块异步执行长时间运行的操作，例如接收请求实体数据或发送响应。通过异步执行这些任务，服务器可以支持大量的并发客户端（成千上万），而不会由于请求线程数量的限制而最多只能支持几十个或最多几百个并发客户端。异步处理还可以消除处理应用程序中其他的请求和活动时带来的影响、减少内存使用量以及得到更好的 CPU 利用率。

　　除 了特定的性能影响模式外，原生 API 还可以使开发人员更加灵活地执行请求处理任务。它允许您改进服务器组件的设计，从而实现更高的效率。例如，对于一些在以前需要通配符 ISAPI 扩展和子请求执行的特定过滤任务，现在既可以在初始请求过程中在模块中执行，也可以针对响应启用 IIS 内核缓存。

　　这可能会需要一些原型设计和试验以确定可以实现迁移好处最大化的最优设计。由于 ISAPI 和 IIS 7.0 模块 API 之间存在基本体系结构的差异，因此直接移植路由不一定是正确的。要告诉大家的好消息是 IIS 7.0 模块 API 比 ISAPI 使用起来更简单，因此迁移难度会降低。

　　服务器可扩展性

　　IIS 7.0 提供端到端可的扩展性。它需要事先了解有关服务器操作的大量知识，尽管如此，它还是展示了改进特定于应用程序的性能的巨大潜力。在对服务器体系结构和请求处理有了一定的了解后，可利用此扩展性来设计自定义的性能解决方案，以适合您的应用程序、工作负载和硬件的需求。

　　这 可以采用以自定义的实现来替换任意内置的 IIS 7.0 功能的形式。尽管 IIS 7.0 功能已经做了大量的优化和性能测试，但肯定无法针对每种可能的用途都进行优化。因此，您可以通过构建针对特定工作负载的优化来改善特定模块的性能。例如，您可能希望重新实现目录列表模块来缓存内存中的目录列表，而不是使用文件系统 API 来枚举文件。

　　此外，可扩展性也可用于构建新的性能特性。此类功能的内置示例包括输出缓存、压缩模块以及多种其他内部缓存。

　　要确定自定义性能特性的需求，您需要了解应用程序和工作负载的性能特性以及需要解决的瓶颈问题。IIS 7.0 为性能分析提供了充足的诊断支持，可使需求和所需的可能设计功能更加清晰。

　　结束语

　　尽管 IIS 7.0 版本主要是一个功能版本，但它通过模块化的体系结构、可配置性和新增的性能特性提供了显著的性能改善。这些改善通过服务器合并和减少的带宽成本为企业成本节约铺平了道路，并且可以提供更好的用户体验。

　　要正确利用这些改进，通常必须针对当前的应用程序平台执行全面的分析并对 IIS 7.0 体系结构有充分的了解。如需有关本文中提及的 IIS 7.0 体系结构和功能的详细信息，请访问 iis.net。在 mvolo.com中，我将撰写更多的博客文章来介绍有关主动利用 IIS 7.0 来改进应用程序性能和降低运营成本的技术。

　　Mike Volodarsky之前是 Microsoft IIS 团队的一名项目经理。在过去的五年时间里，他一直在推动 ASP.NET 2.0 和 IIS 7.0 核心功能的设计与开发。现在，他正在利用 IIS 7.0 和 Windows Server 2008 为高性能 Web 场构建高级 Web 服务器技术。Mike 是《IIS 7.0 Resource Kit》一书的主要作者，并且经常为《MSDN 杂志》和 IIS 7.0 博客 (mvolo.com) 撰写文章。