你也许会想到把你的应用程序划分成不同的逻辑层。你也可能听过三层物理架构或N层架构，这是最常用的架构模式，它把不同的程序功能物理的分配给各个硬件来执行。这样，如果我们想提高应用程序的性能的话，加一些硬件就可以达到目的了。按理说这种方法能提高应用程序的性能,但是我们应该避免使用这种方法。所以，只要有可能，我们都应该把asp.net页面和它用到的组件放到一个应用程序中运行。 因为分布式的布署，要用到web services或者Remoting，它将使应用程序的性能下降20%或者更多。
对于数据层有点不同，最好还是把它独立出来布署，用一个单独的硬件来运行它。虽然这样，但是数据库仍然是应用程序性能的瓶颈。因此，当你想优化你的程序的时候，首先想到的地方就应该是优化数据层了。
在修改应用程序的出现性能问题的地方之前，你要先确认出问题的地方的程序看起来很严密，性能分析器对于查找应用程序哪些地方花费了多长时间非常有用。这些地方是我们用直觉感觉不到的。
本文讨论两种类型的性能优化：一种是大的性能优化(big optimizations)，如用asp.net的Cache；另一种是小的性能优化（tiny optimizations）。小幅的性能优化有时候非常有用。你只对你的代码作一个小的改到，然后一次调用它一千或一万次。作一次大的性能优化，你会发生你的应用程序的速度会有一个很大的提升。作一次小的性能优化，也许每次请求只能提高一微秒，但是如果每天的请求量很大的话，那么应用程序就有很显著的性能提升。
数据层的性能
当你要优化一个应用程序的性能的时候，你可以按下面的顺序工作：你的代码要访问数据库？如果要，访问数据库频率怎么样？ 如果在你的代码中有一段必须访问数据库的请求，而你在其它的地方又看到实现同样的功能的代码，那么你首先要优化它。你的时间最好花在优化查询，连接数据库，返回数据集的大小，以及一次查询往返回的时间上。
一、返回多个数据集
检查你的访问数据库的代码，看是否存在着要返回多次的请求。每次往返降低了你的应用程序的每秒能够响应请求的次数。通过在单个数据库请求中返回多个结果集，可以减少与数据库通信的时间，使你的系统具有扩展性，也可以减少数据库服务器响应请求的工作量。
如果你是用动态的SQL语句来返回多个数据集，那我建议你用存储过程来替代动态的SQL语句。是否把业务逻辑写到存储过程中，这个有点争议。但是我认为，把业务逻辑写到存储过程里面可以限制返回结果集的大小，减小网络数据的流量，在逻辑层也不用在过滤数据，这是一个好事情。
用SqlCommand对象的ExecuteReader方法返回一个强类型的业务对象，再调用NextResult方法来移动数据集指针来定位数据集。示例一演示了一个返回多个ArrayList强类型对象的例子。只从数据库中返回你需要的数据可以大大的减小你的服务器所耗用的内存。
二、对数据进行分页
ASP。NET的DataGrid有一个非常有用的功能：分页。如果DataGrid允许分页，在某一时刻它只下载某一页的数据，另外，它有一个数据分页的济览导航栏，它让你可以选择浏览某一页，而且每次只下载一页的数据。
但是它有一个小小的缺点，就是你必须把所有的数据都绑定到DataGrid中。也就是说，你的数据层必须返回所有的数据，然后DataGrid再根据当前页过滤出当前页所需要的数据显示出来。如果有一个一万条记录的结果集要用DataGrid进行分页，假设DataGrid每页只显示25条数据，那就意味着每次请求都有9975条数据都是要丢弃的。每次请求都要返回这么大的数据集，对应用程序的性能影响是非常大的。
一个好的解决方案是写一个分页的存储过程，例子2是一个用于对Northwind数据库orders表的分页存储过程。你只需要传当前页码，每页显示的条数两个参数进来，存储过程会返回相应的结果。
在服务器端，我专门写了一个分页的控件来处理数据的分页，在这里，我用了第一个方法，在一个存储过程里面返回了两个结果集：数据记录总数和要求的结果集。
返回的记录总数取决于要执行查询，例如，一个where条件可以限制返回的结果集的大小。因为在分页界面中必须要根据数据集记录的大小来计算总的页数，所以必须要返回结果集的记录数。例如，如果一共有1000000条记录，如果用where条件就可以过滤成只返回1000条记录，存储过程的分页逻辑应该知道返回那些需要显示的数据。
三、连接池
用TCP来连接你的应用程序与数据库是一件昂贵的事情（很费时的事情），微软的开发者可以通过用连接池来反复的使用数据库的连接。比起每次请求都用TCP来连一次数据库，连接池只有在不存在有效的连接时才新建一个TCP连接。当关闭一个连接的时候，它会被放到池中，它仍然会保持与数据库的连接，这样就可以减少与数据库的TCP连接次数。
当然，你要注意那些忘记关的连接，你应在每次用完连接后马上关闭它。我要强调的是：无论什么人说.net framework中的GC(垃圾收集器)总会在你用完连接对象后调用连接对象的Close或者Dispose方法显式的关闭你的连接。不要期望CLR会在你想象的时间内关掉连接，虽然CLR最终都要销毁对象和关闭连接，但是我们并不能确定它到底会在什么时候做这些事情。
要用连接池优化，有两条规则，第一，打开连接，处理数据，然后关闭连接。如果你必须在每次请求中多次打开或关闭连接，这好过一直打开一个边接，然后把它传到各个方法中。第二，用相同的连接字符串（或者用相同的用户标识，当你用集成认证的时候）。如果你没有用相同的连接字符串，如你用基于登录用户的连接字符串，这将不能利用连接池的优化功能。如果你用的是集成的论证，因为用户很多，所以你也不能充分利用连接池的优化功能。.NET CLR提供了一个数据性能计数器，它在我们需要跟踪程序性能特性的时候非常有用，当然也包括连接池的跟踪了。
无论你的应用程序什么时候要连在另一台机子的资源，如数据库，你都应该重点优化你连资源所花的时间，接收和发送数据的时间，以及往返回之间的次数。优化你的应用程序中的每一个处理点（process hop），它是提高你的应用的性能的出发点。
应用程序层包含与数据层连接，传送数据到相应的类的实例以及业务处理的逻辑。例如，在Community Server中，要组装一个Forums或者Threads集合，然后应用业务逻辑，如授权，更重要的，这里要完成缓存逻辑。
四、 ASP。NET缓存API
在写应用程序之前,你要做的第一件事是让应用程序最大化的利用ASP.NET的缓存功能。
如果你的组件是要在Asp.net应用程序中运行，你只要把System.Web.dll引用到你的项目中就可以了。然后用HttpRuntime.Cache属性就可访问Cache了（也可以通过Page.Cache或HttpContext.Cache访问）。
有以下几条缓存数据的规则。第一，数据可能会被频繁的被使用，这种数据可以缓存。第二，数据的访问频率非常高，或者一个数据的访问频率不高，但是它的生存周期很长，这样的数据最好也缓存起来。第三是一个常常被忽略的问题，有时候我们缓存了太多数据，通常在一台X86的机子上，如果你要缓存的数据超过800M的话，就会出现内存溢出的错误。所以说缓存是有限的。换名话说，你应该估计缓存集的大小，把缓存集的大小限制在10以内，否则它可能会出问题。在Asp.net中，如果缓存过大的话也会报内存溢出错误，特别是如果缓存大的DataSet对象的时候。
这里有几个你必须了解的重要的缓存机制。首先是缓存实现了“最近使用”原则（ a least-recently-used algorithm），当缓存少的时候，它会自动的强制清除那些无用的缓存。其次 “条件依赖”强制清除原则（expiration dependencies），条件可以是时间，关键字和文件。以时间作为条件是最常用的。在asp.net2.0中增加一更强的条件，就是数据库条件。当数据库中的数据发生变化时，就会强制清除缓存。要更深入的了解数据库条件依赖请看Dino Esposito 在MSDN杂志2004年七月刊的Cutting Edge专栏文章。Asp.net的缓存架构如下图所示：
五、 预请求缓存
在前面，我提到过即使我们只对某些地方作了一个小小的性能改进也可以获得大的性能提升，我非常喜欢用预请求缓存来提升程序的性能。
虽然Cache API设计成用来保存某段时间的数据，而预请求缓存只是保存某个时期的某个请求的内容。如果某个请求的访问频率高，而且这个请求只需要提取，应用，修改或者更新数据一次。那么就可以预缓存该请求。我们举个例子来说明。
在CS的论坛应用程序中，每一个页面的服务器控件都要求得到用于决定它的皮肤（skin）的自定义的数据，以决定用哪个样式表及其它的一些个性化的东西。这里面的某些数据可能要长时间的保存，有些时间则不然，如控件的skin数据，它只需要应用一次，而后就可以一直使用。
要实现预请求缓存，用Asp.net 的HttpContext类，HttpContext类的实例在每一个请求中创建，在请求期间的任何地方都可以通过HttpContext.Current属性访问。HttpContext类有一个Items集合属性，在请求期间所有的对象和数据都被添加到这个集合中缓存起来。和你用Cache缓存访问频率高数据一样，你可以用HttpContext.Items缓存那些每个请求都要用到的基础数据。它背后的逻辑很简单：我们向HttpContext.Items中添加一个数据，然后再从它里面读出数据。
六、 后台处理
通过上面的方法你的应用程序应该运行得很快了，是不是？但是在某些时候，程序中的一次请求中可能要执行一个非常耗时的任务。如发送邮件或者是检查提交的数据的正确性等。
当我们把asp.net Forums 1.0集成在CS中的时侯，发现提交一个新的帖子的时候会非常的慢。每次新增一个帖子的时侯，应用程序首先要检查这个帖子是不是重复提的，然后用“badword”过滤器来过滤，检查图片附加码，作帖子的索引，把它添加到合适的队列中，验证它的附件，最后，发邮件到它的订阅者邮件箱中。显然，这个工作量很大。
结果是它把大量的时间都花在做索引和发送邮件中了。做帖子的索引是一项很耗时的操作，而发邮件给订阅都需要连接到SMTP服务，然后给每一个订阅者都发一封邮件，随着订阅用户的增加，发送邮件的时间会更长。
索引和发邮件并不需要在每次请求时触发，理想状态下，我们想要批量的处理这些操作，每次只发25封邮件或者每隔5分钟把所有的要发的新邮件发一次。我们决定使用与数据库原型缓存一样的代码，但是失败了，所以又不得不回到VS.NET 2005。
我们在System.Threading命名空间下找到了Timer类，这个类非常有用，但却很少有人知道，Web开发人员则更少有人知道了。一旦他建了该类的实例，每隔一个指定的时间，Timer类就会从线程池中的一个线程中调用指定的回调函数。这意味着你的asp.net应用程序可以在没有请求的时候也可以运行。这就是后以处理的解决方案。你就可以让做索引和发邮件工作在后台运行，而不是在每次请求的时候必须执行。
后台运行的技术有两个问题，第一是，当你的应用程序域卸载后，Timer类实例就会停止运行了。也就是不会调用回调方法了。另外，因为CLR的每个进程中都有许多的线程在运行，你将很难让Timer获得一个线程来执行它，或者能执行它，但会延时。Asp.net层要尽量少的使用这种技术，以减少进程中线程的数量，或者只让请求用一小部分的线程。当然如果你有大量的异步工作的话，那就只能用它了。
这里没有足够的空间有贴代码，你可以从http://www.rob-howard.net/中下载示例程序，请下载Blackbelt TechEd 2004的示例程序。
七、 页面输出缓存和代理服务
Asp.net是你的界面层（或者说应该是），它包含页面，用户控件，服务器控件（HttpHandlers 和HttpModules）以及它们生成的内容。如果你有一个Asp.net页面用来输出html，xml,imgae或者是其它的数据，对每一个请求你都用代码来生成相同的输出内容，你就很有必要考虑用页面输出缓存了。
你只要简单的把下面的这一行代码复制到你的页面中就可以实现了：
你就可以有效的利用第一次请求里生成的页面输出缓存内容，60秒后重新生成一道页面内容。这种技术其实也是运用一些低层的Cache API来实现。用页面输出缓存有几个参数可以配置，如上面所说的VaryByParams参数，该参数表示什么时候触发重输出的条件，也可以指定在Http Get或Http Post 请求模式下缓存输出。例如当我们设置该参数为VaryByParams=”Report”的时候，default.aspx?Report=1或者default.aspx?Report=2请求的输出都会被缓存起来。参数的值可以是多个用分号隔开参数。
许多人都没有意识到当用页面输出缓存的时候，asp.net也会生成HTTP头集（HTTP Header）保存在下游的缓存服务器中，这些信息可以用于Microsoft Internet安全性中以及加速服务器的响应速度。当HTTP缓存的头被重置时，请求的内容会被缓在网络资源中，当客户端再次请求该内容时，就不会再从源服务器上获得内容了，而直接从缓存中获得内容。
虽然用页面输出缓存不提高你的应用程序性能，但是它能减少了从的服务器中加载已缓存页面内容的次数。当然，这仅限于缓存匿名用户可以访问的页面。因为一旦页面被缓存后，就不能再执行授权操作了。
八、 用IIS6.0的Kernel Caching
如果你的应用程序没用运行在IIS6.0(windows server 2003)中，那么你就失去了一些很好的提高应用程序性能的方法。在第七个方法中，我讲了用页面输出缓存提高应用程序的性能的方法。在IIS5.0中，当一个请求到来到IIS后，IIS会把它转给asp.net，当应用了页面输出缓存时，ASP.NET中的HttpHandler会接到该请求，HttpHandler从缓存中把内容取出来并返回。
如果你用的是IIS6.0，它有一个非常好的功能就是Kernel Caching，而且你不必修改asp.net程序中任何代码。当asp.net接到一个已缓存的请求，IIS的Kernel Cache会从缓存中得到它的一份拷贝。当从网络中传来一个请求的时，Kernel层会得到该请求，如果该请求被缓存起来了，就直接把缓存的数据返回，这样就完工了。这就意味着当你用IIS的Kernel Caching来缓存页面输出时，你将获得不可置信的性能提升。在开发VS.NET 2005的 asp.net时有一点，我是专门负asp.net性能的程序经理，我的程序员用了这个方法，我看了所有日报表数据，发现用kernel model caching的结果总是最快的。它们的一个共同的特征就是网络的请求和响应量很大,但IIS只占用了5%的CPU资源。这是令人惊奇的。有许多让你使用用IIS6.0的理由，但kernel cashing是最好的一个。
九、 用Gzip压缩数据
除非你的CPU占用率太高了，才有必要用提升服务器性能的技巧。用gzip压缩数据的方法可以减少你发送到服务端的数据量，也可以提高页面的运行速度，同时也减少了网络的流量。怎么样更好的压缩数据取决于你要发送的数据，还有就是客户端的浏览器支不支持（IIS把用gzip压缩后的数据发送到客户端，客户端要支持gzip才能解析，IE6.0和Firefox都支持）。这样你的服务器每秒能多响应一些请求，同样，你也减少了发送响应的数据量，也就能多发送一些请求了。
好消息，gzip压缩已经被集成在IIS6.0中了，它比IIS5.0中gzip更好。不幸的是，在IIS6.0中启用gzip压缩，你不能在IIS6.0的属性对话中设置。IIS开发团队把gzip压缩功能开发出来了，但他们却忘了在管理员窗口中让管理员能很方便的启用它。要启用gzip压缩，你只能深入IIS6.0的xml配置文件中修改它的配置。
除了阅读本文以外，只好再看看Brad Wilson写的（http://www.dotnetdevs.com/articles/IIS6compression.aspx）；一文；另外还有一篇介绍aspx压缩基础知识的文章，Enable ASPX Compression in IIS。但是要注意，在IIS6中动态压缩和kernel cashing是互斥的。
引用内容
十、 服务器控件的ViewState
ViewState是asp.net中的一个特性，它用于把生成页面要用的一状态值保存在一个隐藏域中。当页面被回传到服务器时，服务器要解析，校验和应用ViewState中的数据以还原页面的控件树。ViewState是一个非常有用的特性，它能持久化客户端的状态而不用cookie或者服务器的内存。大部分的服务器控件都是用ViewState来持久化那些在页面中与用户交互的元素的状态值。例如，用以保存用于分页的当前页的页码。
用ViewState会带来一些负面的影响。首先，它加大的服务器的响应和请求的时间。其次，每次回传时都增加了序列化和反序列化数据的时间。最后，它还消耗了服务器更多的内存。
许多的服务器控件很趋于使用ViewState，如众所周知的DataGrid，而有时候是没有必须使用的。默认情况下是允许使用ViewState的，如果你不想使用ViewState的话，你可以在控件或页面级别把关闭它。在控件中，你只要把EnableViewState属性设为False就可以了；你也可以在页面中设置，使它的范围扩展到整个页面中：
如果页面无需回传或者每次请求页面只是呈现控件。你就应该在页面级别中把ViewState关掉。
对于数据层有点不同，最好还是把它独立出来布署，用一个单独的硬件来运行它。虽然这样，但是数据库仍然是应用程序性能的瓶颈。因此，当你想优化你的程序的时候，首先想到的地方就应该是优化数据层了。
在修改应用程序的出现性能问题的地方之前，你要先确认出问题的地方的程序看起来很严密，性能分析器对于查找应用程序哪些地方花费了多长时间非常有用。这些地方是我们用直觉感觉不到的。
本文讨论两种类型的性能优化：一种是大的性能优化(big optimizations)，如用asp.net的Cache；另一种是小的性能优化（tiny optimizations）。小幅的性能优化有时候非常有用。你只对你的代码作一个小的改到，然后一次调用它一千或一万次。作一次大的性能优化，你会发生你的应用程序的速度会有一个很大的提升。作一次小的性能优化，也许每次请求只能提高一微秒，但是如果每天的请求量很大的话，那么应用程序就有很显著的性能提升。
数据层的性能
当你要优化一个应用程序的性能的时候，你可以按下面的顺序工作：你的代码要访问数据库？如果要，访问数据库频率怎么样？ 如果在你的代码中有一段必须访问数据库的请求，而你在其它的地方又看到实现同样的功能的代码，那么你首先要优化它。你的时间最好花在优化查询，连接数据库，返回数据集的大小，以及一次查询往返回的时间上。
一、返回多个数据集
检查你的访问数据库的代码，看是否存在着要返回多次的请求。每次往返降低了你的应用程序的每秒能够响应请求的次数。通过在单个数据库请求中返回多个结果集，可以减少与数据库通信的时间，使你的系统具有扩展性，也可以减少数据库服务器响应请求的工作量。
如果你是用动态的SQL语句来返回多个数据集，那我建议你用存储过程来替代动态的SQL语句。是否把业务逻辑写到存储过程中，这个有点争议。但是我认为，把业务逻辑写到存储过程里面可以限制返回结果集的大小，减小网络数据的流量，在逻辑层也不用在过滤数据，这是一个好事情。
用SqlCommand对象的ExecuteReader方法返回一个强类型的业务对象，再调用NextResult方法来移动数据集指针来定位数据集。示例一演示了一个返回多个ArrayList强类型对象的例子。只从数据库中返回你需要的数据可以大大的减小你的服务器所耗用的内存。
二、对数据进行分页
ASP。NET的DataGrid有一个非常有用的功能：分页。如果DataGrid允许分页，在某一时刻它只下载某一页的数据，另外，它有一个数据分页的济览导航栏，它让你可以选择浏览某一页，而且每次只下载一页的数据。
但是它有一个小小的缺点，就是你必须把所有的数据都绑定到DataGrid中。也就是说，你的数据层必须返回所有的数据，然后DataGrid再根据当前页过滤出当前页所需要的数据显示出来。如果有一个一万条记录的结果集要用DataGrid进行分页，假设DataGrid每页只显示25条数据，那就意味着每次请求都有9975条数据都是要丢弃的。每次请求都要返回这么大的数据集，对应用程序的性能影响是非常大的。
一个好的解决方案是写一个分页的存储过程，例子2是一个用于对Northwind数据库orders表的分页存储过程。你只需要传当前页码，每页显示的条数两个参数进来，存储过程会返回相应的结果。
在服务器端，我专门写了一个分页的控件来处理数据的分页，在这里，我用了第一个方法，在一个存储过程里面返回了两个结果集：数据记录总数和要求的结果集。
返回的记录总数取决于要执行查询，例如，一个where条件可以限制返回的结果集的大小。因为在分页界面中必须要根据数据集记录的大小来计算总的页数，所以必须要返回结果集的记录数。例如，如果一共有1000000条记录，如果用where条件就可以过滤成只返回1000条记录，存储过程的分页逻辑应该知道返回那些需要显示的数据。
三、连接池
用TCP来连接你的应用程序与数据库是一件昂贵的事情（很费时的事情），微软的开发者可以通过用连接池来反复的使用数据库的连接。比起每次请求都用TCP来连一次数据库，连接池只有在不存在有效的连接时才新建一个TCP连接。当关闭一个连接的时候，它会被放到池中，它仍然会保持与数据库的连接，这样就可以减少与数据库的TCP连接次数。
当然，你要注意那些忘记关的连接，你应在每次用完连接后马上关闭它。我要强调的是：无论什么人说.net framework中的GC(垃圾收集器)总会在你用完连接对象后调用连接对象的Close或者Dispose方法显式的关闭你的连接。不要期望CLR会在你想象的时间内关掉连接，虽然CLR最终都要销毁对象和关闭连接，但是我们并不能确定它到底会在什么时候做这些事情。
要用连接池优化，有两条规则，第一，打开连接，处理数据，然后关闭连接。如果你必须在每次请求中多次打开或关闭连接，这好过一直打开一个边接，然后把它传到各个方法中。第二，用相同的连接字符串（或者用相同的用户标识，当你用集成认证的时候）。如果你没有用相同的连接字符串，如你用基于登录用户的连接字符串，这将不能利用连接池的优化功能。如果你用的是集成的论证，因为用户很多，所以你也不能充分利用连接池的优化功能。.NET CLR提供了一个数据性能计数器，它在我们需要跟踪程序性能特性的时候非常有用，当然也包括连接池的跟踪了。
无论你的应用程序什么时候要连在另一台机子的资源，如数据库，你都应该重点优化你连资源所花的时间，接收和发送数据的时间，以及往返回之间的次数。优化你的应用程序中的每一个处理点（process hop），它是提高你的应用的性能的出发点。
应用程序层包含与数据层连接，传送数据到相应的类的实例以及业务处理的逻辑。例如，在Community Server中，要组装一个Forums或者Threads集合，然后应用业务逻辑，如授权，更重要的，这里要完成缓存逻辑。
四、 ASP。NET缓存API
在写应用程序之前,你要做的第一件事是让应用程序最大化的利用ASP.NET的缓存功能。
如果你的组件是要在Asp.net应用程序中运行，你只要把System.Web.dll引用到你的项目中就可以了。然后用HttpRuntime.Cache属性就可访问Cache了（也可以通过Page.Cache或HttpContext.Cache访问）。
有以下几条缓存数据的规则。第一，数据可能会被频繁的被使用，这种数据可以缓存。第二，数据的访问频率非常高，或者一个数据的访问频率不高，但是它的生存周期很长，这样的数据最好也缓存起来。第三是一个常常被忽略的问题，有时候我们缓存了太多数据，通常在一台X86的机子上，如果你要缓存的数据超过800M的话，就会出现内存溢出的错误。所以说缓存是有限的。换名话说，你应该估计缓存集的大小，把缓存集的大小限制在10以内，否则它可能会出问题。在Asp.net中，如果缓存过大的话也会报内存溢出错误，特别是如果缓存大的DataSet对象的时候。
这里有几个你必须了解的重要的缓存机制。首先是缓存实现了“最近使用”原则（ a least-recently-used algorithm），当缓存少的时候，它会自动的强制清除那些无用的缓存。其次 “条件依赖”强制清除原则（expiration dependencies），条件可以是时间，关键字和文件。以时间作为条件是最常用的。在asp.net2.0中增加一更强的条件，就是数据库条件。当数据库中的数据发生变化时，就会强制清除缓存。要更深入的了解数据库条件依赖请看Dino Esposito 在MSDN杂志2004年七月刊的Cutting Edge专栏文章。Asp.net的缓存架构如下图所示：
五、 预请求缓存
在前面，我提到过即使我们只对某些地方作了一个小小的性能改进也可以获得大的性能提升，我非常喜欢用预请求缓存来提升程序的性能。
虽然Cache API设计成用来保存某段时间的数据，而预请求缓存只是保存某个时期的某个请求的内容。如果某个请求的访问频率高，而且这个请求只需要提取，应用，修改或者更新数据一次。那么就可以预缓存该请求。我们举个例子来说明。
在CS的论坛应用程序中，每一个页面的服务器控件都要求得到用于决定它的皮肤（skin）的自定义的数据，以决定用哪个样式表及其它的一些个性化的东西。这里面的某些数据可能要长时间的保存，有些时间则不然，如控件的skin数据，它只需要应用一次，而后就可以一直使用。
要实现预请求缓存，用Asp.net 的HttpContext类，HttpContext类的实例在每一个请求中创建，在请求期间的任何地方都可以通过HttpContext.Current属性访问。HttpContext类有一个Items集合属性，在请求期间所有的对象和数据都被添加到这个集合中缓存起来。和你用Cache缓存访问频率高数据一样，你可以用HttpContext.Items缓存那些每个请求都要用到的基础数据。它背后的逻辑很简单：我们向HttpContext.Items中添加一个数据，然后再从它里面读出数据。
六、 后台处理
通过上面的方法你的应用程序应该运行得很快了，是不是？但是在某些时候，程序中的一次请求中可能要执行一个非常耗时的任务。如发送邮件或者是检查提交的数据的正确性等。
当我们把asp.net Forums 1.0集成在CS中的时侯，发现提交一个新的帖子的时候会非常的慢。每次新增一个帖子的时侯，应用程序首先要检查这个帖子是不是重复提的，然后用“badword”过滤器来过滤，检查图片附加码，作帖子的索引，把它添加到合适的队列中，验证它的附件，最后，发邮件到它的订阅者邮件箱中。显然，这个工作量很大。
结果是它把大量的时间都花在做索引和发送邮件中了。做帖子的索引是一项很耗时的操作，而发邮件给订阅都需要连接到SMTP服务，然后给每一个订阅者都发一封邮件，随着订阅用户的增加，发送邮件的时间会更长。
索引和发邮件并不需要在每次请求时触发，理想状态下，我们想要批量的处理这些操作，每次只发25封邮件或者每隔5分钟把所有的要发的新邮件发一次。我们决定使用与数据库原型缓存一样的代码，但是失败了，所以又不得不回到VS.NET 2005。
我们在System.Threading命名空间下找到了Timer类，这个类非常有用，但却很少有人知道，Web开发人员则更少有人知道了。一旦他建了该类的实例，每隔一个指定的时间，Timer类就会从线程池中的一个线程中调用指定的回调函数。这意味着你的asp.net应用程序可以在没有请求的时候也可以运行。这就是后以处理的解决方案。你就可以让做索引和发邮件工作在后台运行，而不是在每次请求的时候必须执行。
后台运行的技术有两个问题，第一是，当你的应用程序域卸载后，Timer类实例就会停止运行了。也就是不会调用回调方法了。另外，因为CLR的每个进程中都有许多的线程在运行，你将很难让Timer获得一个线程来执行它，或者能执行它，但会延时。Asp.net层要尽量少的使用这种技术，以减少进程中线程的数量，或者只让请求用一小部分的线程。当然如果你有大量的异步工作的话，那就只能用它了。
这里没有足够的空间有贴代码，你可以从http://www.rob-howard.net/中下载示例程序，请下载Blackbelt TechEd 2004的示例程序。
七、 页面输出缓存和代理服务
Asp.net是你的界面层（或者说应该是），它包含页面，用户控件，服务器控件（HttpHandlers 和HttpModules）以及它们生成的内容。如果你有一个Asp.net页面用来输出html，xml,imgae或者是其它的数据，对每一个请求你都用代码来生成相同的输出内容，你就很有必要考虑用页面输出缓存了。
你只要简单的把下面的这一行代码复制到你的页面中就可以实现了：
你就可以有效的利用第一次请求里生成的页面输出缓存内容，60秒后重新生成一道页面内容。这种技术其实也是运用一些低层的Cache API来实现。用页面输出缓存有几个参数可以配置，如上面所说的VaryByParams参数，该参数表示什么时候触发重输出的条件，也可以指定在Http Get或Http Post 请求模式下缓存输出。例如当我们设置该参数为VaryByParams=”Report”的时候，default.aspx?Report=1或者default.aspx?Report=2请求的输出都会被缓存起来。参数的值可以是多个用分号隔开参数。
许多人都没有意识到当用页面输出缓存的时候，asp.net也会生成HTTP头集（HTTP Header）保存在下游的缓存服务器中，这些信息可以用于Microsoft Internet安全性中以及加速服务器的响应速度。当HTTP缓存的头被重置时，请求的内容会被缓在网络资源中，当客户端再次请求该内容时，就不会再从源服务器上获得内容了，而直接从缓存中获得内容。
虽然用页面输出缓存不提高你的应用程序性能，但是它能减少了从的服务器中加载已缓存页面内容的次数。当然，这仅限于缓存匿名用户可以访问的页面。因为一旦页面被缓存后，就不能再执行授权操作了。
八、 用IIS6.0的Kernel Caching
如果你的应用程序没用运行在IIS6.0(windows server 2003)中，那么你就失去了一些很好的提高应用程序性能的方法。在第七个方法中，我讲了用页面输出缓存提高应用程序的性能的方法。在IIS5.0中，当一个请求到来到IIS后，IIS会把它转给asp.net，当应用了页面输出缓存时，ASP.NET中的HttpHandler会接到该请求，HttpHandler从缓存中把内容取出来并返回。
如果你用的是IIS6.0，它有一个非常好的功能就是Kernel Caching，而且你不必修改asp.net程序中任何代码。当asp.net接到一个已缓存的请求，IIS的Kernel Cache会从缓存中得到它的一份拷贝。当从网络中传来一个请求的时，Kernel层会得到该请求，如果该请求被缓存起来了，就直接把缓存的数据返回，这样就完工了。这就意味着当你用IIS的Kernel Caching来缓存页面输出时，你将获得不可置信的性能提升。在开发VS.NET 2005的 asp.net时有一点，我是专门负asp.net性能的程序经理，我的程序员用了这个方法，我看了所有日报表数据，发现用kernel model caching的结果总是最快的。它们的一个共同的特征就是网络的请求和响应量很大,但IIS只占用了5%的CPU资源。这是令人惊奇的。有许多让你使用用IIS6.0的理由，但kernel cashing是最好的一个。
九、 用Gzip压缩数据
除非你的CPU占用率太高了，才有必要用提升服务器性能的技巧。用gzip压缩数据的方法可以减少你发送到服务端的数据量，也可以提高页面的运行速度，同时也减少了网络的流量。怎么样更好的压缩数据取决于你要发送的数据，还有就是客户端的浏览器支不支持（IIS把用gzip压缩后的数据发送到客户端，客户端要支持gzip才能解析，IE6.0和Firefox都支持）。这样你的服务器每秒能多响应一些请求，同样，你也减少了发送响应的数据量，也就能多发送一些请求了。
好消息，gzip压缩已经被集成在IIS6.0中了，它比IIS5.0中gzip更好。不幸的是，在IIS6.0中启用gzip压缩，你不能在IIS6.0的属性对话中设置。IIS开发团队把gzip压缩功能开发出来了，但他们却忘了在管理员窗口中让管理员能很方便的启用它。要启用gzip压缩，你只能深入IIS6.0的xml配置文件中修改它的配置。
除了阅读本文以外，只好再看看Brad Wilson写的（http://www.dotnetdevs.com/articles/IIS6compression.aspx）；一文；另外还有一篇介绍aspx压缩基础知识的文章，Enable ASPX Compression in IIS。但是要注意，在IIS6中动态压缩和kernel cashing是互斥的。
引用内容Summary
Windows Server 2003 is, without a doubt, the best platform for running ASP.NET available. Turning on the compression built into IIS6 allows you to save valuable bandwidth with your ASP.NET-based web sites.
Compressible Content
If you follow these directions from Microsoft, you'll have compression enabled, but still non-functional for ASP.NET. The reason is that the ASP.NET file extension (.aspx) is not set as a valid compressible file extension.
To make this change, you're going to need to edit the Metabase. Edit \Windows\System32\inetsrv\MetaBase.xml with your favorite text editor. Search for "IIsCompressionScheme". There will be two XML elements, one for deflate and one for gzip. Both elements have properties called HcFileExtensions and HcScriptFileExtensions. These contain a space-delimited list of file extension for compressible content. At a bare minimum, you'll need to add aspx to the HcScriptFileExtensions list. Note that if the properties are left blank, then all content, regardless of file extension, will be compressed.
Now fire up a tool like YATT and watch the HTTP stream as you make a request. You should see in the response headers that indicate that the content is being compressed (and it should look like garbage, rather than HTML, since it's compressed).
What if it Still Doesn't Work?
I've had a rather unique problem that others can't seem to replicate. I'm going to document it here, in case anybody else runs into a problem where it seems like compression should be working, but isn't. Don't do this unless you find compression isn't working even after following the steps above.
Open the IIS admin tool, drill into your server, and right-click on "Web Service Extensions". Choose "Add a new web service extension". For the extension name, use whatever you want to identify it in the list (I used "HTTP Compression"). You need to add a single required file, which is \Windows\System32\inetsrv\gzip.dll, the ISAPI responsible for doing gzip and deflate compression. Check the "Set extension status to allowed", then click OK. You should have a new web service extension in your list called "HTTP Compression" (or whatever you named it), and it should have a status of "Allowed".
Windows Server 2003 is, without a doubt, the best platform for running ASP.NET available. Turning on the compression built into IIS6 allows you to save valuable bandwidth with your ASP.NET-based web sites.
Compressible Content
If you follow these directions from Microsoft, you'll have compression enabled, but still non-functional for ASP.NET. The reason is that the ASP.NET file extension (.aspx) is not set as a valid compressible file extension.
To make this change, you're going to need to edit the Metabase. Edit \Windows\System32\inetsrv\MetaBase.xml with your favorite text editor. Search for "IIsCompressionScheme". There will be two XML elements, one for deflate and one for gzip. Both elements have properties called HcFileExtensions and HcScriptFileExtensions. These contain a space-delimited list of file extension for compressible content. At a bare minimum, you'll need to add aspx to the HcScriptFileExtensions list. Note that if the properties are left blank, then all content, regardless of file extension, will be compressed.
Now fire up a tool like YATT and watch the HTTP stream as you make a request. You should see in the response headers that indicate that the content is being compressed (and it should look like garbage, rather than HTML, since it's compressed).
What if it Still Doesn't Work?
I've had a rather unique problem that others can't seem to replicate. I'm going to document it here, in case anybody else runs into a problem where it seems like compression should be working, but isn't. Don't do this unless you find compression isn't working even after following the steps above.
Open the IIS admin tool, drill into your server, and right-click on "Web Service Extensions". Choose "Add a new web service extension". For the extension name, use whatever you want to identify it in the list (I used "HTTP Compression"). You need to add a single required file, which is \Windows\System32\inetsrv\gzip.dll, the ISAPI responsible for doing gzip and deflate compression. Check the "Set extension status to allowed", then click OK. You should have a new web service extension in your list called "HTTP Compression" (or whatever you named it), and it should have a status of "Allowed".
十、 服务器控件的ViewState
ViewState是asp.net中的一个特性，它用于把生成页面要用的一状态值保存在一个隐藏域中。当页面被回传到服务器时，服务器要解析，校验和应用ViewState中的数据以还原页面的控件树。ViewState是一个非常有用的特性，它能持久化客户端的状态而不用cookie或者服务器的内存。大部分的服务器控件都是用ViewState来持久化那些在页面中与用户交互的元素的状态值。例如，用以保存用于分页的当前页的页码。
用ViewState会带来一些负面的影响。首先，它加大的服务器的响应和请求的时间。其次，每次回传时都增加了序列化和反序列化数据的时间。最后，它还消耗了服务器更多的内存。
许多的服务器控件很趋于使用ViewState，如众所周知的DataGrid，而有时候是没有必须使用的。默认情况下是允许使用ViewState的，如果你不想使用ViewState的话，你可以在控件或页面级别把关闭它。在控件中，你只要把EnableViewState属性设为False就可以了；你也可以在页面中设置，使它的范围扩展到整个页面中：
如果页面无需回传或者每次请求页面只是呈现控件。你就应该在页面级别中把ViewState关掉。
