您好、欢迎来到现金彩票网!
当前位置:国民彩票app下载 > 高速缓存块 >

IIS 70 中的 10 大性能改进

发布时间:2019-07-01 15:39 来源:未知 编辑:admin

  :当我与计划采用 IIS 7.0 的公司会面交谈时,每次都要提到的一个问题就是迁移到 IIS 7.0 是否会改善服务器或应用程序的性能。答案通常是肯定的,但如果在将应用程序刚刚迁移到 IIS 7.0 时并没有看到任何性能改善,也请不要感到惊讶。 要理解这一点,您需要了解最新版本自身的一些特点。IIS 6.0是工程版本,旨在实现以下三个目标:更强的安全性、更高的 ...

  当我与计划采用 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,您可以通过某些环境进行了解。例如,的 CPU 效率出现了 10% 的改进(可在 团队博客上找到完整的分析,网址为go.microsoft.com /fwlink/?LinkId=122497)。您可能还会发现在某些特定领域也有显著的改进,例如安全套接字层 (SSL) 和 Windows® 身份验证(现在二者均在内核中执行),此外在多核和多处理器计算机中它也可以提供更出色的垂直可伸缩性。

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

  在具有 100 个并发客户端的三种不同配置情况下,静态工作负载和工作负载的内存使用量(专用字节)

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

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

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

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

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

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

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

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

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

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

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

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

  通 过将 PHP 和其他应用程序框架迁移到 IIS 7.0 和 FastCGI,您可以充分利用 IIS7.0 的各种功能,包括 ASP.NET 集成管道。利用它可以通过 ASP.NET 服务非常方便地增强应用程序框架,而不必再将其转换到ASP.NET。并且它还可以使那些使用不同框架的应用程序协同工作。有关如何使用它在不改动任何代码的情况下来增强现有应用程序并改善应用程序性能的示例,请参阅我撰写的《MSDN® 杂志》文章“使用集成的 ASP.NET 管道增强应用程序”(网址为/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 输出缓存都进行了升级,现在既可以为支持压缩内容的客户端缓存压缩的内容,也可以处理来自需要未压缩内容的客户端的请求。

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

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

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

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

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

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

  尽管比较复杂,但还是值得为此付出的。通过实现 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 和 IIS7.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。在,我将撰写更多的博客文章来介绍有关主动利用 IIS 7.0 来改进应用程序性能和降低运营成本的技术。

  订阅更新:您可以通过RSS订阅我们的内容更新您可能感兴趣的文章上一篇:小技巧:用简单的js语句定制自己的Chrome“插件”

http://catacurian.net/gaosuhuancunkuai/496.html
锟斤拷锟斤拷锟斤拷QQ微锟斤拷锟斤拷锟斤拷锟斤拷锟斤拷锟斤拷微锟斤拷
关于我们|联系我们|版权声明|网站地图|
Copyright © 2002-2019 现金彩票 版权所有