性能优化

ASP.NET性能优化

c# 方面

string stringbulider  (toupper  ==  .length)

避免不必要的对象创建例如在循环中中创建对象，会引起垃圾回收机制

避免装箱拆箱（泛型  list dictinoary）

readonly  const 

避免两次类型转换 is contain  as 

以引用方式传递值类型参数

缓存数据

返回数据  take first

tryget

页面方面

页面的自动连接事件，

 js css 压缩

 服务器控件的ViewState 

页面缓存

资源文件服务器分离

jss css 最好干净

当浏览器在请求一个Web页面是从URL开始的。下面就是过程描述：

　　　　1． 输入URL地址或者点击URL的一个链接

　　　　2． 浏览器根据URL地址，结合DNS，解析出URL对应的IP地址

　　　　3． 发送HTTP请求

　　　　4． 开始连接请求的服务器并且请求相关的内容（至于请求时怎么被处理的，我们这里暂时不讨论，只是后面的文章要讨论的问题）

　　　　5． 浏览器解析从服务器端返回的内容，并且把页面显现出来，同时也继续进行其他的请求。

 

当获得了IP地址之后，那么浏览器就向服务器发送HTTP的请求，下面我们就稍微看下这个发送请求是怎么样被发送的：

　　　　1．    浏览器通过发送一个TCP的包，要求服务器打开连接

　　　　2．    服务器也通过发送一个包来应答客户端的浏览器，告诉浏览器连接开了。

　　　　3．    浏览器发送一个HTTP的GET请求，这个请求包含了很多的东西了，例如我们常见的cookie和其他的head头信息。

 

　　这样，一个请求就算是发过去了。

数据库方面
返回多个数据集 
使用sp
建立索引
sql 语句优化
对数据进行分页 

连接池

dataset datareader

数据页

分区表 sqlbulkcopy 表值参数

row number

四、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中增加一更强的条件，就是数据库条件。当数据库中的数据发生变化时，就会强制清除缓存　　 

五、预请求缓存 

　　在前面，我们只对某些地方作了一个小小的性能改进也可以获得大的性能提升，用预请求缓存来提升程序的性能是很不错的。 

　　虽然Cache API设计成用来保存某段时间的数据，而预请求缓存只是保存某个时期的某个请求的内容。如果某个请求的访问频率高，而且这个请求只需要提取，应用，修改或者更新数据一次。那么就可以预缓存该请求。我们举个例子来说明。 

　　在BS的论坛应用程序中，每一个页面的服务器控件都要求得到用于决定它的皮肤（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层要尽量少的使用这种技术，以减少进程中线程的数量，或者只让请求用一小部分的线程。当然如果你有大量的异步工作的话，那就只能用它了。 

七、页面输出缓存和代理服务 

　　Asp.net是你的界面层（或者说应该是），它包含页面，用户控件，服务器控件（HttpHandlers 和HttpModules）以及它们生成的内容。如果你有一个Asp.net页面用来输出html，xml,imgae或者是其它的数据，对每一个请求你都用代码来生成相同的输出内容，你就很有必要考虑用页面输出缓存了。 

只要简单的把下面的这一行代码复制到你的页面中就可以实现了：

<%@ PageOutputCache VaryByParams=”none” Duration=”60” %> 

就可以有效的利用第一次请求里生成的页面输出缓存内容，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是最好的一个。



1. C#语言方面


1.1.2 不要使用空析构函数 ★
　如果类包含析构函数，由创建对象时会在 Finalize 队列中添加对象的引用，以保证当对象无法可达时，仍然可以调用到 Finalize 方法。垃圾回收器在运行期间，会启动一个低优先级的线程处理该队列。相比之下，没有析构函数的对象就没有这些消耗。如果析构函数为空，这个消耗就毫无意 义，只会导致性能降低！因此，不要使用空的析构函数。
　在实际情况中，许多曾在析构函数中包含处理代码，但后来因为种种原因被注释掉或者删除掉了，只留下一个空壳，此时应注意把析构函数本身注释掉或删除掉。
　1.1.3 实现 IDisposable 接口
　垃圾回收事实上只支持托管内在的回收，对于其他的非托管资源，例如 Window GDI 句柄或数据库连接，在析构函数中释放这些资源有很大问题。原因是垃圾回收依赖于内在紧张的情况，虽然数据库连接可能已濒临耗尽，但如果内存还很充足的话，垃圾回收是不会运行的。
　 C#的 IDisposable 接口是一种显式释放资源的机制。通过提供 using 语句，还简化了使用方式（编译器自动生成 try ... finally 块，并在 finally 块中调用 Dispose 方法）。对于申请非托管资源对象，应为其实现 IDisposable 接口，以保证资源一旦超出 using 语句范围，即得到及时释放。这对于构造健壮且性能优良的程序非常有意义！
为防止对象的 Dispose 方法不被调用的情况发生，一般还要提供析构函数，两者调用一个处理资源释放的公共方法。同时，Dispose 方法应调用 System.GC.SuppressFinalize(this)，告诉垃圾回收器无需再处理 Finalize 方法了。


1.4 类型系统
　1.4.1 避免无意义的变量初始化动作
　CLR保证所有对象在访问前已初始化，其做法是将分配的内存清零。因此，不需要将变量重新初始化为0、false或null。
　需要注意的是：方法中的局部变量不是从堆而是从栈上分配，所以C#不会做清零工作。如果使用了未赋值的局部变量，编译期间即会报警。不要因为有这个印象而对所有类的成员变量也做赋值动作，两者的机理完全不同！
　1.4.2 ValueType 和 ReferenceType


　1.4.2.2 为 ValueType 提供 Equals 方法
　 .net 默认实现的 ValueType.Equals 方法使用了反射技术，依靠反射来获得所有成员变量值做比较，这个效率极低。如果我们编写的值对象其 Equals 方法要被用到（例如将值对象放到 HashTable 中），那么就应该重载 Equals 方法。public struct Rectangle
{
public double Length;
public double Breadth;
public override bool Equals ( object ob)
{
if (ob is Rectangle)
return Equels ((Rectangle)ob))
else 
return false ;
} 
private bool Equals (Rectangle rect)
{
return this .Length == rect.Length && this .Breadth == rect.Breach;
} 
} 

1.6 反射
　反射是一项很基础的技术，它将编译期间的静态绑定转换为延迟到运行期间的动态绑定。在很多场景下（特别是类框架的设计），可以获得灵活易于扩展的架构。但带来的问题是与静态绑定相比，动态绑定会对性能造成较大的伤害。
　1.6.1 反射分类
　 type comparison ：类型判断，主要包括 is 和 typeof 两个操作符及对象实例上的 GetType 调用。这是最轻型的消耗，可以无需考虑优化问题。注意 typeof 运算符比对象实例上的 GetType 方法要快，只要可能则优先使用 typeof 运算符。
　member enumeration ： 成员枚举，用于访问反射相关的元数据信息，例如Assembly.GetModule、Module.GetType、Type对象上的 IsInterface、IsPublic、GetMethod、GetMethods、GetProperty、GetProperties、 GetConstructor调用等。尽管元数据都会被CLR缓存，但部分方法的调用消耗仍非常大，不过这类方法调用频度不会很高，所以总体看性能损失程 度中等。
　member invocation：成员调用，包括动态创建对象及动态调用对象方法，主要有Activator.CreateInstance、Type.InvokeMember等。
　1.6.2 动态创建对象
　C#主要支持 5 种动态创建对象的方式：
　　1. Type.InvokeMember
　　2. ContructorInfo.Invoke
　　3. Activator.CreateInstance(Type)
　　4. Activator.CreateInstance(assemblyName, typeName)
　　5. Assembly.CreateInstance(typeName)
　最快的是方式 3 ，与 Direct Create 的差异在一个数量级之内，约慢 7 倍的水平。其他方式，至少在 40 倍以上，最慢的是方式 4 ，要慢三个数量级。
　1.6.3 动态方法调用
　 方法调用分为编译期的早期绑定和运行期的动态绑定两种，称为Early-Bound Invocation和Late-Bound Invocation。Early-Bound Invocation可细分为Direct-call、Interface-call和Delegate-call。Late-Bound Invocation主要有Type.InvokeMember和MethodBase.Invoke，还可以通过使用LCG（Lightweight Code Generation）技术生成IL代码来实现动态调用。
　从测试结果看，相比Direct Call，Type.InvokeMember要接近慢三个数量级；MethodBase.Invoke虽然比Type.InvokeMember要快三 倍，但比Direct Call仍慢270倍左右。可见动态方法调用的性能是非常低下的。我们的建议是：除非要满足特定的需求，否则不要使用！
　1.6.4 推荐的使用原则
　模式
　　1． 如果可能，则避免使用反射和动态绑定
　　2． 使用接口调用方式将动态绑定改造为早期绑定
　　3． 使用Activator.CreateInstance(Type)方式动态创建对象
　　4． 使用typeof操作符代替GetType调用
　反模式
　　1． 在已获得Type的情况下，却使用Assembly.CreateInstance(type.FullName)


　1.7.1 循环写法
　 可以把循环的判断条件用局部变量记录下来。局部变量往往被编译器优化为直接使用寄存器，相对于普通从堆或栈中分配的变量速度快。如果访问的是复杂计算属性 的话，提升效果将更明显。for (int i = 0, j = collection.GetIndexOf(item); i < j; i++)
　需要说明的是：这种写法对于CLR集合类的Count属性没有意义，原因是编译器已经按这种方式做了特别的优化。
。



1.8 Hashtable
　Hashtable是一种使用非常频繁的基础集合类型。需要理解影响 Hashtable的效率有两个因素：一是散列码（GetHashCode方法），二是等值比较（Equals方法）。Hashtable首先使用键的散 列码将对象分布到不同的存储桶中，随后在该特定的存储桶中使用键的Equals方法进行查找。
　良好的散列码是第一位的因素，最理想的情况是每个不同的键都有不同的散列码。Equals方法也很重要，因为散列只需要做一次，而存储桶中查找键可能需要做多次。从实际经验看，使用Hashtable时，Equals方法的消耗一般会占到一半以上。

System.Object类提供了默认的GetHashCode实现，使用对象在内存中的地址作为散列码。我们 遇到过一个用Hashtable来缓存对象的例子，每次根据传递的OQL表达式构造出一个ExpressionList对象，再调用 QueryCompiler的方法编译得到CompiledQuery对象。以ExpressionList对象和CompiledQuery对象作为键 值对存储到Hashtable中。ExpressionList对象没有重载GetHashCode实现，其超类ArrayList也没有，这样最后用的 就是System.Object类的GetHashCode实现。由于ExpressionList对象会每次构造，因此它的HashCode每次都不 同，所以这个CompiledQueryCache根本就没有起到预想的作用。这个小小的疏漏带来了重大的性能问题，由于解析OQL表达式频繁发生，导致 CompiledQueryCache不断增长，造成服务器内存泄漏！解决这个问题的最简单方法就是提供一个常量实现，例如让散列码为常量0。虽然这会导 致所有对象汇聚到同一个存储桶中，效率不高，但至少可以解决掉内存泄漏问题。当然，最终还是会实现一个高效的GetHashCode方法的。
　以上介绍这些Hashtable机理，主要是希望大家理解：如果使用Hashtable，你应该检查一下对象是否提供了适当的GetHashCode和Equals方法实现。否则，有可能出现效率不高或者与预期行为不符的情况。


2.2 Connection
　数据库连接是一种共享资源，并且打开和关闭的开销较大。Ado.net默 认启用了连接池机制，关闭连接不会真的关闭物理连接，而只是把连接放回到连接池中。因为池中共享的连接资源始终是有限的，如果在使用连接后不尽快关闭连 接，那么就有可能导致申请连接的线程被阻塞住，影响整个系统的性能表现。
　2.2.1 在方法中打开和关闭连接
　这个原则有几层含义：
　　1. 主要目的是为了做到必要时申请和尽早释放
　　2. 不要在类的构造函数中打开连接、在析构函数中释放连接。因为这将依赖于垃圾回收，而垃圾回收只受内存影响，回收时机不定
　　3. 不要在方法之间传递连接，这往往导致连接保持打开的时间过长

这里强调一下在方法之间传递连接的危害：曾经在压力测试中遇到过一个测试案例，当增大用户数的时候，这个案例要比 别的案例早很久就用掉连接池中的所有连接。经分析，就是因为A方法把一个打开的连接传递到了B方法，而B方法又调用了一个自行打开和关闭连接的C方法。在 A方法的整个运行期间，它至少需要占用两条连接才能够成功工作，并且其中的一条连接占用时间还特别长，所以造成连接池资源紧张，影响了整个系统的可伸缩 性！

2.2.2 显式关闭连接
　Connection对象本身在垃圾回收时可以被关闭，而依赖垃圾回收是很不好的策略。推荐使用using语句显式关闭连接，如下例：using (SqlConnection conn = new SqlConnection(connString))
{
conn.Open();

} // Dispose is automatically called on the conn variable here


2.2.3 确保连接池启用
　Ado.net是为每个不同的连接串建立连接池，因此应该确保连接串不会出现与具体用户相关的信息。另外，要注意连接串是大小写敏感的。
　2.2.4 不要缓存连接
　例如，把连接缓存到Session或Application中。在启用连接池的情况下，这种做法没有任何意义。
　2.3 Command
　2.3.1 使用ExecuteScalar和ExecuteNonQuery
　 如果想返回像Count(*)、Sum(Price)或Avg(Quantity)那样的单值，可以使用ExecuteScalar方法。 ExecuteScalar返回第一行第一列的值，将结果集作为标量值返回。因为单独一步就能完成，所以ExecuteScalar不仅简化了代码，还提 高了性能。
　使用不返回行的SQL语句时，例如修改数据（INSERT、UPDATE或DELETE）或仅返回输出参数或返回值，请使用ExecuteNonQuery。这避免了用于创建空DataReader的任何不必要处理。
　2.3.2 使用Prepare
　当需要重复执行同一SQL语句多次，可考虑使用Prepare方法提升效率。需要注意的是，如果只是执行一次或两次，则完全没有必要。例如：
cmd.CommandText = "insert into Table1 ( Col1, Col2 ) values ( @val1, @val2 )";

cmd.Parameters.Add( "@val1", SqlDbType.Int, 4, "Col1" );
cms.Parameters.Add( "@val2", SqlDbType.NChar, 50, "Col2");

cmd.Parameters[0].Value = 1;
cmd.Parameters[1].Value = "XXX";
cmd.Prepare();
cmd.ExecuteNonQuery();

cmd.Parameters[0].Value = 2;
cmd.Parameters[1].Value = "YYY";
cmd.ExecuteNonQuery();

cmd.Parameters[0].Value = 3;
cmd.Parameters[1].Value = "ZZZ";
cmd.ExecuteNonQuery();


2.3.3 使用绑定变量 ★
　SQL语句需要先被编译成执行计划，然后再执行。如果使用绑定变量的方 式，那么这个执行计划就可以被后续执行的SQL语句所复用。而如果直接把参数合并到了SQL语句中，由于参数值千变万化，执行计划就难以被复用了。例如上 面Prepare一节给出的示例，如果把参数值直接写到insert语句中，那么上面的四次调用将需要编译四次执行计划。
　为避免这种情况造成性能损失，要求一律使用绑定变量方式。
　2.4 DataReader
　 DataReader最适合于访问只读的单向数据集。与DataSet不同，数据集并不全部在内存中，而是随不断发出的read请求，一旦发现数据缓冲区 中的数据均被读取，则从数据源传输一个数据缓冲区大小的数据块过来。另外，DataReader保持连接，DataSet则与连接断开。
　2.4.1 显式关闭DataReader
　 与连接类似，也需要显式关闭DataReader。另外，如果与DataReader关联的Connection仅为DataReader服务的话，可考 虑使用Command对象的ExecuteReader(CommandBehavior.CloseConnection)方式。这可以保证当 DataReader关闭时，同时自动关闭Connection。
　2.4.2 用索引号访问代替名称索引号访问属性
　从Row中访问某列属性，使用索引号的方式比使用名称方式有细微提高。如果会被频繁调用，例如在循环中，那么可考虑此类优化。示例如下：
cmd.CommandText = "select Col1, Col2 from Table1" ;
SqlDataReader dr = cmd.ExecuteReader();

int col1 = dr.GetOrdinal("Col1");
int col2 = dr.GetOrdinal("Col2");

while (dr.Read())
{
Console.WriteLine( dr[col1] + "_" + dr[col2]);
}


2.4.3 使用类型化方法访问属性
　从Row中访问某列属性，用GetString、GetInt32这种显式指明类型的方法，其效率较通用的GetValue方法有细微提高，因为不需要做类型转换。
　2.4.4 使用多数据集
　部分场景可以考虑一次返回多数据集来降低网络交互次数，提升效率。示例如下：
cmd.CommandText = "StoredProcedureName"; // The stored procedure returns multiple result sets.
SqlDataReader dr = cmd.ExecuteReader();

while (dr.read())
// read first result set

dr.NextResult();

while (dr.read())
// 


2.5 DataSet
　2.5.1 利用索引加快查找行的效率
　如果需要反复查找行，建议增加索引。有两种方式：
　1. 设置DataTable的PrimaryKey
　适用于按PrimaryKey查找行的情况。注意此时应调用DataTable.Rows.Find方法，一般惯用的Select方法不能利用索引。
　2. 使用DataView
　适用于按Non-PrimaryKey查找行的情况。可为DataTable创建一个DataView，并通过SortOrder参数指示建立索引。此后使用Find或FindRows查找行。

3.1 减少往返行程（Reduce Round Trips）
　使用下面的方法可以减少Web服务器和Browser之间的往返行程：
　1. 为Browser启用缓存
　如果呈现的内容是静态的或变化周期较长，应启用Browser缓存，避免发出冗余的http请求。 

2. 缓冲页面输出
　如果可能，则尽量缓冲页面输出，处理结束后再一次传送到客户端，这可以避免频繁传递 小块内容所造成的多次网络交互。由于这种方式在页面处理结束之前客户端无法看到页面内容，因此如果一个页面的尺寸较大的话，可考虑使用 Response.Flush方法。该方法强制输出迄今为止在缓冲区中的内容，你应当采用合理的算法控制调用Response.Flush方法的次数。

3. 使用Server.Transfer重定向请求
　使用Server.Transfer方法重定向请 求优于Response.Redirect方法。原因是Response.Redirect会向Broswer回送一个响应头，在响应头中指出重定向的 URL，之后Brower使用新的URL重新发出请求。而Server.Transfer方法直接是一个简单的服务端调用，完全没有这些开销！
　需要注意Server.Transfer有局限性：第一，它会跳过安全检查；第二，只适用于在同一Web应用内的页面间跳转。
3.6 页面处理
　1. 尽量减小Page的尺寸
　包括缩短控件的名称、CSS的class的名称、去掉无谓空行和空格、禁用不需要的ViewState
　2. 启用页面输出的缓冲区（Buffer）
　如果Buffer的机制被关闭，可以用下面的方法打开。
　使用程序打开页面输出缓存：
　Response.BufferOutput = true;

使用@Page开关打开页面输出缓冲机制：
　<%@ Page Buffer = "true" %>

使用Web.config或Machine.config配置文件的<pages>节点：
　<pages buffer="true" …>
　3. 利用Page.IsPostBack优化页面输出
　4. 通过分离页面的不同的内容，来提高缓存效率和减少呈现的时间 
　5. 优化复杂和代价较大的循环 
　6. 合理利用客户端的计算资源，将一些操作转移到客户端进行