减小字体
增大字体- ·上一篇文章：VS2005和ASP.NET2.0中使用强类型数据
- ·下一篇文章：编写高性能Web应用程序的10个技巧(2)
编写高性能Web应用程序的10个技巧(3)
技巧 6 — 后台处理
通往代码的路径应该尽可能快速，是吗？可能有时您会发现您正在执行的针对每个请求执行的或者每 n 个请求执行一次的任务所需资源非常多。发送电子邮件或者分析和验证传入数据就是这样的一些例子。
剖析 ASP.NET Forums 1.0 并重新构建组成社区服务器的内容时，我们发现发布新帖子的代码路径非常慢。每次发布新帖子的时候，应用程序首先需要确保没有重复的帖子，然后必须使用“坏词”筛选器分析该帖子，分析帖子的字符图释，对帖子添加标记并进行索引，请求时将帖子添加到合适的队列，验证附件，最终在帖子发布之后，立即向所有订阅者发出电子邮件通知。很清楚，这涉及很多操作。
经研究发现，大多数时间都花在了索引逻辑和发送电子邮件上。对帖子进行索引是一个非常耗时的操作，人们发现内置的 System.Web.Mail 功能要连接 SMTP 服务器，然后连续发送电子邮件。当某个特定帖子或主题领域的订阅者数量增加时，执行 AddPost 功能所需的时间也越来越长。
并不需要针对每个请求都进行电子邮件索引。理想情况下，我们想要将此操作进行批处理，一次索引 25 个帖子或者每五分钟发送一次所有电子邮件。我们决定使用我曾经用于对数据缓存失效进行原型设计的代码，这个失效是最终被包含进了Visual Studio 2005之中。
System.Threading 命名空间中的 Timer 类非常有用，但是在 .NET Framework 中不是很有名，至少对于 Web 开发人员来说是这样。创建之后，这个 Timer 类将以一个可配置的间隔针对 ThreadPool 中的某个线程调用指定的回调。这就表示，您可以对代码进行设置，使其能够在没有对 ASP.NET 应用程序进行传入请求的情况下得以执行，这是后台处理的理想情况。您还可以在此后台进程中执行如索引或发送电子邮件之类的操作。
但是，这一技术有几个问题。如果应用程序域卸载，该计时器实例将停止激发事件。另外，因为 CLR 对于每个进程的线程数量具有一个硬性标准，所以在负载很重的服务器可能会出现这样的情形：其中的计时器可能不能保证线程继续完成操作，并且在某种程度上可能会造成延迟。ASP.NET 通过在进程中保留一定数量的可用线程，并且仅使用总线程的一部分用于请求处理，试图将上述情况发生的机会降到最低。但是，如果您具有很多异步操作时，这可能就是一个问题了。
这里没有足够的空间来放置该代码，但是您可以下载一个容易理解的示例，网址是www.rob-howard.net。请了解一下 Blackbelt TechEd 2004 演示中的幻灯片和演示。
技巧 7 — 页输出缓存和代理服务器
ASP.NET 是您的表示层（或者说应该是您的表示层）；它由页、用户控件、服务器控件（HttpHandlers 和 HttpModules）以及它们生成的内容组成。如果您具有一个 ASP.NET 页，它会生成输出（HTML、XML、图像或任何其他数据），并且您针对每个请求运行此代码时，它都会生成相同的输出，那么您就拥有一个可用于页输出缓存的绝佳备选内容。
通过将下面这行内容添加页的最上端：
<%@ Page OutputCache VaryByParams="none" Duration="60" %>
您就可以高效地为此页生成一次输出，然后对它进行多次重用，时间最长为 60 秒，此时该页将重新执行，输出也将再一次添加到 ASP.NET 缓存。通过使用一些低级别可编程API 也可以完成此行为。对于输出缓存有几个可配置的设置，如刚刚讲到的 VaryByParams 属性。VaryByParams 刚好被请求到，但还允许您指定 HTTP GET 或 HTTP POST 参数来更改缓存项。例如，只需设置 VaryByParam="Report" 即可对 default.aspx?Report=1 或 default.aspx?Report=2 进行输出缓存。通过指定一个以分号分隔的列表，还可以指定其他参数。
很多人还没有意识到当使用了输出缓存之后，ASP.NET 页也会生成一些向下流到缓存服务器的 HTTP 标题头，如 Microsoft Internet Security 和 Acceleration Server 或 Akamai 使用的标题头。设置了 HTTP 缓存表题头之后，可以在这些网络资源上对文档进行缓存，客户端请求也可在不必返回原始服务器的情况下得以满足。
因此，使用页输出缓存不会使得您的应用程序效率更高，但是它可能会减少服务器上的负载，因为下行流缓存技术会缓存文档。当然，这只能是匿名内容；一旦它成为下行流之后，您就再也不会看到这些请求，并且再也无法执行身份验证以阻止对它的访问了。
技巧 8 — 运行 IIS 6.0（哪怕只为了使用内核缓存也好）
如果您未运行 IIS 6.0 (Windows Server 2003)，那么您就错过了 Microsoft Web 服务器中的一些很好的性能增强。在技巧 7 中，我讨论了输出缓存。在 IIS 5.0 中，请求是通过 IIS 然后进入 ASP.NET 的。涉及到缓存时，ASP.NET 中的 HttpModule 会接收该请求，并返回缓存中的内容。
如果您正在使用 IIS 6.0，就会发现一个很好的小功能，称为内核缓存，它不需要对 ASP.NET 进行任何代码更改。当请求由 ASP.NET 进行输出缓存时，IIS 内核缓存会接收缓存数据的一个副本。当请求来自网络驱动程序时，内核级别的驱动程序（无上下文切换到用户模式）就会接收该请求，如果经过了缓存，则会将缓存的数据刷新到响应，然后完成执行。这就表示，当您将内核模式缓存与 IIS 和 ASP.NET 输出缓存一起使用时，就会看到令人不敢相信的性能结果。在 ASP.NET 的 Visual Studio 2005 开发过程中，我一度是负责 ASP.NET 性能的开发经理。开发人员完成具体工作，但是我要看到每天进行的所有报告。内核模式缓存结果总是最有意思的。最常见的特征是网络充满了请求/响应，而 IIS 运行时的 CPU 使用率只有大约 5%。这太令人震惊了！当然使用 IIS 6.0 还有一些其他原因，但是内核模式缓存是其中最明显的一个。
技巧 9 — 使用 Gzip 压缩
虽然使用 gzip 并不一定是服务器性能技巧（因为您可能会看到 CPU 使用率的提高），但是使用 gzip 压缩可以减少服务器发送的字节数量。这就使人们觉得页速度加快了，并且还减少了带宽的用量。根据所发送数据、可以压缩的程度以及客户端浏览器是否支持（IIS 只会向支持 gzip 压缩的客户端发送经过 gzip 压缩的内容，如 Internet Explorer 6.0 和 Firefox），您的服务器每秒可以服务于更多的请求。实际上，几乎每当您
通往代码的路径应该尽可能快速，是吗？可能有时您会发现您正在执行的针对每个请求执行的或者每 n 个请求执行一次的任务所需资源非常多。发送电子邮件或者分析和验证传入数据就是这样的一些例子。
剖析 ASP.NET Forums 1.0 并重新构建组成社区服务器的内容时，我们发现发布新帖子的代码路径非常慢。每次发布新帖子的时候，应用程序首先需要确保没有重复的帖子，然后必须使用“坏词”筛选器分析该帖子，分析帖子的字符图释，对帖子添加标记并进行索引，请求时将帖子添加到合适的队列，验证附件，最终在帖子发布之后，立即向所有订阅者发出电子邮件通知。很清楚，这涉及很多操作。
经研究发现，大多数时间都花在了索引逻辑和发送电子邮件上。对帖子进行索引是一个非常耗时的操作，人们发现内置的 System.Web.Mail 功能要连接 SMTP 服务器，然后连续发送电子邮件。当某个特定帖子或主题领域的订阅者数量增加时，执行 AddPost 功能所需的时间也越来越长。
并不需要针对每个请求都进行电子邮件索引。理想情况下，我们想要将此操作进行批处理，一次索引 25 个帖子或者每五分钟发送一次所有电子邮件。我们决定使用我曾经用于对数据缓存失效进行原型设计的代码，这个失效是最终被包含进了Visual Studio 2005之中。
System.Threading 命名空间中的 Timer 类非常有用，但是在 .NET Framework 中不是很有名，至少对于 Web 开发人员来说是这样。创建之后，这个 Timer 类将以一个可配置的间隔针对 ThreadPool 中的某个线程调用指定的回调。这就表示，您可以对代码进行设置，使其能够在没有对 ASP.NET 应用程序进行传入请求的情况下得以执行，这是后台处理的理想情况。您还可以在此后台进程中执行如索引或发送电子邮件之类的操作。
但是，这一技术有几个问题。如果应用程序域卸载，该计时器实例将停止激发事件。另外，因为 CLR 对于每个进程的线程数量具有一个硬性标准，所以在负载很重的服务器可能会出现这样的情形：其中的计时器可能不能保证线程继续完成操作，并且在某种程度上可能会造成延迟。ASP.NET 通过在进程中保留一定数量的可用线程，并且仅使用总线程的一部分用于请求处理，试图将上述情况发生的机会降到最低。但是，如果您具有很多异步操作时，这可能就是一个问题了。
这里没有足够的空间来放置该代码，但是您可以下载一个容易理解的示例，网址是www.rob-howard.net。请了解一下 Blackbelt TechEd 2004 演示中的幻灯片和演示。
技巧 7 — 页输出缓存和代理服务器
ASP.NET 是您的表示层（或者说应该是您的表示层）；它由页、用户控件、服务器控件（HttpHandlers 和 HttpModules）以及它们生成的内容组成。如果您具有一个 ASP.NET 页，它会生成输出（HTML、XML、图像或任何其他数据），并且您针对每个请求运行此代码时，它都会生成相同的输出，那么您就拥有一个可用于页输出缓存的绝佳备选内容。
通过将下面这行内容添加页的最上端：
<%@ Page OutputCache VaryByParams="none" Duration="60" %>
您就可以高效地为此页生成一次输出，然后对它进行多次重用，时间最长为 60 秒，此时该页将重新执行，输出也将再一次添加到 ASP.NET 缓存。通过使用一些低级别可编程API 也可以完成此行为。对于输出缓存有几个可配置的设置，如刚刚讲到的 VaryByParams 属性。VaryByParams 刚好被请求到，但还允许您指定 HTTP GET 或 HTTP POST 参数来更改缓存项。例如，只需设置 VaryByParam="Report" 即可对 default.aspx?Report=1 或 default.aspx?Report=2 进行输出缓存。通过指定一个以分号分隔的列表，还可以指定其他参数。
很多人还没有意识到当使用了输出缓存之后，ASP.NET 页也会生成一些向下流到缓存服务器的 HTTP 标题头，如 Microsoft Internet Security 和 Acceleration Server 或 Akamai 使用的标题头。设置了 HTTP 缓存表题头之后，可以在这些网络资源上对文档进行缓存，客户端请求也可在不必返回原始服务器的情况下得以满足。
因此，使用页输出缓存不会使得您的应用程序效率更高，但是它可能会减少服务器上的负载，因为下行流缓存技术会缓存文档。当然，这只能是匿名内容；一旦它成为下行流之后，您就再也不会看到这些请求，并且再也无法执行身份验证以阻止对它的访问了。
技巧 8 — 运行 IIS 6.0（哪怕只为了使用内核缓存也好）
如果您未运行 IIS 6.0 (Windows Server 2003)，那么您就错过了 Microsoft Web 服务器中的一些很好的性能增强。在技巧 7 中，我讨论了输出缓存。在 IIS 5.0 中，请求是通过 IIS 然后进入 ASP.NET 的。涉及到缓存时，ASP.NET 中的 HttpModule 会接收该请求，并返回缓存中的内容。
如果您正在使用 IIS 6.0，就会发现一个很好的小功能，称为内核缓存，它不需要对 ASP.NET 进行任何代码更改。当请求由 ASP.NET 进行输出缓存时，IIS 内核缓存会接收缓存数据的一个副本。当请求来自网络驱动程序时，内核级别的驱动程序（无上下文切换到用户模式）就会接收该请求，如果经过了缓存，则会将缓存的数据刷新到响应，然后完成执行。这就表示，当您将内核模式缓存与 IIS 和 ASP.NET 输出缓存一起使用时，就会看到令人不敢相信的性能结果。在 ASP.NET 的 Visual Studio 2005 开发过程中，我一度是负责 ASP.NET 性能的开发经理。开发人员完成具体工作，但是我要看到每天进行的所有报告。内核模式缓存结果总是最有意思的。最常见的特征是网络充满了请求/响应，而 IIS 运行时的 CPU 使用率只有大约 5%。这太令人震惊了！当然使用 IIS 6.0 还有一些其他原因，但是内核模式缓存是其中最明显的一个。
技巧 9 — 使用 Gzip 压缩
虽然使用 gzip 并不一定是服务器性能技巧（因为您可能会看到 CPU 使用率的提高），但是使用 gzip 压缩可以减少服务器发送的字节数量。这就使人们觉得页速度加快了，并且还减少了带宽的用量。根据所发送数据、可以压缩的程度以及客户端浏览器是否支持（IIS 只会向支持 gzip 压缩的客户端发送经过 gzip 压缩的内容，如 Internet Explorer 6.0 和 Firefox），您的服务器每秒可以服务于更多的请求。实际上，几乎每当您