当我与计划采用 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服务器技巧15则
• 下一篇:IIS 7应用程序管理