[转] ASP.NET 性能提升秘诀之管道与进程优化

  ASP.NET 2.0 中包涵了很多秘密,当你发现它时,可以为你的程序带来更大的性能和扩展性提升。例如,了解了在 Membership 和 Profile provider 提供程序中所隐藏的秘密瓶颈后就可以方便地的解决验证问题并使得授权操作的速度加快。

  另外,ASP.NET HTTP 管道为了避免针对每次请求所要执行的必要代码而发生阻塞。不仅那样,ASP.NET 工作者进程能够推动其限制而获得更高的性能。页面碎片在浏览器端的输出缓存(不是在服务器端)可以显著节约回访者的下载时间。按需求的用户界面下载可以让你的站点给人快速流畅的感觉。

  最后内容传输网络和 HTTP 缓存头的恰当使用可以让你的网站惊人的快速。在这篇文章中,你将学习到这些技术,它能够使你的ASP.NET应用程序获得更高的性能、更好的扩展性 ,并且可以在任何 ASP.NET 的网站上实现,尤其是那些应用了 ASP.NET 2.0 Membership 和 Profile provider 的站点。

ASP.NET管道优化

  位于请求管道中的很多 ASP.NET 默认的 HttpModules 用于拦截客户端所发出的每个请求。例如,SessionStateModule 拦截每个请求,并解析对应的会话 cookie,然后在 HttpContext 中加载适当的会话。实时证明,并不是所有的 modules 都是必要的。

  例如,如果你不使用 Membership 和 Profile provider 提供程序,那么你就可以不需要 FormsAuthentication module。如果你需要为你的用户使用 Windows 验证,那么你就可以不需要 WindowsAuthentication。位于管道中的这些 modules 仅仅在每次请求到来时执行一些不必要的代码。

  默认的 modules 都定义在了 machine.config 文件中(位于 $WINDOWS$\Microsoft.NET\Framework\$VERSION$\CONFIG 目录下)。

默认 Modules

  你可以通过在站点的 web.config 文件中添加 <remove> 节点到你的网站应用程序中来删除这些默认的 modules。例如:

删除默认 Modules

  上面的配置对于使用了数据库并基于 Forms 验证的网站来说非常适合,它们并不需要任何会话的支持。因此,所有这些 modules 都可以安全的删除。

ASP.NET 进程配置优化

  ASP.NET 进程模型配置定义了一些进程级别的属性,像 ASP.NET 使用的线程数量、超时前阻止线程花费了多长时间、多少请求在继续等待 I/O 工作完成等等。默认情况下,很多方面都具有太多的限制。当今,硬件已经变得十分便宜了,即使是采用双核多 GB 的 RAM 服务器也变得非常平常的选择了。

  因此,进程模型配置能够减少 ASP.NET 进程消耗更多的系统资源并提供为每台服务器提供更好的扩展性。

  执行一次规则的 ASP.NET 安装将会在 machine.config 文件中创建如下配置的节点:

添加 ProcessModel

  你需要减少这种自动配置并针对不同的特性使用一些特定的值以便自定义ASP.NET工作者进程的工作方式。例如:

ProcessModel 配置详情
 

  除了下面几个不为默认值以外,其余均为系统默认值:

  maxWorkerThreads

  每次处理默认为 20,在一台双核的计算机上,ASP.NET 的处理就需要 40 了。这意味着 ASP.NET 在一台并行的双核服务器上可以每次处理 40 个请求。我将数量增加到 100 以便为 ASP.NET 的每次处理提供更多的线程。如果你有一个应用程序,它的 CPU 处理能力并不是很强但是它却能够每秒更容易地处理多个请求,那么你就可以增加这个值。

  尤其是你的 Web 应用程序使用了大量的 Web 服务调用或者下载/上传了很多不会对 CPU 产生压力的数据时。当 ASP.NET 用完这些工作者线程时,它会停止出来发来的多个请求。此时请求会放置到一个队列中并持续等待直到出现一个空闲的工作者线程。通常到你的站点开始接受超过预期的点击时会发生这样的情况。那样的话,如果你需要节省 CPU 的使用,可以增加每次处理的工作者线程数来达到目的。

  maxIOThreads

  每次处理默认为 20,在一台双核的计算机上,ASP.NET 进行的 I/O 操作就需要 40 个线程了。这意味着 ASP.NET 在一台并行的双核服务器上可以每次处理 40 个 I/O 请求。I/O 请求能够进行的文件读/写、数据库操作、web 服务调用、从 Web 应用程序中产生的 HTTP 请求等等。因此,如果你的服务器有足够的系统资源来处理更多的 I/O 请求,你可以将该值设置为 100。特别是当你的 Web 应用程序在并行模式下进行下载/上传数据、调用很多外部 Web 服务时,非常有用。

  minWorkerThreads

  当空闲的 ASP.NET 工作者线程数量低于这个数字时,ASP.NET 就会开始将这些发来的请求推入队列中。因此,你可以为改值设定一个较低的值以便可以增加当前请求的数量。此外,建议不要将该值设置得过低,因为 Web 应用程序的代码可能需要做一些后台处理和并行处理,此时会需要更多的空闲工作者线程支持。

  minIOThreads

  除了它是针对 I/O 线程以外,其它与 minWorkerThreads 的方式相同。然而你可以将该值设置得比 minWorkerThreads 还低。因为就 I/O 线程而言,这里不会发生并行处理的问题。

  memoryLimit

  指定内存大小所允许的最大值,作为整个系统内存的百分比,以便 ASP.NET 在启动一个新的进程并重新分派存在的请求之前这些工作者进程能够进行消费。如果在你的服务器上仅仅只运行了你的网站应用程序,而且没有其它的进程需要 RAM,你可以设置一个更高的值,比如 80。

  然而,如果你同时有一个会发生内存泄漏的应用程序,那么最好是把该值设置为一个较低的值以便在出现大问题之前泄漏的内存能得到及时的回收从而保持你的站点稳定。尤其是当你使用 COM 组件并发生内存泄漏时。然而,这只是针对该问题的一个临时解决方案;当然需要你去解决泄漏问题。

  除了 processModel 以外,另外还有一个非常重要的节点 system.net,你能够指定发出请求作为单独 IP 的最大数量。

connectionManagement

  默认值为 2,设置得比较低。这就意味着你不能从你的 Web 应用程序用一个 IP 地址同时链接多于 2 个的链接。站点获得外部内容很多都是由于默认设置而遭到阻塞。这里我将其设置为 100。如果你的 Web 应用程序会对某一个指定的服务器进行大量的调用,你甚至可以考虑设置一个更高的值。

原文地址:https://www.cnblogs.com/jacksonwj/p/1413882.html