Web 应用程序性能优化

技巧 1 — 返回多个结果集

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

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

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

返回页首

技巧 2 — 分页的数据访问

ASP.NET DataGrid 具有一个很好的功能：数据分页支持。在 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 应用程序和 SQL Server^™ 之间设置 TCP 连接可能是一个非常消耗资源的操作。Microsoft 的开发人员到目前为止能够使用连接池已经有一段时间了，这使得他们能够重用数据库连接。他们不是针对每个请求都设置一个新的 TCP 连接，而是只在连接池中没有任何连接时才设置新连接。当连接关闭时，它会返回连接池，在其中它会保持与数据库的连接，而不是完全破坏该 TCP 连接。

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

要以最优化的方式使用连接池，需要遵守一些规则。首先打开连接，执行操作，然后关闭该连接。如果您必须如此的话，可以针对每个请求多次打开和关闭连接（最好应用技巧 1），但是不要一直将连接保持打开状态并使用各种不同的方法对其进行进出传递。第二，使用相同的连接字符串（如果使用集成身份验证的话，还要使用相同的线程标识）。如果不使用相同的连接字符串，例如根据登录的用户自定义连接字符串，那么您将无法得到连接池提供的同一个优化值。如果您使用集成身份验证，同时还要模拟大量用户，连接池的效率也会大大下降。尝试跟踪与连接池相关的任何性能问题时，.NET CLR 数据性能计数器可能非常有用。

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

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

返回页首

技巧 4 — ASP.NET 缓存 API

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

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

对于缓存数据，有几个规则。首先，如果数据可能会多次使用时，则这是使用缓存的一个很好的备选情况。第二，如果数据是通用的，而不特定于某个具体的请求或用户时，则也是使用缓存的一个很好的备选情况。如果数据是特定于用户或请求的，但是寿命较长的话，仍然可以对其进行缓存，但是这种情况可能并不经常使用。第三，一个经常被忽略的规则是，有时可能您缓存得太多。通常在一个 x86 计算机上，为了减少内存不足错误出现的机会，您会想使用不高于 800MB 的专用字节运行进程。因此缓存应该有个限度。换句话说，您可能能够重用某个计算结果，但是如果该计算采用 10 个参数的话，您可能要尝试缓存 10 个排列，这样有可能给您带来麻烦。一个要求 ASP.NET 的最常见支持是由于过度缓存引起的内存不足错误，尤其是对于大型数据集。

图 3 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 功能要连接 SMYP 服务器，然后连续发送电子邮件。当某个特定张贴或主题领域的订阅者数量增加时，执行 AddPost 功能所需的时间也越来越长。

并不需要针对每个请求都进行电子邮件索引。理想情况下，我们想要将此操作进行批处理，一次索引 25 个张贴或者每五分钟发送一次所有电子邮件。我们决定使用以前用于对数据缓存失效进行原型设计的代码，这个失效是用于最终进入 Visual Studio^® 2005 的内容的。

System.Threading 命名空间中的 Timer 类非常有用，但是在 .NET Framework 中不是很有名，至少对于 Web 开发人员来说是这样。创建之后，这个 Timer 类将以一个可配置的间隔针对 ThreadPool 中的某个线程调用指定的回调。这就表示，您可以对代码进行设置，使其能够在没有对 ASP.NET 应用程序进行传入请求的情况下得以执行，这是后台处理的理想情况。您还可以在此后台进程中执行如索引或发送电子邮件之类的操作。

但是，这一技术有几个问题。如果应用程序域卸载，该计时器实例将停止触发其事件。另外，因为 CLR 对于每个进程的线程数量具有一个硬性标准，所以可能会出现这样的情形：服务器负载很重，其中计时器可能没有可在其基础上得以完成的线程，在某种程度上可能会造成延迟。ASP.NET 通过在进程中保留一定数量的可用线程，并且仅使用总线程的一部分用于请求处理，试图将上述情况发生的机会降到最低。但是，如果您具有很多异步操作时，这可能就是一个问题了。

这里没有足够的空间来放置该代码，但是您可以下载一个可以看懂的示例，网址是 http://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 and 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 上宿主的http://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中提供了连接池(Connection Pool)改善打开和关闭数据库对性能的影响。系统将用户的数据库连接放在连接池中，需要时取出，关闭时收回连接，等待下一次的连接请求。连接池的大小是有限的，如果在连接池达到最大限度后仍要求创建连接，必然大大影响性能。因此，在建立数据库连接后只有在真正需要操作时才打开连接，使用完毕后马上关闭，从而尽量减少数据库连接打开的时间，避免出现超出连接限制的情况。 　　

使用存储过程 　
　
存储过程是存储在服务器上的一组预编译的SQL语句，类似于DOS系统中的批处理文件。存储过程具有对数据库立即访问的功能，信息处理极为迅速。使用存储过程可以避免对命令的多次编译，在执行一次后其执行规划就驻留在高速缓存中，以后需要时只需直接调用缓存中的二进制代码即可。另外，存储过程在服务器端运行，独立于ASP.NET程序，便于修改，最重要的是它可以减少数据库操作语句在网络中的传输。

优化查询语句
　　
ASP.NET中ADO连接消耗的资源相当大，SQL语句运行的时间越长，占用系统资源的时间也越长。因此，尽量使用优化过的SQL语句以减少执行时间。比如，不在查询语句中包含子查询语句，充分利用索引等。 　　

2. 字符串操作性能优化　
　
使用值类型的ToString方法
　　
在连接字符串时，经常使用+号直接将数字添加到字符串中。这种方法虽然简单，也可以得到正确结果，但是由于涉及到不同的数据类型，数字需要通过装箱操作转化为引用类型才可以添加到字符串中。但是装箱操作对性能影响较大，因为在进行这类处理时，将在托管堆中分配一个新的对象，原有的值复制到新创建的对象中。使用值类型的ToString方法可以避免装箱操作，从而提高应用程序性能。 　　

运用StringBuilder类 　　

String类对象是不可改变的，对于String对象的重新赋值在本质上是重新创建了一个String对象并将新值赋予该对象，其方法ToString对性能的提高并非很显著。在处理字符串时，最好使用StringBuilder类，其.NET 命名空间是System.Text。该类并非创建新的对象，而是通过Append，Remove，Insert等方法直接对字符串进行操作，通过ToString方法返回操作结果。 　　其定义及操作语句如下所示：

int num; 　　
System.Text.StringBuilder str = new System.Text.StringBuilder(); //创建字符串 　　str.Append(num.ToString()); //添加数值num 　　
Response.Write(str.ToString); //显示操作结果
3. 优化 Web 服务器计算机和特定应用程序的配置文件以符合您的特定需要

默认情况下，ASP.NET 配置被设置成启用最广泛的功能并尽量适应最常见的方案。因此，应用程序开发人员可以根据应用程序所使用的功能，优化和更改其中的某些配置，以提高应用程序的性能。下面的列表是您应该考虑的一些选项。

仅对需要的应用程序启用身份验证。

默认情况下，身份验证模式为 Windows，或集成 NTLM。大多数情况下，对于需要身份验证的应用程序，最好在 Machine.config 文件中禁用身份验证，并在 Web.config 文件中启用身份验证。

根据适当的请求和响应编码设置来配置应用程序。

ASP.NET 默认编码格式为 UTF-8。如果您的应用程序为严格的 ASCII，请配置应用程序使用 ASCII 以获得稍许的性能提高。
　　
考虑对应用程序禁用 AutoEventWireup。

在 Machine.config 文件中将 AutoEventWireup 属性设置为 false，意味着页面不将方法名与事件进行匹配和将两者挂钩(例如 Page_Load)。如果页面开发人员要使用这些事件，需要在基类中重写这些方法(例如，需要为页面加载事件重写 Page.OnLoad，而不是使用 Page_Load 方法)。如果禁用 AutoEventWireup，页面将通过将事件连接留给页面作者而不是自动执行它，获得稍许的性能提升。

从请求处理管线中移除不用的模块。

默认情况下，服务器计算机的 Machine.config 文件中 节点的所有功能均保留为激活。根据应用程序所使用的功能，您可以从请求管线中移除不用的模块以获得稍许的性能提升。检查每个模块及其功能，并按您的需要自定义它。例如，如果您在应用程序中不使用会话状态和输出缓存，则可以从 列表中移除它们，以便请求在不执行其他有意义的处理时，不必执行每个模块的进入和离开代码。

4. 一定要禁用调试模式　　

在部署生产应用程序或进行任何性能测量之前，始终记住禁用调试模式。如果启用了调试模式，应用程序的性能可能受到非常大的影响。 　　

5. 对于广泛依赖外部资源的应用程序，请考虑在多处理器计算机上启用网络园艺　　

ASP.NET 进程模型帮助启用多处理器计算机上的可缩放性，将工作分发给多个进程(每个CPU一个)，并且每个进程都将处理器关系设置为其 CPU。此技术称为网络园艺。如果应用程序使用较慢的数据库服务器或调用具有外部依赖项的 COM 对象(这里只是提及两种可能性)，则为您的应用程序启用网络园艺是有益的。但是，在决定启用网络园艺之前，您应该测试应用程序在网络园中的执行情况。 　　

6. 只要可能，就缓存数据和页输出　　

ASP.NET 提供了一些简单的机制，它们会在不需要为每个页请求动态计算页输出或数据时缓存这些页输出或数据。另外，通过设计要进行缓存的页和数据请求(特别是在站点中预期将有较大通讯量的区域)，可以优化这些页的性能。与 .NET Framework 的任何 Web 窗体功能相比，适当地使用缓存可以更好的提高站点的性能，有时这种提高是超数量级的。使用 ASP.NET 缓存机制有两点需要注意。首先，不要缓存太多项。缓存每个项均有开销，特别是在内存使用方面。不要缓存容易重新计算和很少使用的项。其次，给缓存的项分配的有效期不要太短。很快到期的项会导致缓存中不必要的周转，并且经常导致更多的代码清除和垃圾回收工作。若关心此问题，请监视与 ASP.NET Applications 性能对象关联的 Cache Total Turnover Rate 性能计数器。高周转率可能说明存在问题，特别是当项在到期前被移除时。这也称作内存压力。

7. 选择适合页面或应用程序的数据查看机制　　

根据您选择在 Web 窗体页显示数据的方式，在便利和性能之间常常存在着重要的权衡。例如，DataGrid Web 服务器控件可能是一种显示数据的方便快捷的方法，但就性能而言它的开销常常是最大的。在某些简单的情况下，您通过生成适当的 HTML 自己呈现数据可能很有效，但是自定义和浏览器定向会很快抵销所获得的额外功效。Repeater Web 服务器控件是便利和性能的折衷。它高效、可自定义且可编程。 　　

8. 将 SqlDataReader 类用于快速只进数据游标　　

SqlDataReader 类提供了一种读取从 SQL Server 数据库检索的只进数据流的方法。如果当创建 ASP.NET 应用程序时出现允许您使用它的情况，则 SqlDataReader 类提供比 DataSet 类更高的性能。情况之所以这样，是因为 SqlDataReader 使用 SQL Server 的本机网络数据传输格式从数据库连接直接读取数据。另外，SqlDataReader 类实现 IEnumerable 接口，该接口也允许您将数据绑定到服务器控件。有关更多信息，请参见 SqlDataReader 类。有关 ASP.NET 如何访问数据的信息，请参见通过 ASP.NET 访问数据。 　　

9. 将 SQL Server 存储过程用于数据访问　　

在 .NET Framework 提供的所有数据访问方法中，基于 SQL Server 的数据访问是生成高性能、可缩放 Web 应用程序的推荐选择。使用托管 SQL Server 提供程序时，可通过使用编译的存储过程而不是特殊查询获得额外的性能提高。 　　

10. 避免单线程单元 (STA) COM 组件　　

默认情况下，ASP.NET 不允许任何 STA COM 组件在页面内运行。若要运行它们，必须在 .aspx 文件内将 ASPCompat=true 属性包含在 @ Page 指令中。这样就将执行用的线程池切换到 STA 线程池，而且使 HttpContext 和其他内置对象可用于 COM 对象。前者也是一种性能优化，因为它避免了将多线程单元 (MTA) 封送到 STA 线程的任何调用。使用 STA COM 组件可能大大损害性能，应尽量避免。若必须使用 STA COM 组件，如在任何 interop 方案中，则应在执行期间进行大量调用并在每次调用期间发送尽可能多的信息。另外，小心不要在构造页面期间创建任何 STA COM 组件。例如下面的代码中，在页面构造时将实例化由某个线程创建的 MySTAComponent，而该线程并不是将运行页面的 STA 线程。这可能对性能有不利影响，因为要构造页面就必须完成 MTA 和 STA 线程之间的封送处理。

Dim myComp as new MySTAComponent() Public Sub Page_Load() myComp.Name = Bob End Sub

首选机制是推迟对象的创建，直到以后在 STA 线程下执行上述代码，如下面的例子所示。
Dim myComp Public Sub Page_Load() myComp = new MySTAComponent() myComp.Name = Bob End Sub

推荐的做法是在需要时或者在 Page_Load 方法中构造任何 COM 组件和外部资源。永远不要将任何 STA COM 组件存储在可以由构造它的线程以外的其他线程访问的共享资源里。这类资源包括像缓存和会话状态这样的资源。即使 STA 线程调用 STA COM 组件，也只有构造此 STA COM 组件的线程能够实际为该调用服务，而这要求封送处理对创建者线程的调用。此封送处理可能产生重大的性能损失和可伸缩性问题。在这种情况下，请研究一下使 COM 组件成为 MTA COM 组件的可能性，或者更好的办法是迁移代码以使对象成为托管对象。 　　

11. 将调用密集型的 COM 组件迁移到托管代码　　

.NET Framework 提供了一个简单的方法与传统的 COM 组件进行交互。其优点是可以在保留现有投资的同时利用新的平台。但是在某些情况下，保留旧组件的性能开销使得将组件迁移到托管代码是值得的。每一情况都是不一样的，决定是否需要迁移组件的最好方法是对 Web 站点运行性能测量。建议您研究一下如何将需要大量调用以进行交互的任何COM 组件迁移到托管代码。许多情况下不可能将旧式组件迁移到托管代码，特别是在最初迁移 Web 应用程序时。在这种情况下，最大的性能障碍之一是将数据从非托管环境封送到托管环境。因此，在交互操作中，请在任何一端执行尽可能多的任务，然后进行一个大调用而不是一系列小调用。例如，公共语言运行库中的所有字符串都是 Unicode 的，所以应在调用托管代码之前将组件中的所有字符串转换成 Unicode 格式。另外，一处理完任何 COM 对象或本机资源就释放它们。这样，其他请求就能够使用它们，并且最大限度地减少了因稍后请求垃圾回收器释放它们所引起的性能问题。 　　

12. 在 Visual Basic .NET 或 JScript. 代码中使用早期绑定　　

以往，开发人员喜欢使用 Visual Basic、VBScript. 和 JScript. 的原因之一就是它们所谓“无类型”的性质。变量不需要显式类型声明，并能够简单地通过使用来创建它们。当从一个类型到另一个类型进行分配时，转换将自动执行。不过，这种便利会大大损害应用程序的性能。Visual Basic 现在通过使用 Option Strict 编译器指令来支持类型安全编程。为了向后兼容，默认情况下，ASP.NET 不启用该选项。但是，为了得到最佳性能，强烈建议在页中启用该选项。若要启用 Option Strict，请将 Strict 属性包括在 @ Page 指令中，或者，对于用户控件，请将该属性包括在 @ Control 指令中。下面的示例演示了如何设置该属性，并进行了四个变量调用以显示使用该属性是如何导致编译器错误的。

JScript. .NET 也支持无类型编程，但它不提供强制早期绑定的编译器指令。若发生下面任何一种情况，则变量是晚期绑定的：被显式声明为 Object，是无类型声明的类的字段，是无显式类型声明的专用函数或方法成员，并且无法从其使用推断出类型。 　　最后一个差别比较复杂，因为如果 JScript. .NET 编译器可以根据变量的使用情况推断出类型，它就会进行优化。在下面的示例中，变量 A 是早期绑定的，但变量 B 是晚期绑定的。

var A; 　　var B; 　　A = Hello; 　　B = World; 　　B = 0; 为了获得最佳的性能，当声明 JScript. .NET 变量时，请为其分配一个类型。例如，var A : String。

13. 使请求管线内的所有模块尽可能高效　　

请求管线内的所有模块在每次请求中都有机会被运行。因此，当请求进入和离开模块时快速地触发代码至关重要，特别是在不使用模块功能的代码路径里。分别在使用及不使用模块和配置文件时执行吞吐量测试，对确定这些方法的执行速度非常有用。

14. 使用 HttpServerUtility.Transfer 方法在同一应用程序的页面间重定向　　

采用 Server.Transfer 语法，在页面中使用该方法可避免不必要的客户端重定向。
　　
15. 必要时调整应用程序每个辅助进程的线程数　　

ASP.NET 的请求结构试图在执行请求的线程数和可用资源之间达到一种平衡。已知一个使用足够 CPU 功率的应用程序，该结构将根据可用于请求的 CPU 功率，来决定允许同时执行的请求数。这项技术称作线程门控。但是在某些条件下，线程门控算法不是很有效。通过使用与 ASP.NET Applications 性能对象关联的 Pipeline Instance Count 性能计数器，可以在 PerfMon 中监视线程门控。当页面调用外部资源，如数据库访问或 XML Web services 请求时，页面请求通常停止并释放 CPU。如果某个请求正在等待被处理，并且线程池中有一个线程是自由的，那么这个正在等待的请求将开始被处理。遗憾的是，有时这可能导致 Web 服务器上存在大量同时处理的请求和许多正在等待的线程，而它们对服务器性能有不利影响。通常，如果门控因子是外部资源的响应时间，则让过多请求等待资源，对 Web 服务器的吞吐量并无帮助。为缓和这种情况，可以通过更改 Machine.config 配置文件节点的 maxWorkerThreads 和 maxIOThreads 属性，手动设置进程中的线程数限制。 　　

注意：辅助线程是用来处理 ASP.NET 请求的，而 IO 线程则是用于为来自文件、数据库或 XML Web services 的数据提供服务的。分配给这些属性的值是进程中每个 CPU 每类线程的最大数目。对于双处理器计算机，最大数是设置值的两倍。对于四处理器计算机，最大值是设置值的四倍。无论如何，对于有四个或八个 CPU 的计算机，最好更改默认值。对于有一个或两个处理器的计算机，默认值就可以，但对于有更多处理器的计算机的性能，进程中有一百或两百个线程则弊大于利。注意进程中有太多线程往往会降低服务器的速度，因为额外的上下文交换导致操作系统将 CPU 周期花在维护线程而不是处理请求上。 　　

16. 适当地使用公共语言运行库的垃圾回收器和自动内存管理　　

小心不要给每个请求分配过多内存，因为这样垃圾回收器将必须更频繁地进行更多的工作。另外，不要让不必要的指针指向对象，因为它们将使对象保持活动状态，并且应尽量避免含 Finalize 方法的对象，因为它们在后面会导致更多的工作。特别是在 Finalize 调用中永远不要释放资源，因为资源在被垃圾回收器回收之前可能一直消耗着内存。最后这个问题经常会对 Web 服务器环境的性能造成毁灭性的打击，因为在等待 Finalize 运行时，很容易耗尽某个特定的资源。 　　

17. 如果有大型 Web 应用程序，可考虑执行预批编译　　

每当发生对目录的第一次请求时都会执行批编译。如果目录中的页面没有被分析并编译，此功能会成批分析并编译目录中的所有页面，以便更好地利用磁盘和内存。如果这需要很长时间，则将快速分析并编译单个页面，以便请求能被处理。此功能带给 ASP.NET 性能上的好处，因为它将许多页面编译为单个程序集。从已加载的程序集访问一页比每页加载新的程序集要快。批编译的缺点在于：如果服务器接收到许多对尚未编译的页面的请求，那么当 Web 服务器分析并编译它们时，性能可能较差。为解决这个问题，可以执行预批编译。为此，只需在应用程序激活之前向它请求一个页面，无论哪页均可。然后，当用户首次访问您的站点时，页面及其程序集将已被编译。没有简单的机制可以知道批编译何时发生。需一直等到 CPU 空闲或者没有更多的编译器进程(例如 csc.exe(C# 编译器)或 vbc.exe(Visual Basic 编译器))启动。还应尽量避免更改应用程序的 bin 目录中的程序集。更改页面会导致重新分析和编译该页，而替换 bin 目录中的程序集则会导致完全重新批编译该目录。在包含许多页面的大规模站点上，更好的办法可能是根据计划替换页面或程序集的频繁程度来设计不同的目录结构。不常更改的页面可以存储在同一目录中并在特定的时间进行预批编译。经常更改的页面应在它们自己的目录中(每个目录最多几百页)以便快速编译。Web 应用程序可以包含许多子目录。批编译发生在目录级，而不是应用程序级。

18. 不要依赖代码中的异常　　

因为异常大大地降低性能，所以您不应该将它们用作控制正常程序流程的方式。如果有可能检测到代码中可能导致异常的状态，请执行这种操作。不要在处理该状态之前捕获异常本身。常见的方案包括：检查 null，分配给将分析为数字值的 String 一个值，或在应用数学运算前检查特定值。下面的示例演示可能导致异常的代码以及测试是否存在某种状态的代码。两者产生相同的结果。

　try 　　{ 　　result = 100 / num; 　　} 　　catch (Exception e) 　　{ 　　result = 0; 　　} 　　// ...to this. 　　if (num != 0) 　　result = 100 / num; 　　else 　　result = 0;

19. 使用 HttpResponse.Write 方法进行字符串串联

该方法提供非常有效的缓冲和连接服务。但是，如果您正在执行广泛的连接，请使用多个 Response.Write 调用。下面示例中显示的技术比用对 Response.Write 方法的单个调用连接字符串更快。

Response.Write(a); 　　Response.Write(myString); 　　Response.Write(b); 　　Response.Write(myObj.ToString()); 　　Response.Write(c); 　　Response.Write(myString2); 　　Response.Write(d); 20. 除非有特殊的原因要关闭缓冲，否则使其保持打开

禁用 Web 窗体页的缓冲会导致大量的性能开销。 　　

21. 只在必要时保存服务器控件视图状态　　

自动视图状态管理是服务器控件的功能，该功能使服务器控件可以在往返过程上重新填充它们的属性值(您不需要编写任何代码)。但是，因为服务器控件的视图状态在隐藏的窗体字段中往返于服务器，所以该功能确实会对性能产生影响。您应该知道在哪些情况下视图状态会有所帮助，在哪些情况下它影响页的性能。例如，如果您将服务器控件绑定到每个往返过程上的数据，则将用从数据绑定操作获得的新值替换保存的视图状态。在这种情况下，禁用视图状态可以节省处理时间。默认情况下，为所有服务器控件启用视图状态。若要禁用视图状态，请将控件的EnableViewState 属性设置为 false，如下面的 DataGrid 服务器控件示例所示。

您还可以使用 @ Page 指令禁用整个页的视图状态。当您不从页回发到服务器时，这将十分有用：

注意:@ Control 指令中也支持 EnableViewState 属性，该指令允许您控制是否为用户控件启用视图状态。若要分析页上服务器控件使用的视图状态的数量，请(通过将 trace=true 属性包括在 @ Page 指令中)启用该页的跟踪并查看 Control Hierarchy 表的 Viewstate 列。有关跟踪和如何启用它的信息，请参见 ASP.NET 跟踪。

22. 避免到服务器的不必要的往返过程　　

虽然您很可能希望尽量多地使用 Web 窗体页框架的那些节省时间和代码的功能，但在某些情况下却不宜使用 ASP.NET 服务器控件和回发事件处理。通常，只有在检索或存储数据时，您才需要启动到服务器的往返过程。多数数据操作可在这些往返过程间的客户端上进行。例如，从 HTML 窗体验证用户输入经常可在数据提交到服务器之前在客户端进行。通常，如果不需要将信息传递到服务器以将其存储在数据库中，那么您不应该编写导致往返过程的代码。如果您开发自定义服务器控件，请考虑让它们为支持 ECMAScript. 的浏览器呈现客户端代码。通过以这种方式使用服务器控件，您可以显著地减少信息被不必要的发送到 Web 服务器的次数。

使用 Page.IsPostBack 避免对往返过程执行不必要的处理

如果您编写处理服务器控件回发处理的代码，有时可能需要在首次请求页时执行其他代码，而不是当用户发送包含在该页中的 HTML 窗体时执行的代码。根据该页是否是响应服务器控件事件生成的。

使用 Page.IsPostBack 属性有条件地执行代码

例如，下面的代码演示如何创建数据库连接和命令，该命令在首次请求该页时将数据绑定到 DataGrid 服务器控件。

void Page_Load(Object sender, EventArgs e) 　　
{ 　　// Set up a connection and command here. 　　
if (!Page.IsPostBack) 　　
{ 　　String query = select * from Authors where FirstName like '%JUSTIN%'; 　　myCommand.Fill(ds, Authors); 　　myDataGrid.DataBind(); 　　
}
}

由于每次请求时都执行 Page_Load 事件，上述代码检查 IsPostBack 属性是否设置为 false。如果是，则执行代码。如果该属性设置为 true，则不执行代码。注意 如果不运行这种检查，回发页的行为将不更改。Page_Load 事件的代码在执行服务器控件事件之前执行，但只有服务器控件事件的结果才可能在输出页上呈现。如果不运行该检查，仍将为 Page_Load 事件和该页上的任何服务器控件事件执行处理。 　　

23. 当不使用会话状态时禁用它　　

并不是所有的应用程序或页都需要针对于具体用户的会话状态，您应该对任何不需要会话状态的应用程序或页禁用会话状态。 　　若要禁用页的会话状态，请将 @ Page 指令中的 EnableSessionState 属性设置为 false。例如:

注意:如果页需要访问会话变量，但不打算创建或修改它们，则将@ Page 指令中的 EnableSessionState 属性设置为ReadOnly。还可以禁用 XML Web services 方法的会话状态。有关更多信息，请参见使用 ASP.NET 和 XML Web services 客户端创建的 XML Web services。若要禁用应用程序的会话状态，请在应用程序 Web.config 文件的 sessionstate 配置节中将 mode 属性设置为 off。例如:

24. 仔细选择会话状态提供程序　　

ASP.NET 为存储应用程序的会话数据提供了三种不同的方法：进程内会话状态、作为 Windows 服务的进程外会话状态和 SQL Server 数据库中的进程外会话状态。每种方法都有自己的优点，但进程内会话状态是迄今为止速度最快的解决方案。如果只在会话状态中存储少量易失数据，则建议您使用进程内提供程序。进程外解决方案主要用于跨多个处理器或多个计算机缩放应用程序，或者用于服务器或进程重新启动时不能丢失数据的情况。有关更多信息，请参见 ASP.NET 状态管理。 　　

25. 不使用不必要的Server Control

ASP.net中，大量的服务器端控件方便了程序开发，但也可能带来性能的损失，因为用户每操作一次服务器端控件，就产生一次与服务器端的往返过程。因此，非必要，应当少使用Server Control。 　　

26. ASP.NET应用程序性能测试　　

在对ASP.NET应用程序进行性能测试之前，应确保应用程序没有错误，而且功能正确。具体的性能测试可以采用以下工具进行：Web Application Strees Tool (WAS)是Microsoft发布的一个免费测试工具，它可以模拟成百上千个用户同时对web应用程序进行访问请求，在服务器上形成流量负载，从而达到测试的目的，可以生成平均TTFB、平均TTLB等性能汇总报告。Application Center Test (ACT) 是一个测试工具，附带于Visual Studio.NET的企业版中，是Microsoft正式支持的web应用程序测试工具。它能够直观地生成图表结果，功能比WAS多，但不具备多个客户机同时测试的能力。服务器操作系统管理工具中的性能计数器，可以对服务器进行监测以了解应用程序性能。 　　

结论：

对于网站开发人员来说，在编写ASP.NET应用程序时注意性能问题，养成良好的习惯，提高应用程序性能，至少可以推迟必需的硬件升级，降低网站的成本。