中提供了连接池（Connection Pool）改善打开和关闭数据库对性能的影响。系统将用户的数据库连接放在连接池中，需要时取出，关闭时收回连接，等待下一次的连接请求。
连接池的大小是有限的，如果在连接池达到最大限度后仍要求创建连接，必然大大影响性能。因此，在建立数据库连接后只有在真正需要操作时才打开连接，使用完毕后马上关闭，从而尽量减少数据库连接打开的时间，避免出现超出连接限制的情况。
存储过程是存储在服务器上的一组预编译的SQL语句，类似于DOS系统中的批处理文件。存储过程具有对数据库立即访问的功能，信息处理极为迅 速。使用存储过程可以避免对命令的多次编译，在执行一次后其执行规划就驻留在高速缓存中，以后需要时只需直接调用缓存中的二进制代码即可。
另外，存储过程在服务器端运行，独立于中ADO连接消耗的资源相当大，SQL语句运行的时间越长，占用系统资源的时间也越长。因此，尽量使用优化过的SQL语句以减少执行时间。比如，不在查询语句中包含子查询语句，充分利用索引等。
命名空间是 配置被设置成启用最广泛的功能并尽量适应最常见的方案。因此，应用程序开发人员可以根据应用程序所使用的功能，优化和更改其中的某些配置，以提高应用程序的性能。下面的列表是您应该考虑的一些选项。
仅对需要的应用程序启用身份验证。默认情况下，身份验证模式为 Windows，或集成 NTLM。大多数情况下，对于需要身份验证的应用程序，最好在 默认编码格式为 UTF-8。如果您的应用程序为严格的 ASCII，请配置应用程序使用 ASCII 以获得稍许的性能提高。
考虑对应用程序禁用 AutoEventWireup。在 进程模型帮助启用多处理器计算机上的可缩放性，将工作分发给多个进程（每个 CPU 一个），并且每个进程都将处理器关系设置为其 CPU。此技术称为网络园艺。如果应用程序使用较慢的数据库服务器或调用具有外部依赖项的 COM
对象（这里只是提及两种可能性），则为您的应用程序启用网络园艺是有益的。但是，在决定启用网络园艺之前，您应该测试应用程序在网络园中的执行情况。
提供了一些简单的机制，它们会在不需要为每个页请求动态计算页输出或数据时缓存这些页输出或数据。另外，通过设计要进行缓存的页和数据请求（特别是在站点 中预期将有较大通讯量的区域），可以优化这些页的性能。与 .NET Framework 的任何 Web 窗体功能相比，适当地使用缓存可以更好的提高站点的性能，有时这种提高是超数量级的。
Turnover Rate 性能计数器。高周转率可能说明存在问题，特别是当项在到期前被移除时。这也称作内存压力。
的本机网络数据传输格式从数据库连接直接读取数据。另外，SqlDataReader 类实现 IEnumerable 接口，该接口也允许您将数据绑定到服务器控件。有关更多信息，请参见 SqlDataReader 类。有关 访问数据。
Framework 提供的所有数据访问方法中，基于 SQL Server 的数据访问是生成高性能、可缩放 Web 应用程序的推荐选择。使用托管 SQL Server 提供程序时，可通过使用编译的存储过程而不是特殊查询获得额外的性能提高。
不允许任何 STA COM 组件在页面内运行。若要运行它们，必须在 .aspx 文件内将 ASPCompat=true 属性包含在 @ Page 指令中。这样就将执行用的线程池切换到 STA 线程池，而且使 HttpContext 和其他内置对象可用于 COM 对象。前者也是一种性能优化，因为它避免了将多线程单元 (MTA) 封送到 STA
使用 STA COM 组件可能大大损害性能，应尽量避免。若必须使用 STA COM 组件，如在任何 interop 方案中，则应在执行期间进行大量调用并在每次调用期间发送尽可能多的信息。另外，小心不要在构造页面期间创建任何 STA COM 组件。例如下面的代码中，在页面构造时将实例化由某个线程创建的 MySTAComponent，而该线程并不是将运行页面的 STA
线程。这可能对性能有不利影响，因为要构造页面就必须完成 MTA 和 STA 线程之间的封送处理。
许多情况下不可能将旧式组件迁移到托管代码，特别是在最初迁移 Web 应用程序时。在这种情况下，最大的性能障碍之一是将数据从非托管环境封送到托管环境。因此，在交互操作中，请在任何一端执行尽可能多的任务，然后进行一个 大调用而不是一系列小调用。例如，公共语言运行库中的所有字符串都是 Unicode 的，所以应在调用托管代码之前将组件中的所有字符串转换成 Unicode 格式。
另外，一处理完任何 COM 对象或本机资源就释放它们。这样，其他请求就能够使用它们，并且最大限度地减少了因稍后请求垃圾回收器释放它们所引起的性能问题。
或 JScript 代码中使用早期绑定
以往，开发人员喜欢使用 Visual Basic、VBScript 和 JScript 的原因之一就是它们所谓“无类型”的性质。变量不需要显式类型声明，并能够简单地通过使用来创建它们。当从一个类型到另一个类型进行分配时，转换将自动执 行。不过，这种便利会大大损害应用程序的性能。
Visual Basic 现在通过使用 Option Strict 编译器指令来支持类型安全编程。为了向后兼容，默认情况下， 也支持无类型编程，但它不提供强制早期绑定的编译器指令。若发生下面任何一种情况，则变量是晚期绑定的：
被显式声明为 Object。
是无类型声明的类的字段。
是无显式类型声明的专用函数或方法成员，并且无法从其使用推断出类型。
最后一个差别比较复杂，因为如果 JScript .NET 编译器可以根据变量的使用情况推断出类型，它就会进行优化。在下面的示例中，变量 A 是早期绑定的，但变量 B 是晚期绑定的。
为了获得最佳的性能，当声明 JScript .NET 变量时，请为其分配一个类型。例如，var A : String。
的请求结构试图在执行请求的线程数和可用资源之间达到一种平衡。已知一个使用足够 CPU 功率的应用程序，该结构将根据可用于请求的 CPU 功率，来决定允许同时执行的请求数。这项技术称作线程门控。但是在某些条件下，线程门控算法不是很有效。通过使用与 请求的，而 IO 线程则是用于为来自文件、数据库或 XML Web services 的数据提供服务的。
分配给这些属性的值是进程中每个 CPU 每类线程的最大数目。对于双处理器计算机，最大数是设置值的两倍。对于四处理器计算机，最大值是设置值的四倍。无论如何，对于有四个或八个 CPU 的计算机，最好更改默认值。对于有一个或两个处理器的计算机，默认值就可以，但对于有更多处理器的计算机的性能，进程中有一百或两百个线程则弊大于利。
注意 进程中有太多线程往往会降低服务器的速度，因为额外的上下文交换导致操作系统将 CPU 周期花在维护线程而不是处理请求上。
性能上的好处，因为它将许多页面编译为单个程序集。从已加载的程序集访问一页比每页加载新的程序集要快。
批编译的缺点在于：如果服务器接收到许多对尚未编译的页面的请求，那么当 Web 服务器分析并编译它们时，性能可能较差。为解决这个问题，可以执行预批编译。为此，只需在应用程序激活之前向它请求一个页面，无论哪页均可。然后，当用户 首次访问您的站点时，页面及其程序集将已被编译。
没有简单的机制可以知道批编译何时发生。需一直等到 CPU 空闲或者没有更多的编译器进程（例如 跟踪。
服务器控件和回发事件处理。
通常，只有在检索或存储数据时，您才需要启动到服务器的往返过程。多数数据操作可在这些往返过程间的客户端上进行。例如，从 HTML 窗体验证用户输入经常可在数据提交到服务器之前在客户端进行。通常，如果不需要将信息传递到服务器以将其存储在数据库中，那么您不应该编写导致往返过程的 代码。
如果您开发自定义服务器控件，请考虑让它们为支持 ECMAScript 的浏览器呈现客户端代码。通过以这种方式使用服务器控件，您可以显著地减少信息被不必要的发送到 Web 服务器的次数。
若要禁用应用程序的会话状态，请在应用程序 为存储应用程序的会话数据提供了三种不同的方法：进程内会话状态、作为 Windows 服务的进程外会话状态和 SQL Server 数据库中的进程外会话状态。每种方法都有自己的优点，但进程内会话状态是迄今为止速度最快的解决方案。如果只在会话状态中存储少量易失数据，则建议您使用
进程内提供程序。进程外解决方案主要用于跨多个处理器或多个计算机缩放应用程序，或者用于服务器或进程重新启动时不能丢失数据的情况。有关更多信息，请参 见 中，大量的服务器端控件方便了程序开发，但也可能带来性能的损失，因为用户每操作一次服务器端控件，就产生一次与服务器端的往返过程。因此，非必要，应当少使用Server Control。
在对的企业版中，是Microsoft正式支持的web应用程序测试工具。它能够直观地生成图表结果，功能比WAS多，但不具备多个客户 机同时测试的能力。
现在写一个应用程序的内容，因为它们只是web应用程序的一个子集。本文也不能提供一个完整提高web应用程 序性能的指南，因为这需要一本书的篇幅。本文只提供一个提高web应用程序性能的良好的开端。（剩下的只有我们自己慢慢研究了）。
在工作这外，我经常去攀岩，在每次攀岩之前，我都会重温一下攀岩线路图及看一下前面的成功的攀岩者的建议。因为我们需要它们的成功经验。同样的，当你需要修改某个有性能问题的程序或者是要开发一个高性能的站点时，你也需要学习怎么样写一个高性能的web应用程序。
我个人的经验主要来源于在微软的 Forums，.Text, 和 nGallery的集成升级版本软件）。我想这些经验能我让来帮助大家。
你也许会想到把你的应用程序划分成不同的逻辑层。你也可能听过三层物理架构或N层架构，这是最常用的架构模式，它把不同的程序功能物理的分配给 各个硬件来执行。这样，如果我们想提高应用程序的性能的话，加一些硬件就可以达到目的了。按理说这种方法能提高应用程序的性能,但是我们应该避免使用这种 方法。所以，只要有可能，我们都应该把的Cache；另一种是小的性能优化（tiny
optimizations）。小幅的性能优化有时候非常有用。你只对你的代码作一个小的改到，然后一次调用它一千或一万次。作一次大的性能优化，你会发 生你的应用程序的速度会有一个很大的提升。作一次小的性能优化，也许每次请求只能提高一微秒，但是如果每天的请求量很大的话，那么应用程序就有很显著的性能提升。
当你要优化一个应用程序的性能的时候，你可以按下面的顺序工作：你的代码要访问数据库？如果要，访问数据库频率怎么样？同样，这种测试方法也可 以用在用Web Service或.NET Remoting的程序代码中。本文将不讨论用Web Services和Remoting的程序优化的问题。
如果在你的代码中有一段必须访问数据库的请求，而你在其它的地方又看到实现同样的功能 的代码，那么你首先要优化它。修改和完善继续测试，除非你有一个非常大的性能问题，你的时间最好花在优化查询，连接数据库，返回数据集的大小，以及一次查询往返回的时间上。
根据经验的总结，让我们来看看十个能帮助你提升你的应用程序性能的经验，我将按将它们提升效率的多少从大到小小依次说明。
一、返回多个数据集
检查你的访问数据库的代码，看是否存在着要返回多次的请求。每次往返降低了你的应用程序的每秒能够响应请求的次数。通过在单个数据库请求中返回多个结果集，可以减少与数据库通信的时间，使你的系统具有扩展性，也可以减少数据库服务器响应请求的工作量。
如果你是用动态的SQL语句来返回多个数据集，那我建议你用存储过程来替代动态的SQL语句。是否把业务逻辑写到存储过程中，这个有点争议。但 是我认为，把业务逻辑写到存储过程里面可以限制返回结果集的大小，减小网络数据的流量，在逻辑层也不用在过滤数据，这是一个好事情。
用SqlCommand对象的ExecuteReader方法返回一个强类型的业务对象，再调用NextResult方法来移动数据集指针来定 位数据集。示例一演示了一个返回多个ArrayList强类型对象的例子。只从数据库中返回你需要的数据可以大大的减小你的服务器所耗用的内存。
二、对数据进行分页
Framework中的GC(垃圾收集器)总会在你用完连接对象后调用连接对象的Close或者Dispose方法显式的关闭你的连接。不要期望CLR会 在你想象的时间内关掉连接，虽然CLR最终都要销毁对象和关闭边接，但是我们并不能确定它到底会在什么时候做这些事情。
要用连接池优化，有两条规则，第一，打开连接，处理数据，然后关闭连接。如果你必须在每次请求中多次打开或关闭连接，这好过一直打开一个边接， 然后把它传到各个方法中。第二，用相同的连接字符串（或者用相同的用户标识，当你用集成认证的时候）。如果你没有用相同的连接字符串，如你用基于登录用户
的连接字符串，这将不能利用连接池的优化功能。如果你用的是集成的论证，因为用户很多，所以你也不能充分利用连接池的优化功能。.NET CLR提供了一个数据性能计数器，它在我们需要跟踪程序性能特性的时候非常有用，当然也包括连接池的跟踪了。
无论你的应用程序什么时候要连在另一台机子的资源，如数据库，你都应该重点优化你连资源所花的时间，接收和发送数据的时间，以及往返回之间的次数。优化你的应用程序中的每一个处理点（process hop），它是提高你的应用的性能的出发点。
应用程序层包含与数据层连接，传送数据到相应的类的实例以及业务处理的逻辑。例如，在Community Server中，要组装一个Forums或者Threads集合，然后应用业务逻辑，如授权，更重要的，这里要完成缓存逻辑。
四、 的缓存功能。
如果你的组件是要在中，如果缓存过大的话也会报内存溢出错误，特别是如果缓存大的DataSet对象的时候。
这里有几个你必须了解的重要的缓存机制。首先是缓存实现了“最近使用”原则（ a least-recently-used algorithm），当缓存少的时候，它会自动的强制清除那些无用的缓存。其次 “条件依赖”强制清除原则（expiration dependencies），条件可以是时间，关键字和文件。以时间作为条件是最常用的。在
我们在应用程序可以在没有 请求的时候也可以运行。这就是后以处理的解决方案。你就可以让做索引和发邮件工作在后台运行，而不是在每次请求的时候必须执行。
后台运行的技术有两个问题，第一是，当你的应用程序域卸载后，Timer类实例就会停止运行了。也就是不会调用回调方法了。另外，因为CLR的 每个进程中都有许多的线程在运行，你将很难让Timer获得一个线程来执行它，或者能执行它，但会延时。是你的界面层（或者说应该是），它包含页面，用户控件，服务器控件（HttpHandlers
和HttpModules）以及它们生成的内容。如果你有一个也会生成HTTP头集（HTTP Header）保存在下游的缓存服务器中，这些信息可以用于Microsoft Internet安全性中以及加速服务器的响应速度。当HTTP缓存的头被重置时，请求的内容会被缓在网络资源中，当客户端再次请求该内容时，就不会再从 源服务器上获得内容了，而直接从缓存中获得内容。
虽然用页面输出缓存不提高你的应用程序性能，但是它能减少了从的服务器中加载已缓存页面内容的次数。当然，这仅限于缓存匿名用户可以访问的页面。因为一旦页面被缓存后，就不能再执行授权操作了。
八、 用，当应用了页面输出缓存时，程序中任何代码。当 2005的 性能的程序经理，我的程序员用了这个方法，我看了所有日报表数据，发现用kernel model caching的结果总是最快的。它们的一个共同的特征就是网络的请求和响应量很大,但IIS只占用了5%的CPU资源。这是令人惊奇的。有许多让你使用
用中的一个特性，它用于把生成页面要用的一状态值保存在一个隐藏域中。当页面被回传到服务器时，服务器要解 析，校验和应用ViewState中的数据以还原页面的控件树。ViewState是一个非常有用的特性，它能持久化客户端的状态而不用cookie或者 服务器的内存。大部分的服务器控件都是用ViewState来持久化那些在页面中与用户交互的元素的状态值。例如，用以保存用于分页的当前页的页码。
用ViewState会带来一些负面的影响。首先，它加大的服务器的响应和请求的时间。其次，每次回传时都增加了序列化和反序列化数据的时间。最后，它还消耗了服务器更多的内存。
许多的服务器控件很趋于使用ViewState，如众所周知的DataGrid，而有时候是没有必须使用的。默认情况下是允许使用 ViewState的，如果你不想使用ViewState的话，你可以在控件或页面级别把关闭它。在控件中，你只要把EnableViewState属性 设为False就可以了；你也可以在页面中设置，使它的范围扩展到整个页面中：
如果页面无需回传或者每次请求页面只是呈现控件。你就应该在页面级别中把ViewState关掉。
我只是提供我几个我认为有助于提高写高性能的性能的技巧只是一个起步，更多的信息 请参考《Improving ASP.NET Performance》一书。只有通过自己的实践，你才能找到对你的项目最有帮助的技巧。然而，在你的开发旅程中，这些技巧可以起一些指导性的作用。在 软件开发中，这些都不是绝对有用的，因为各个项目都不一样。
服务器操作系统"管理工具"中的"性能"计数器，可以对服务器进行监测以了解应用程序性能。
