数据层性能

　　技巧1—返回多个结果集

　　技巧2—分页的数据访问

　　技巧3—连接池

　　技巧4—ASP.NET缓存API

　　技巧5—每请求缓存

　　技巧6—后台处理

　　技巧7—页输出缓存和代理服务器

　　技巧8—运行IIS6.0(只要用于内核缓存)

　　技巧9—使用Gzip压缩

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

　　小结

　　使用ASP.NET编写Web应用程序的简单程度令人不敢相信。正因为如此简单，所以很多开发人员就不会花时间来设计其应用程序的结构，以获得更好的性能了。在本文中，我将讲述10个用于编写高性能Web应用程序的技巧。但是我并不会将这些建议仅局限于ASP.NET应用程序，因为这些应用程序只是Web应用程序的一部分。本文不作为对Web应用程序进行性能调整的权威性指南—一整本书恐怕都无法轻松讲清楚这个问题。请将本文视作一个很好的起点。

　　成为工作狂之前，我原来喜欢攀岩。在进行任何大型攀岩活动之前，我都会首先仔细查看指南中的路线，阅读以前游客提出的建议。但是，无论指南怎么好，您都需要真正的攀岩体验，然后才能尝试一个特别具有挑战性的攀登。与之相似，当您面临修复性能问题或者运行一个高吞吐量站点的问题时，您只能学习如何编写高性能Web应用程序。

　　我的个人体验来自在Microsoft的ASP.NET部门作为基础架构程序经理的经验，在此期间我运行和管理www.ASP.NET，帮助设计社区服务器的结构，社区服务器是几个著名ASP.NET应用程序(组合到一个平台的ASP.NETForums、.Text和nGallery)。我确信有些曾经帮助过我的技巧对您肯定也会有所帮助。

　　您应该考虑将应用程序分为几个逻辑层。您可能听说过3层(或者n层)物理体系结构一词。这些通常都是规定好的体系结构方式，将功能在进程和/或硬件之间进行了物理分离。当系统需要扩大时，可以很轻松地添加更多的硬件。但是会出现一个与进程和机器跳跃相关的性能下降，因此应该避免。所以，如果可能的话，请尽量在同一个应用程序中一起运行ASP.NET页及其相关组件。

　　因为代码分离以及层之间的边界，所以使用Web服务或远程处理将会使得性能下降20%甚至更多。

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

　　在深入应用程序的性能修复问题之前，请首先确保对应用程序进行剖析，以便找出具体的问题所在。主要性能计数器(如表示执行垃圾回收所需时间百分比的计数器)对于找出应用程序在哪些位置花费了其主要时间也非常有用。然而花费时间的位置通常非常不直观。

　　本文讲述了两种类型的性能改善:大型优化(如使用ASP.NET缓存)，和进行自身重复的小型优化。这些小型优化有时特别有意思。您对代码进行一点小小的更改，就会获得很多很多时间。使用大型优化，您可能会看到整体性能的较大飞跃。而使用小型优化时，对于某个特定请求可能只会节省几毫秒的时间，但是每天所有请求加起来，则可能会产生巨大的改善。

　　数据层性能

　　谈到应用程序的性能调整，有一个试纸性的测试可用来对工作进行优先级划分:代码是否访问数据库?如果是，频率是怎样的?请注意，这一相同测试也可应用于使用Web服务或远程处理的代码，但是本文对这些内容未做讲述。

　　如果某个特定的代码路径中必需进行数据库请求，并且您认为要首先优化其他领域(如字符串操作)，则请停止，然后执行这个试纸性测试。如果您的性能问题不是非常严重的话，最好花一些时间来优化一下与数据库、返回的数据量、进出数据库的往返频率相关的花费时间。

　　了解这些常规信息之后，我们来看一下可能会有助于提高应用程序性能的十个技巧。首先，我要讲述可能会引起最大改观的更改。

　　技巧1—返回多个结果集

　　仔细查看您的数据库代码，看是否存在多次进入数据库的请求路径。每个这样的往返都会降低应用程序可以提供的每秒请求数量。通过在一个数据库请求中返回多个结果集，可以节省与数据库进行通信所需的总时间长度。同时因为减少了数据库服务器管理请求的工作，还会使得系统伸缩性更强。

　　虽然可以使用动态SQL返回多个结果集，但是我首选使用存储过程。关于业务逻辑是否应该驻留于存储过程的问题还存在一些争议，但是我认为，如果存储过程中的逻辑可以约束返回数据的话(缩小数据集的大小、缩短网络上所花费时间，不必筛选逻辑层的数据)，则应赞成这样做。

　　使用SqlCommand实例及其ExecuteReader方法填充强类型的业务类时，可以通过调用NextResult将结果集指针向前移动。图1显示了使用类型类填充几个ArrayList的示例会话。只从数据库返回您需要的数据将进一步减少服务器上的内存分配。

　　技巧2—分页的数据访问

　　ASP.NETDataGrid具有一个很好的功能:数据分页支持。在DataGrid中启用分页时，一次会显示固定数量的记录。另外，在DataGrid的底部还会显示分页UI，以便在记录之间进行导航。该分页UI使您能够在所显示的数据之间向前和向后导航，并且一次显示固定数量的记录。

　　还有一个小小的波折。使用DataGrid的分页需要所有数据均与网格进行绑定。例如，您的数据层需要返回所有数据，那么DataGrid就会基于当前页筛选显示的所有记录。如果通过DataGrid进行分页时返回了100,000个记录，那么针对每个请求会放弃99,975个记录(假设每页大小为25个记录)。当记录的数量不断增加时，应用程序的性能就会受到影响，因为针对每个请求必须发送越来越多的数据。

　　要编写性能更好的分页代码，一个极佳的方式是使用存储过程。图2显示了针对Northwind数据库中的Orders表进行分页的一个示例存储过程。简而言之，您此时要做的只是传递页索引和页大小。然后就会计算合适的结果集，并将其返回。

　　在社区服务器中，我们编写了一个分页服务器控件，以完成所有的数据分页。您将会看到，我使用的就是技巧1中讨论的理念，从一个存储过程返回两个结果集:记录的总数和请求的数据。

　　返回记录的总数可能会根据所执行查询的不同而有所变化。例如，WHERE子句可用来约束返回的数据。为了计算在分页UI中显示的总页数，必须了解要返回记录的总数。例如，如果总共有1,000,000条记录，并且要使用一个WHERE子句将其筛选为1000条记录，那么分页逻辑就需要了解记录的总数才能正确呈现分页UI。

　　技巧3—连接池

　　在Web应用程序和SQLServer™之间设置TCP连接可能是一个非常消耗资源的操作。Microsoft的开发人员到目前为止能够使用连接池已经有一段时间了，这使得他们能够重用数据库连接。他们不是针对每个请求都设置一个新的TCP连接，而是只在连接池中没有任何连接时才设置新连接。当连接关闭时，它会返回连接池，在其中它会保持与数据库的连接，而不是完全破坏该TCP连接。

　　当然，您需要小心是否会出现泄漏连接。当您完成使用连接时，请一定要关闭这些连接。再重复一遍:无论任何人对Microsoft.NETFramework中的垃圾回收有什么评论，请一定要在完成使用连接时针对该连接显式调用Close或Dispose。不要相信公共语言运行库(CLR)会在预先确定的时间为您清除和关闭连接。尽管CLR最终会破坏该类，并强制连接关闭，但是当针对对象的垃圾回收真正发生时，并不能保证。

　　要以最优化的方式使用连接池，需要遵守一些规则。

　　首先打开连接，执行操作，然后关闭该连接。如果您必须如此的话，可以针对每个请求多次打开和关闭连接(最好应用技巧1)，但是不要一直将连接保持打开状态并使用各种不同的方法对其进行进出传递。

　　第二，使用相同的连接字符串(如果使用集成身份验证的话，还要使用相同的线程标识)。如果不使用相同的连接字符串，例如根据登录的用户自定义连接字符串，那么您将无法得到连接池提供的同一个优化值。如果您使用集成身份验证，同时还要模拟大量用户，连接池的效率也会大大下降。尝试跟踪与连接池相关的任何性能问题时，.NETCLR数据性能计数器可能非常有用。

　　每当应用程序连接资源时，如在另一个进程中运行的数据库，您都应该重点考虑连接该资源所花时间、发送或检索数据所花时间，以及往返的数量，从而进行优化。优化应用程序中任何种类的进程跳跃都是获得更佳性能的首要一点。

　　应用层包含了连接数据层、将数据转换为有意义类实例和业务流程的逻辑。例如社区服务器，您要在其中填充Forums或Threads集合，应用业务规则(如权限);最重要的是要在其中执行缓存逻辑。

　　技巧4—ASP.NET缓存API

　　编写应用程序代码行之前，一个首要完成的操作是设计应用层的结构，以便最大化利用ASP.NET缓存功能。

　　如果您的组件要在ASP.NET应用程序中运行，则只需在该应用程序项目中包括一个System.Web.dll引用。当您需要访问该缓存时，请使用HttpRuntime.Cache属性(通过Page.Cache和HttpContext.Cache也可访问这个对象)。