IIS 7.0 中的 10 大性能改进

通常是肯定的，但如果在将应用程序刚刚迁移到 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 文件（静态工作负载）和 helloworld ASP.NET 页面（ASP.NET工作负载）进行简单吞吐量测试所得到的结果。尽管大部分不必要的功能在“完整”配置中已被禁用，但在“最小”配置中完全移除它们仍可使静态工作负载和ASP.NET 工作负载的吞吐量都得到大幅提升。

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

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 的内存占用量实际完全相同，但 ServerCore的总操作系统内存占用量更低，因此相比而言只需更少的内存即可支持此工作负载。在实际当中，更低的内存占用量可允许在性能较差的硬件中部署应用程序工作负载，因为它关注的是应用程序的处理需求而非操作环境。当然，这也使得 Server Core 成为用于虚拟环境的首选。

专用的应用程序拓扑

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

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

其次，特殊处理可使应用程序获得更合适的缓存区域，从而改善其性能。这包括低级缓存（如虚拟内存转换旁路缓冲器(TLB)）、文件系统缓存以及其他操作系统和应用程序缓存。另一种区域资源来自CPU。通过仅关注应用程序的特<