ASP.NET性能优化方面的总结

  1

1.1

如果呈现的内容是静态的或变化周期较长，应启用Browser缓存，避免发出冗余的http请求。

1.2

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

1.3

使用Server.Transfer方法重定向请求优于Response.Redirect方法。原因是Response.Redirect会向Broswer回送一个响应头，在响应头中指出重定向的URL，之后Brower使用新的URL重新发出请求。而Server.Transfer方法直接是一个简单的服务端调用，完全没有这些开销！

需要注意Server.Transfer有局限性：第一，它会跳过安全检查；第二，只适用于在同一Web应用内的页面间跳转。

 

如果需要运行阻塞或长时间运行的操作，可以考虑使用异步调用的机制，以便Web服务器能够继续处理其它的请求。

2.1

只要有可能就要避免在请求的处理过程中对Web服务和远程对象的同步调用，因为它占用的是的ASP.NET 线程池中的工作线程，这将直接影响Web服务器响应其它请求的能力。

2.2

这种模式能让Web Server调用之后就立即返回。可根据实际情况决定是否使用这种方法。

2.3

将作业提交到服务器上的工作队列中。客户端通过发送请求来轮询作业的执行结果。

 

缓存能在很大程度上决定ASP.NET应用的最终性能。Asp.net支持页面输出缓存和页面部分缓存，并提供Cache API，供应用程序缓存自己的数据。是否使用缓存可考虑下面的要点：

3.1

3.2

3.3

3.4

3.5

 

4.1

在执行请求的过程中创建线程是一种代价较大的操作，会严重影响Web Server的性能。如果后续的操作必须用线程完成，建议通过thread pool来创建/管理线程。

4.2

由于执行请求的线程是ASP.NET thread pool中的工作线程，同一个Client的两次请求不一定由相同的线程来处理。

4.3

这和1的情况类似。异步调用会导致创建新的线程，增加服务器的负担。所以，如果没有并发的作业要执行，就不要执行异步调用。

 

5.1

5.2

5.3

5.4

 

6.1

包括缩短控件的名称、CSS的class的名称、去掉无谓空行和空格、禁用不需要的ViewState

6.2

如果Buffer的机制被关闭，可以用下面的方法打开。

使用程序打开页面输出缓存： Response.BufferOutput = true;

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

使用Web.config或Machine.config配置文件的<pages>节点：

<pagesbuffer="true" …>

6.3

6.4.

　6.5优化复杂和代价较大的循环

　6.6合理利用客户端的计算资源，将一些操作转移到客户端进行

 

ViewState是Asp.net为服务端控件在页面回传之间跟踪状态信息而设计的一种机制。

7.1

如果不需要跟踪页面状态，例如页面不会回传（PostBack）、不需要处理服务端控件事件或者每次页面刷新时都会重新计算控件内容，那么就不需要用ViewState来记录页面状态了。可以对特定的WebControl设置EnableViewState属性，也可以在页面一级设置：

<%@Page EnableViewState="false" %>

7.2

ASP.NET

7.3

放到ViewState中的内容会被序列化/反序列化，Asp.net为String、Integer、Boolean等基本类型的序列化做了优化，如果Array、ArrayList、HashTable存储的是基本类型效率也较高，但其它类型则需要提供类型转换器（Type Converter），否则将使用代价昂贵的二进制序列化程序。