编写高性能Web应用程序的10个技巧

 

·一般ASP.NET性能的秘密

·能提高ASP.NET表现的有用的技巧和窍门

·在ASP.NET中使用数据库的建议

·ASP.NET中的缓存和后台处理

 

       使用ASP.NET编写一个Web应用程序是难以置信的简单的。太简单了，以至于很多开发者都不花费时间来构建他们的应用程序来达到很好的表现。在这篇文章里，我将为编写高性能的Web应用程序推荐10个技巧。我不会讲我的论述局限于ASP.NET应用程序，因为ASP.NET应用程序只是Web应用程序的一个子集而已。这篇文章不会是针对优化Web应用程序的性能的权威性指导——一本完整的书可以很容易的做到这一点。相反，我们应该把这篇文章当成一个好的起点。

 

       在成为一个工作狂以前，我会经常去攀岩。在做任何攀岩活动之前，我更愿意看看旅行指南里面的路线，再读读那些曾经到过峰顶的人做的推荐。但是，不管旅行指南写的有多好，在尝试一个有挑战性的目标之前，您都需要有实际的攀岩经验。与之相似，当您面临修复性能问题或者运行一个高吞吐量站点的问题时，您只能学习如何编写高性能 Web 应用程序。

 

 

       我的个人经验来自在微软的ASP.NET团队中担任过一名基础程序经理的经历，维护和管理www.asp.net，还有帮助构架Community Server，它是几个著名的ASP.NET应用程序（ASP.NET Forums，.Text，和连接到一个平台的nGallery）的下一个版本。我相信这些曾经帮助过我技巧中的一些也会对您有用的。

      

       您应该考虑把您的应用程序分离为几个逻辑层次。您可能已经听说过3层（或者n层）体系结构。这些通常都是规定的结构模式，它们将业务和（或）硬件从物理上进行了功能划分。如果系统需要更大的规模，更多的硬件可以轻松的加进来。然而，那会产生一个与业务和机器跳跃相关联的性能下降，因此我们应该避免它。所以只要可能，尽量在同一个应用程序中运行ASP.NET页面和页面的相关组件。

 

       因为代码的分离和层次之间的边界，使用Web服务或者远程处理会降低性能20%甚至更多。

 

       数据层有点与众不同，因为通常情况下，最好具有专用于数据库的硬件。然而，然而进程跳跃到数据库的成本依然很高，因此在数据层的性能是您优化代码时应该首先考虑的。

 

       在投入到修复您的应用程序的性能问题之前，确保您要先分析您的应用程序来发现问题的根源所在。关键性能计数器（例如那个指示在执行垃圾收集过程中花费的时间百分比的计数器）在找出应用程序在哪里花费了主要的时间时也是非常有用的。虽然那些花费时间的地方经常是不那么直观的。

 

       在这篇文章中我讨论了两种改进性能的方法：大块的优化，例如使用ASP.NET缓存，还有小块的优化，它们经常重复出现。这些小块的优化有时是最有意思的。您对代码的一个小的修改会被调用成千上万次。对大块的优化，您可能会发现整个的性能有了一个大的飞跃。对小块的优化，您可能会缩减了对一个给定请求的几微秒的时间，但是如果把每天的所有的请求累积起来，性能就会得到一个意想不到的改进。

 

数据层中的性能

 

       当您要开始优化一个应用程序的性能的时候，有一个决定性的测试您可以优先考虑使用：代码是否要访问数据库？如果是，多长时间访问一次？注意这个测试也可以应用到那些使用Web服务或者远程控制的代码中，但是我不会在这篇文章中涉及那些内容。

 

       如果在您的代码中的某个代码路径中要求一个数据库请求，而您发现其他地方您想要优先优化，例如字符串操作，那么停下来然后先执行关键性的测试。除非您有一个性能实在糟糕的问题要处理，否则您的时间会得到更好的利用，如果您把时间花在优化数据库连接的时间，返回的数据量，还有您作的往返数据库的操作中。

 

       现在我已经总体介绍了相关的信息，下面让我们看看10条帮您的应用程序表现更好的技巧。我会从那些对改善性能效果最明显的地方开始说。

 

技巧 1——返回多个结果集

 

       查看一下您的数据库代码，看看您是否有访问数据库多于一次的请求路径（request paths）。每个这样的往返都回降低您的应用程序每秒可以服务的请求的数量。通过在一次数据库请求中返回多个结果集，您可以减少数据库通信消耗的总时间。在您减少了数据库服务器管理的请求之后，您也会使您的系统更具可升级性。

 

       一般您可以使用动态SQL语句来返回多个结果集，我更喜欢用存储过程。是否应该把业务逻辑放在存储过程中是存在争议的，但我认为如果一个存储过程中的逻辑可以限制返回的数据（减少数据集的大小，花在网络连接上的时间，并且不需要过滤逻辑层的数据），那它就是好东西。

 

       使用一个SqlCommand实例和它的ExecuteReader方法来生成强类型的业务类，您可以通过调用NextResult让结果集指针向前移动。图1展示了一个使用定义的类生成几个ArrayList的示例会话。只从数据库返回您需要的数据会显著地减少您服务器上的内存申请。

 

 1// read the first resultset
 2reader = command.ExecuteReader();
 3
 4// read the data from that resultset
 5while (reader.Read()) {
 6    suppliers.Add(PopulateSupplierFromIDataReader( reader ));
 7}
 8
 9// read the next resultset
10reader.NextResult();
11
12// read the data from that second resultset
13while (reader.Read()) {
14    products.Add(PopulateProductFromIDataReader( reader ));
15}
16
17

 

技巧 2——分页数据访问

 

       ASP.NET的DataGrid提供了一个非常棒的能力：对数据分页的支持。当在DataGrid中设置了分页，那么将一次显示一个特定数目的结果。此外，用来在结果之间导航的分页UI也会在DataGrid的底部显示出来。分页UI允许您在显示的数据之间向前导航或者向后导航，每页显示特定数目的结果。

      

       但是有一个小问题。使用DataGrid分页时需要所有的数据都绑定到表格。例如，您的数据层会需要返回所有数据，然后DataGrid要根据当前页填充所有要显示的记录。如果当您在使用DataGrid分页时返回了100，000条记录，每次请求都会丢弃99，975条记录（假设每页的容量是25条记录）。当记录的数量不断增长时，应用程序的性能会受到很大的影响，因为每次请求都必须返回越来越多的数据。

 

       一个写出更好的分页代码的办法是使用存储过程。图2显示了一个示例存储过程，它为Nothwind数据库中的Orders数据表分页。总的来说，在这里所有您需要做的就是传入页的索引和页的容量。数据库会计算出适当的结果集然后返回它们。

 

 1CREATE PROCEDURE northwind_OrdersPaged
 2(
 3    @PageIndex int, 
 4    @PageSize int
 5)
 6AS
 7BEGIN
 8DECLARE @PageLowerBound int
 9DECLARE @PageUpperBound int
10DECLARE @RowsToReturn int
11
12-- First set the rowcount
13SET @RowsToReturn = @PageSize * (@PageIndex + 1)
14SET ROWCOUNT @RowsToReturn
15
16-- Set the page bounds
17SET @PageLowerBound = @PageSize * @PageIndex
18SET @PageUpperBound = @PageLowerBound + @PageSize + 1
19
20-- Create a temp table to store the select results
21CREATE TABLE #PageIndex 
22(
23    IndexId int IDENTITY (1, 1) NOT NULL,
24    OrderID int
25)
26
27-- Insert into the temp table
28INSERT INTO #PageIndex (OrderID)
29SELECT 
30    OrderID
31FROM 
32    Orders
33ORDER BY 
34    OrderID DESC
35
36-- Return total count
37SELECT COUNT(OrderID) FROM Orders
38
39-- Return paged results
40SELECT 
41    O.*
42FROM 
43    Orders O,
44    #PageIndex PageIndex
45WHERE 
46    O.OrderID = PageIndex.OrderID AND
47    PageIndex.IndexID > @PageLowerBound AND
48    PageIndex.IndexID < @PageUpperBound
49ORDER BY 
50    PageIndex.IndexID
51
52END
53
54

 

       在社区服务期中，我们写了一个分页服务端控件来做这些数据分页。您会发现我在使用技巧1中讨论过的思想，从一个存储过程返回两个结果集：纪录总数和请求的数据。

 

       返回的记录总数可以根据执行的请求而有所不同。例如，一个WHERE分句可以用来约束返回的数据。我们必须知道要返回的记录总数，以计算要在分页UI中显示的总的页数。例如，如果有1，000，000条总的记录数，而一个WHERE分句用来把这些记录过滤为1，000条记录，分页逻辑需要知道总的记录数来恰当的提交分页UI。

 

技巧 3——连接池

 

       在您的Web应用程序和SQL Server之间建立TCP连接会是一个昂贵的操作。Microsoft的开发者们已经利用连接池有一段时间了，这允许他们重用与数据库的连接。与其为每个请求建立一个新的TCP连接，还不如只有在连接池中没有一个可用的连接的时候才建立一个新的连接。当连接关闭后，它返回到连接池中——它还保持着与数据库的连接，而不是完全销毁那个TCP连接。

      

       当然您需要小心泄露的连接。总是关闭您的连接在您使用完它们时。我重复一遍：不管谁说了关于Microsoft .NET框架的垃圾回收机制的什么话，当您使用完时，您务必总是对您的连接显式调用Close或者Dispose方法。不要相信通用语言运行时（CLR）会在一个预定的时间为您清理和关闭您的连接。CLR会最终销毁类并且强迫连接关闭，但您不能保证什么时候在对象上的垃圾回收机制会真正执行。

 

       要想使用连接池达到最佳效果，您需要遵循几条规则。第一，打开一个连接，完成工作，然后关闭连接。如果您不得不（最好应用技巧1）为每个请求打开和关闭几次连接也是可以的，这比一直开着连接然后把它传递给几个不同的方法要好得多。第二，使用同一个连接字符串（如果您在使用集成身份认证，当然还需要有相同的线程标识）。如果您不使用同一个连接字符串，例如基于登录的用户的不同自定义连接字符串，您就不能得到连接池提供的相同的最优值。而且如果您在模仿大量的用户时使用了集成身份验证，您的连接池的效率也会降低很多。在尝试跟踪任何与连接池有关的性能问题时，.NET CLR数据性能计数器会很有用的。

 

       不论何时您的应用程序连接一个资源，例如一个数据库，或者在另一个进程中运行，您都应该通过把注意力集中到连接到资源所花费的时间上，发送和接受数据花费的时间，还有往返与数据库的次数来进行优化。优化您的应用程序中的任何类型的进程跳转（process hop）都是开始达到更好性能的第一步。

 

       应用层包含连接到您的数据层的逻辑，并且把数据转换为有意义的类实例和逻辑过程。例如，在社区服务器中，这里是您生成一个论坛或者线程集合，并且应用业务规则例如许可的地方；更重要的是这里是执行缓冲逻辑的地方。

 

技巧 4——ASP.NET缓冲API

      

       在您开始编写应用程序的第一行代码之前要考虑的第一件事情是，架构应用层来最大化并且利用ASP.NET的缓存特性。

 

       如果您的组件运行在一个ASP.NET应用程序之中，您只需要在您的应用程序项目中简单的引用System.Web.dll就可以了。当您需要访问缓存时，使用HttpRuntime.Cache属性（这个对象也可以通过Page.Cache和HttpContext.Cache来访问）。

 

       使用缓存数据有几条原则。第一，如果数据可以多次使用，那么缓存它就是一个好的选择。第二，如果数据是通用的而不是给特定的请求或者用户使用的，那么缓存它就是一个非常好的选择。如果数据是用户或者请求特定的，但是他的生存期是很长的，那么它也可以被缓存，但是可能不会经常使用到。第三，一个经常被忽视的原则是，有时候您可以缓存的太多了。通常在一台x86计算机上，为了减少发生内存不足（out-of-memory）错误的可能性，您会希望运行一个使用不超过800MB私有字节的进程。因此，缓存应该受到限制。换句话说，您可能需要重新使用一次计算的结果，但是如果那个计算需要十个参数，您可能需要尝试缓存10个排列，而这可能会给您带来麻烦。由于过度缓存引起的内存不足错误是ASP.NET中最常见的，特别是对于大数据集的情况。

      

       缓存有几个极佳的功能，您需要对它们有所了解。首先，缓存会实现最近最少使用的算法，使得 ASP.NET 能够在内存运行效率较低的情况下强制缓存清除——从缓存自动删除未使用过的项目。第二，缓存支持可以强制失效的过期依赖项。这些依赖项包括时间、键和文件。时间经常会用到，但是对于 ASP.NET 2.0，引入了一个功能更强的新失效类型：数据库缓存失效。它指的是当数据库中的数据发生变化时自动删除缓存中的项。有关数据库缓存失效的详细信息，请参阅 MSDN Magazine 2004 年 7 月的 Dino Esposito Cutting Edge 专栏。要了解缓存的体系结构，请参阅图 3。

 

技巧 5 — 每请求缓存

 

 

       在本文前面部分，我提到了对经常遍历代码路径的一些小改善可以获得较大的整体性能收益。对于这些小改善，其中有一个绝对是我的最爱，我将其称之为“每请求缓存”。

 

       缓存 API 的设计目的是为了将数据缓存较长的一段时间，或者缓存至满足某些条件时，但每请求缓存则意味着只将数据缓存为该请求的持续时间。对于每个请求，要经常访问某个特定的代码路径，但是数据却只需提取、应用、修改或更新一次。这听起来有些理论化，那么我们来举一个具体的示例。

 

       在社区服务器的论坛应用程序中，页面上使用的每个服务器控件都需要个性化的数据来确定使用什么外观、使用什么样式表，以及其他个性化数据。这些数据中有些可以长期缓存，但是有些数据却只针对每个请求提取一次，然后在执行该请求期间对其重用多次，如要用于控件的外观。

 

       为了达到每请求缓存，请使用 ASP.NET HttpContext。对于每个请求，都会创建一个 HttpContext 实例，在该请求期间从 HttpContext.Current 属性的任何位置都可访问该实例。该 HttpContext 类具有一个特殊的 Items 集合属性；添加到此 Items 集合的对象和数据只在该请求持续期间内进行缓存。正如您可以使用缓存来存储经常访问的数据一样，您也可以使用 HttpContext.Items 来存储只基于每个请求使用的数据。它背后的逻辑非常简单：数据在它不存在的时候添加到 HttpContext.Items 集合，在后来的查找中，只是返回 HttpContext.Items 中的数据。

 

技巧 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），您的服务器每秒可以服务于更多的请求。实际上，几乎每当您减少所返回数据的数量时，都会增加每秒请求数。

 

       Gzip 压缩已经内置到 IIS 6.0 中，并且其性能比 IIS 5.0 中使用的 gzip 压缩要好的多，这是好消息。但不幸的是，当尝试在 IIS 6.0 中打开 gzip 压缩时，您可能无法在 IIS 的属性对话中找到该设置。IIS 小组在该服务器中置入了卓越的 gzip 功能，但是忘了包括一个用于启用该功能的管理 UI。要启用 gzip 压缩，您必须深入到 IIS 6.0 的 XML 配置设置内部（这样不会引起心脏虚弱）。顺便提一句，这归功于 OrcsWeb 的 Scott Forsyth，他帮助我提出了在 OrcsWeb 上宿主的 www.asp.net 服务器的这个问题。

 

       本文就不讲述步骤了，请阅读 Brad Wilson 的文章，网址是 IIS6 Compression。还有一篇有关为 ASPX 启用压缩的知识库文章，网址是 Enable ASPX Compression in IIS。但是您应该注意，由于一些实施细节，IIS 6.0 中不能同时存在动态压缩和内核缓存。

 

技巧 10 — 服务器控件视图状态

 

 

       视图状态是一个有趣的名称，用于表示在所生成页的隐藏输出字段中存储一些状态数据的 ASP.NET。当该页发回服务器时，服务器可以分析、验证、并将此视图状态数据应用回该页的控件树。视图状态是一个非常强大的功能，因为它允许状态与客户端一起保持，并且它不需要 cookie 或服务器内存即可保存此状态。很多 ASP.NET 服务器控件都使用视图状态来保持在与页元素进行交互期间创建的设置，例如保存对数据进行分页时显示的当前页。

 

       然而使用视图状态也有一些缺点。首先，当页被服务或被请求时，它都会增加页的总负载。对发回服务器的视图状态数据进行序列化或取消序列化时，也会发生额外的开销。最后，视图状态会增加服务器上的内存分配。

 

       几个服务器控件有过度使用视图状态的趋势，即使在并不需要的情况下也要使用它，其中最著名的是 DataGrid。ViewState 属性的默认行为是启用，但是如果您不需要，则可以在控件或页级别关闭。在控件内，只需将 EnableViewState 属性设置为 false，或者在页中使用下列设置即可对其进行全局设置：

 

  

<%@ Page EnableViewState="false" %>

 

 

       如果您不发回页，或者总是针对每个请求重新生成页上的控件，则应该在页级别禁用视图状态。

 

小结

 

 

       我为您讲述了一些我认为在编写高性能 ASP.NET 应用程序时有所帮助的技巧。正如我在本文前面部分提到的那样，这是一个初步指南，并不是 ASP.NET 性能的最后定论。（有关改善 ASP.NET 应用程序性能的信息，请参阅 Improving ASP.NET Performance。）只有通过自己的亲身体验才能找出解决具体性能问题的最好方法。但是，在您的旅程中，这些技巧应该会为您提供一些好的指南。在软件开发中，几乎没有绝对的东西；每个应用程序都是唯一的。