ASP.NET2.0性能全面优化技巧--(笔记)

 ASP.NET性能概述

一，执行时间
       处理一个请求所需的时间，通常按服务器向客户端返回的第一个字节和最后一个字节之间的时间计算。执行时间直接影响吞吐量的计算。

二，响应时间
       从提出请求到服务器将第一个字节返回客户端之间的时间长度。对于客户端用户，这通常是性能中最直观的一个方面。如果应用程序响应时间很长，用户可能会觉得不耐烦，并转到另一个站点。应用程序的响应时间的改变与吞吐量的速率无关（甚至成反比）。

三，可伸缩性
       用于衡量应用程序在获取更多资源（内存、处理器或计算机）时更好地执行的能力。它经常按吞吐量相对于处理器数的更改速率计算。

四，吞吐量
       Web 应用程序在单位时间之内可以处理的请求数，经常以每秒请求数衡量。吞吐量可根据应用于服务器的加载（客户端线程数）而不同。这通常被视为要优化的最重要的性能度量。

优化技巧

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

2，尽量使用客户端脚本
       虽然您很可能希望尽量多地使用Web 窗体页框架的那些节省时间和代码的功能，但在某些情况下却不宜使用ASP.NET 服务器控件和回发事件处理。通常，只有在检索或存储数据时，您才需要启动到服务器的往返过程。多数数据操作可在这些往返过程间的客户端上进行。例如，从HTML窗体验证用户输入经常可在数据提交到服务器之前在客户端进行。通常，如果不需要将信息传递到服务器以将其存储在数据库中，那么您不应该编写导致往返过程的代码。

3，使用Page.IsPostback避免对往返过程执行不必要的处理。。
A， 如果您编写处理服务器控件回发处理的代码，有时可能需要在首次请求页时执行其他代码，而不是当用户发送包含在该页中的HTML 窗体时执行的代码。根据该页是否是响应服务器控件事件生成的，使用Page.IsPostBack 属性有条件地执行代码。
B，注意如果不运行这种检查，回发页的行为将不更改。Page_Load 事件的代码在执行服务器控件事件之前执行，但只有服务器控件事件的结果才可能在输出页上呈现。如果不运行该检查，仍将为Page_Load 事件和该页上的任何服务器控件事件执行处理。

4，在适当的环境中使用ASP.NET 服务器控件。
       检查您的应用程序代码以确保对ASP.NET服务器控件的使用是必要的。即使它们非常易于使用，但是服务器控件并不总是完成任务的最佳选择，因为它们会使用服务器资源。在许多情况下，一个简单的呈现或数据绑定代入就可以完成任务。

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

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

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

8，必要时调整应用程序每个辅助进程的线程数。
      ASP.NET 的请求结构试图在执行请求的线程数和可用资源之间达到一种平衡。已知一个使用足够CPU 功率的应用程序，该结构将根据可用于请求的CPU 功率，来决定允许同时执行的请求数。这项技术称作线程门控。但是在某些条件下，线程门控算法不是很有效。通过使用与ASP.NETApplications 性能对象关联的PipelineInstance Count 性能计数器，可以在PerfMon 中监视线程门控

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

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

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

12，只要可能，就缓存数据和页输出
      使用ASP.NET 缓存机制有两点需要注意。首先，不要缓存太多项。缓存每个项均有开销，特别是在内存使用方面。不要缓存容易重新计算和很少使用的项。其次，给缓存的项分配的有效期不要太短。很快到期的项会导致缓存中不必要的周转，并且经常导致更多的代码清除和垃圾回收工作。若关心此问题，请监视与ASP.NETApplications 性能对象关联的Cache TotalTurnover Rate 性能计数器。高周转率可能说明存在问题，特别是当项在到期前被移除时。这也称作内存压力。


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

14，根据适当的请求和响应编码设置来配置应用程序。
       ASP.NET 默认编码格式为UTF-8。如果您的应用程序为严格的ASCII，请配置应用程序使用ASCII 以获得稍许的性能提高。

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