在IIS 7.0中的10大性能改进
迈克沃洛达尔斯基
概览：
- 最小化您的应用程序足迹
- 降低带宽成本
- 使用增强的缓存能力
当我遇到公司计划采用IIS 7.0中，一个问题，不可避免地是移动到IIS 7.0服务器或应用程序的性能提高。该
答案是肯定的，但并不感到惊讶，当你没有看到当你第一次将应用程序迁移到IIS 7.0的性能改进。
要理解这一点，你需要了解的性质的最新版本。IIS 6.0是一个工程旨在释放完成三件事情：更强的安全性，可靠性更高，并提高了性能。相比之下，IIS 7.0是一个平台发布。其目的是将高品质的基础Web服务器核心的模块化和可扩展的平台，其前身为重点的现代部署和管理方案的支持。
实际上可能有很多的建筑变化，新特点考虑Web服务器的性能产生负面影响，例如，一个关键的变化紧紧优化Web服务器的代码路径爆发成独立的模块，没有得到特殊待遇Web服务器上。但是，由于很多IIS团队绩效工作，IIS 7.0仍然在其前身性能校验和在某些方面超过它。我可以亲口告诉你的工作在Web服务器上的核心和集成管道，实现这一目标需要很多别出心裁的设计和辛勤工作，在实施产品。
然而，IIS 7.0具有更高的潜力提供重大的性能改进和降低性能相关的成本为您的服务器场，比任何其他的IIS释放在过去。
你不一定要看到这些好处，仅仅通过迁移到IIS 7.0，但某些环境。Microsoft.com例如，在CPU效率提高了10％，（Microsoft.com团队博客上，你可以找到完整的分析
go.microsoft.com / fwlink的的/？LINKID = 122497
）。您可能也注意到在特定的领域，包括安全套接字层（SSL）和Windows
®
认证（现在都在内核中执行），在多核和多处理器机器的可扩展性更好的垂直明显的改善。
尽管如此，真正的IIS 7.0马力并不来自增量性能改进现有功能。相反，改进来自于新的功能，你必须积极利用。这些功能往往植根的灵活性和可扩展性的平台和新的性能特性。在这篇文章中，我会告诉你10，你可以解锁移动到IIS 7.0的性能改进的最重要来源。
精简的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工作量大幅增加的吞吐量在最小配置结果。
.gif)
图1
吞吐率静态的工作量和ASP.NET三种不同的配置有100个并发客户端的工作量
（单击图像可查看大图）
此外，您可能会看到在内存占用和更高的现场密度的改进，尤其是在共享的托管环境或大量的工作进程的情况下，正在使用。这通常是获得的少的DLL加载到每个进程和消除模块的初始化以及请求处理过程中发生的任何内存分配。
图2
显示了相同的吞吐量测试中的内存使用（私有字节IIS工作进程）。虽然在这个例子中没有明显的改善，增幅分别符合预期，ASP.NET应用程序域的开销相对高于拆除的模块所提供的节省基线。
.gif)
图2
内存使用率（专用字节）的静态和ASP.NET三种不同的配置有100个并发客户端的工作量
（单击图像可查看大图）
IIS 7.0提供额外的控制模块在应用程序级别启用，以及模块的使用控制权的基础上通过模块的先决条件的工作量。虽然这需要先进的配置，它可以在多站点环境或应用程序，支持多种不同的工作负载提供额外的好处。
一个字谨慎：确定您需要的功能可能会非常棘手。你必须考虑的不仅是最小的功能来支持您的应用程序框架，而且任何附加功能，您的应用程序可能会间接依赖。例如，您的应用程序可能会依赖于特定的身份验证方法，或依靠授权语义上提供的各种IIS功能，在这种情况下，去除那些可能会产生不利影响您的应用程序的安全性。同样，您的应用程序可能会依靠一些模块的功能或性能的影响，在这种情况下，移除它们可能会导致不正确的行为或性能损失。
构建精益操作系统
的Windows Server
®
2008还提供了OS级别的组件，你可以用它来 进一步降低您的Web服务器的表面积。为Windows Server 2008操作系统的服务器核心安装选项是一个最小的，并且包含最小的一组核心OS子系统。服务器核心精益IIS 7.0 Web服务器是一个理想的环境。
但是，当评估服务器核心，要知道，一些限制可能会影响您的应用程序。服务器核心不提供Microsoft
®
。NET Framework的支持，这意味着，没有ASP.NET，没有IIS NET的可扩展性，并没有IIS管理器。另外，本地管理的任务将需要命令行工具，因为没有Microsoft管理控制台（MMC）。从性能的角度来看，如果你已经正确利用的IIS组件化的，你可能看不到内存占用或在Server Core上运行的应用程序的工作量与一个完整的Windows Server实现吞吐量的差异。这是因为IIS和您的应用程序的工作是相同的两个平台上。然而，有一个地方，在那里你会看到一个不同：整体的足迹，无论是在服务器的磁盘空间和内存的使用方面。
作为一个例子，
图3
显示的差异足迹后进行静态的工作量测试一个完整的Windows Server 2008的配置和服务器核心。虽然在这两种情况下，IIS足迹几乎是相同的，更低的总体OS足迹允许的工作量显着更少的内存来支持服务器核心。较低的足迹实际上可能让你更强大的硬件上部署应用程序的工作量，专注于应用程序的处理需求，而不是经营环境。当然，这使得服务器核心虚拟化环境的一个很好的选择。
.gif)
图3
完整的Windows Server 2008中对服务器核心后执行工作量静态测试内存占用
（单击图像可查看大图）
专业应用拓扑
当应用程序工作负载优化，可以分隔成不同的部分工作量。例如，而不是一个农场，30个相同的Web服务器上运行应用程序，你可以运行10个Web服务器，应用服务器，代理服务器进行缓存和压缩。
有几个原因为什么这种专业化工作。首先，许多应用程序工作负载的性能在很大程度上取决于各种共享资源，如内存，这可能是有争议的多个部分之间的应用程序。对这些资源的竞争可以建立在其他的资源得到充分利用，防止每个服务器的瓶颈。分离的应用程序部分给出的部件准备好，否则有争议的资源的访问，从而导致更高的效率，在同一组硬件资源。
二，专业化可以使应用程序能够实现更大的缓存局域性，从而提高了性能。这包括低级别的高速缓存，如虚拟内存的转换后备缓冲器（TLB），文件系统缓存，和其他操作系统和应用程序缓存。另一个来源的局部性增益来从CPU。只集中在一个特定的应用程序的一部分，正在发生的平行活动的数量减少，可以降低应用程序的上下文切换的数量，并最大限度地提高由CPU执行的工作。
第三，专业化使特定工作负荷的优化，使每个部分的应用更高效地工作。许多这些优化是不可能的整个应用程序时，应用程序的不同部分的相互矛盾的需求，由于在同一服务器上支持。
一个共同的地方，发生这种情况是IIS和AS P.NET线程配置，这大大影响并发和间接影响许多应用的内存使用率，延迟和吞吐量。IIS静态文件的工作量是非常异步的，需要一个高并发请求限制，但它生长在一个非常低的可用线程数。另一方面，许多的ASP.NET功能是同步的，长期封锁，并要求高的线程数量，同时还有一些人要求较低的并发限制，以减少对内存的影响。通过分离静态的工作量，摆脱到一个单独的进程或服务器的请求处理管道，你可以优化的并发性，每一个人的工作量。
最后，专业化可以使更大的整体可扩展性，允许应用程序向外扩展离散工作量或彼此独立的应用程序部分。这可以使应用程序的拓扑结构提供更高的容量和冗余最需要它的地方，而不是要求你整个应用程序的应用同一模板。在这种模式下，专业的资源可能是物理服务器，虚拟服务器，甚至是在同一台机器上的应用程序池。
当评估专业化的潜在好处在你的应用程序拓扑，开始在您的应用程序中找到处理或资源密集型的瓶颈。这些地区应该是第一候选人专业化隔离时，因为他们可能提供了显着的优化潜力，因为他们将要求最高水平的规模。然后，评估是否把它们分离出来，使其余的应用程序更有效运用资源。最后，您将需要评估的开销带来的孤立的应用程序组件的连接机制。
改进的应用程序支持
IIS 7.0通过FastCGI的应用程序框架，一个开放的协议所支持的许多开源应用框架，否则可能不支持稳定和高性能的原生整合IIS的扩展支持。的FastCGI与CGI（公共网关接口）协议，该协议已经得到了很长一段时间的IIS，在Windows平台上提供性能大大改善。这主要是由于FastCGI的可重复使用的流程架构，消除了沉重的每个请求的进程创建开销，从而使客户能够利用持续保持活着连接。
如果IIS使用CGI或其他机制支持的应用程序框架，你可能会达到提高性能（在某些情况下，稳定），通过移动FastCGI协议。
第一个应用程序框架，以利用这种支持是PHP。事实上，IIS团队曾直接与Zend技术，以确保，IIS与PHP FastCGI的实施工作，使性能改进在Windows上的PHP框架。（欲了解更多关于该项目中，在我的博客上看到张贴在
go.microsoft.com / fwlink的的/？LINKID = 122509
）。如果你有一个ASP或ASP.NET应用程序运行在IIS的Web服务器技术，包括混合， PHP或其他符合FastCGI的应用框架，使用其他技术，你可能会在IIS 7.0平台，能够整合这些应用程序。
移动到IIS 7.0和FastCGI PHP和其他应用程序框架将允许您利用各种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使得它可以提供较大数目的每个服务器上的应用程序比以前的一些内部测试中，高达100000网站在单个服务器上是可能的。这吸引了大量的网站和应用程序创建和配置的能力。
一个字谨慎：为了实现高速的配置，你需要移动到新的配置API，为老年人配置API无法实现它。此外，并非所有的IIS配置API都提供相同的性能特点，因此需要慎重的选择，以确保高性能。如果有疑问，去利用新的IIS配置对象，包括Microsoft.Web.Administration命名空间，使用AppCmd .exe命令行工具，和配置IIS COM对象从脚本访问。NET或C + +代码直接配置选项。
多少个站点，可以配置多少可以积极的区别在IIS架构是一个非常重要的区别，使用持久的应用程序和工作进程去处理请求。在这个模型中，活跃的应用程序服务器上的消耗更多的资源，但还提供了更好的持续性能，由于缓存和删除的初始化成本。
因为每个活跃的应用程序需要一定量的内存和一个单独的工作进程（如果正在使用所推荐的应用程序隔离模型），活跃的应用程序，在很大程度上依赖于应用程序的内存占用。因此，其工作进程（甚至可以共享相同的工作进程与其他静态内容应用），而一个单一的应用程序，只提供静态内容可能只需要3MB，一些动态的应用程序可能需要100MB以上的RAM，即使在低使用率。这使得IIS工作进程本身微不足道的内存开销相比，应用程序的足迹时，确定可能的最大密度。
在典型的共享主机方案，它是经常可以看到什么是所谓的80/20分配，要求的80％到20％的站点。这将导致在一个小的百分比的地盘的在任何给定的时间。要允许更多数量的活性位点，IIS 7.0提供了有效的生命周期管理。这可以帮助你从无效的应用程序，以便让更积极的应用程序可以托管回收内存。
IIS 7.0引入了一个新的算法，称为动态闲置，闲置超时工作进程，主动调整的基础上在服务器上的可用内存。由于内存变低，闲置的应用程序更迅速地去除，从而使更积极的应用程序可以托管。但是，如果内存可用，超时可以留大，以提供更好的性能和维护应用程序状态。除了允许更多的应用程序激活，动态无功也有助于避免内存不足的情况 ，由于颠簸导致严重的性能退化。
要举办许多活跃的应用成为可能，你也应该利用一个64位的操作系统，因为这将允许操作系统，以解决超过4GB的内存。在此之上，你可以配置IIS工作进程运行在32位模式下（SYSWOW64），在那里他们消耗更少的内存，同时允许自己的操作系统，以解决更多的内存比在32位环境中什么是可能的。
从压缩减少带宽
这毫不奇怪，带宽成本是一个面向Internet的数据中心运行成本的顶级。此外，提供所需的带宽要求的内容感知应用程序的响应是一个关键因素。
需要将应用程序交付的反应，以减少带宽的最有效的方法之一是使用HTTP压缩。这可以减少响应有很大数量的大小，通常可以放大10时，适用于轻松地可压缩的文本内容（如HTML）。最好的部分是，几乎所有的桌面浏览器都支持它，和桌面硬件解压成本相比是次要的发送更少的数据延迟储蓄。因为压缩是基于HTTP 1.1协议中定义的内容编码协商，使客户端不支持，它是安全的压缩这些客户只接收未压缩版本的内容。
IIS 7.0提供了两种压缩功能介绍它的前身：静态压缩和动态压缩。静态压缩前压缩静态内容，并将其保存在磁盘上，从而使将来的请求提供压缩的内容的情况下直接压缩开销。动态压缩压缩实时的响应，因此，可以由应用程序产生的响应的压缩。在IIS 7.0上的任何应用程序框架，可以利用动态压缩，包括ASP，ASP.NET或PHP。
尽管一个共同的神话，动态压缩通常不会有一个令人望而却步的CPU开销。事实上，动态压缩往往导致繁忙的服务器上的CPU利用率不到5％。可以部署动态压缩有点宽松，允许任何应用程序工作负载的最大带宽节省。
可进一步优化配置，以实现所需的压缩对CPU开销比的压缩强度，压缩开销。但它不会停在那里，你还可以配置你的应用程序启用缓存压缩的内容，已经压缩的内容服务，消除了压缩开销缓存命中。请注意，ASP.NET和IIS输出缓存已经升级与可选的能力，以支持它的客户端缓存压缩的内容，以及客户需要压缩内容的处理请求。
媒体比特率限制
随着越来越多的网站提供媒体内容，对于许多企业的带宽成本暴涨。更糟的是，有很大比例的媒体内容发送到客户端的媒体带宽被浪费，因为从来没有真正使用。为什么会出现这种情况呢？
想想你最后一次观看在线视频或浏览时看到视频广告。你看视频的结束？这是常见的浏览视频网站的用户观看移动到下一个视频或离开页面之前，只有部分视频。但是，Web服务器通常会采用渐进式下载，提供视频发送更多的数据比需要的那几秒钟的游戏时间。大多数的数据永远不会被使用。
如果您的视频平均观看时间只得到5秒，但交付（缓冲区）30秒，值得那些5秒的视频数据，你可能会浪费80％以上的带宽！
一年前，为客户解决这个问题，采用IIS 7.0的beta版本，我写了带宽限制模块，自动检测视频比特率，并确保服务器到客户端，在大致相同的速率提供视频。IIS媒体团队拿起这个模块，这是被称为“比特率限制模块（
见图4
），可在下载中心iis.net（
iis.net /下载/ TABID = 34＆G = 6＆I = 1640
）。您可以了解更多关于它的Scott Guthrie的博客（在
go.microsoft.com / fwlink的的/？LINKID = 122514
）。
.gif)
如图4
比特率限制减少了带宽使用
（单击图像可查看大图）
比特率限制模块自动检测最流行的视频类型的编码速率。您可以控制 多少数据你想预先发送给客户端，以消除初始缓冲延迟（快速启动），在什么比例的编码率，你想提供内容。您也可以配置许多其他选项，如最大的带宽和并发连接，控制模块编程。
输出缓存
一般来说，缓存是头号的方式来提高性能的应用程序执行重复劳动。不同应用的特定性能改进，这往往需要很大的努力和咀嚼了一个应用程序的处理开销，缓存消除重复请求相同内容的开销。
此前IIS 7.0，IIS和AS P.NET提供了缓存功能，在IIS内核缓存和ASP.NET输出缓存的形式。IIS内核缓存提供最大的性能，但主要限于静态内容。ASP.NET输出缓存缓存动态内容，尽管有较慢的性能和高效的内存管理少了一个更为完整的解决方案。在IIS 7.0中的新的输出缓存IIS内核缓存和ASP.NET输出缓存之间架起了一座桥梁。
IIS 7.0输出缓存，能够从任何应用程序，包括ASP，ASP.NET，PHP，和任何其他的IIS 7.0兼容的应用程序框架的动态内容缓存。通过提供内容的可变性和过期的基本支持，这个新的功能使得它可以实现缓存的内容不能被缓存由IIS内核缓存。尽管如此，它能够使用的内核缓存的内容并满足的限制。
此外，IIS 7.0输出缓存还提供了更高的性能替代ASP.NET输出缓存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引入了一个新的服务器，所有的IIS 7.0模块都是基于API。这取代了传统的ISAPI筛选器和ISAPI扩展API使用以前版本的IIS。对于不需要支持以前版本的新模块，新API的使用更方便，有利于产生更可靠的服务器端代码，并且变得更加强大。
但是，IIS 7.0提供了一个选项，以支持现有的ISAPI筛选器和扩展通过可选的IIS 7.0模块实现通过一个兼容层。这使得现有的ISAPI在IIS 7.0组件的功能，而无需重写。
虽然使用现有的ISAPI投资降低门槛迁移到IIS 7.0，你应该认真考虑传统的ISAPI代码移植到新的IIS 7.0的API。这样做可以消除ISAPI兼容层的开销和解锁所不具备的ISAPI组件的性能优势。根据正在执行的ISAPI组件的工作，这些性能优势是相当显着的。例如，IIS 7.0模块API提供了内置的缓存配置元数据和其他相关的网站，应用程序和URL的任意数据，它可以显着加快内部操作的组件的支持。
此外，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，以提高应用程序的性能，并降低运营成本。
迈克沃洛达尔斯基
是前微软IIS团队的项目经理。在过去的五年中，他一直在推动ASP.NET 2.0和IIS 7.0的核心功能的设计和开发。现在，他建立技术先进的Web服务器使用IIS 7.0和Windows Server 2008的高性能Web农场。迈克是主要领导者的书
IIS 7.0 Resource Kit中，
并写入积极
MSDN杂志
及他的IIS 7.0的博客，
mvolo.com
。