你使用Response.Redirect吗?
搜索你的代码为“Response.Redirect”，并考虑更换与Server.Transfer的。这并不招致了一个新的请求成本，因为它避免了任何客户端重定向。
你不能总是简单地取代Response.Redirect调用Server.Transfer的调用，因为Server.Transfer使用一个新的处理程序在执行的处理程序阶段。Response.Redirect产生第二个请求。如果你需要不同的身份验证和授权，缓存，或其他运行时设备上的目标，这两个机制是不等价的。Response.Redirect导致一个额外的请求被发送到服务器。Response.Redirect也使得用户可见的网址。这可能需要在某些情况下，您要求用户书签的新位置。
你使用Page.IsPostBack?
检查在你的页面的逻辑使用Page.IsPostBack属性，以减少多余的处理，避免不必要的初始化成本。使用Page.IsPostBack属性有条件地执行代码，根据页面是否是响应服务器控件事件生成，或者它是否是首次加载。
你验证用户输入?
检查，验证用户输入客户端上，以减少服务器的往返行程。这也提供了更好的反馈给用户。出于安全原因，确保任何客户端验证与对应的服务器端验证赞扬。
你有没有制定明确和严格的真实?
确保您使用Option Strict和明确，以减少意外的后期绑定，当使用Visual Basic。NET中。
- <%@ Page Language="VB" Explicit="true" Strict="true" %>
这可以很容易地搜索，使用正则表达式的Findstr.exe进行文件。
- C:\findstr /i /s /r /c:"<%.*@.*page.*%>" *.aspx
- pag\default.aspx:<%@ Page Language="VB" %>
- pag\login.aspx:<%@ page Language="VB" %>
- pag\main.aspx:<%@ Page Language="VB" Explicit="true" Strict="true" %>
- ...
您已禁用调试?
检查你的Web.config文件，并确保调试设置为false 节和检查。aspx页，以确保调试设置为false。如果启用了调试，编译器不生成优化的代码和页面批次编译。您可以通过使用正则表达式的Findstr.exe进行文件。aspx页。
- C:\pag>findstr /i /r /c:"<%.*@.*page.*debug=.*true*.*%>" *.aspx
- login.aspx:<%@ page Language="VB" Debug="True" %>
- main.aspx:<%@ Page Language="c#" Debug="True" %>
您已禁用跟踪?
检查您的Web.config文件，以确保在部分禁用跟踪。另外，请检查你的。aspx页，以确保跟踪设置为false。您可以通过使用正则表达式的Findstr.exe进行文件。aspx页。
- C:\pag>findstr /i /r /c:"<%.*@.*page.*trace=.*true*.*%>" *.aspx
- login.aspx:<%@ page Language="VB" Trace="True" %>
- main.aspx:<%@ Page Language="c#" Trace="True" %>
你积极的超时吗?
设置超时积极相应调整。评估每一页，并确定一个合理的超时。默认页是在Machine.config执行超时属性指定超时90秒。服务器资源举行，直到请求被处理完全或执行时间，以较早者为准。在大多数情况下，用户不必等待这样一个长时间才能完成的请求。他们要么完全放弃请求，或发送一个新的请求，这进一步增加了服务器上的负载。
您使用视图状态?
使用下面的复习题，以评估您的应用程序如何有效地使用视图状态：
你禁用视图状态时，它不需要?
每一页的评估，以确定是否需要查看状态启用。视图状态会增加开销每个请求。开销包括增加页面发送到客户端，以及一个序列化和反序列化成本的大小。你不需要查看在下列条件下的状态：
页面不回自己的页面仅用于输出和不依赖于响应处理。
你的页面的服务器控件不处理事件，你有没有动态的或数据绑定的属性值(或他们是在每个请求的代码)。
如果你忽略的旧数据，并重新填充的服务器控制每次刷新页面。
您已经采取步骤，以减少您的视图状态的大小吗?
评估每一页的视图状态的使用。要确定一个页面的视图状态的大小，您可以启用跟踪，看看每个每个控制如何使用它。控制控制的基础上，禁用视图状态。
你使用服务器控件吗?
使用下面的复习题，检讨如何有效地你的ASP.NET应用程序使用服务器控件：
你使用服务器控件时，你不需要吗?
评估您的服务器控件的使用，以确定是否可以替换他们具有重量轻HTML控件或可能是静态的文本。你也许可以在下列情况下更换一个服务器控件：
在控制显示的数据是静态的，例如，一个标签。
你并不需要以编程方式访问在服务器端控制。
控制显示的是只读数据。
在回处理过程中不需要控制。
你有服务器控制的深层次吗?
服务器控件嵌套很深的层次复合的建设控制树成本。考虑呈现的内容自己使用Response.Write或建立一个自定义的控制，并呈现。要确定的控制和控制层次，使页面的跟踪。
您从您的ASPX页面访问数据吗?
大多数ASP.NET应用程序需要某种形式的数据访问。数据访问的性能和可扩展性问题发现一个共同的地方。审查以下问题，以帮助改善您的应用程序的页面级别的数据访问：
你页大的结果集?
确定您的应用程序领域，大的结果集显示和考虑分页的结果。大的结果集显示给用户，可以对性能有显著影响。
你使用数据集时，你可以使用DataReaders吗?
如果你不需要缓存数据，层与层之间或数据的交换数据绑定到一个控制和只需要只进，只读访问数据，然后使用DataReader，而不是。
您可以使用数据绑定吗?
使用下面的复习题，审查代码的数据绑定使用：
你用的Page.DataBind吗?
避免调用的Page.DataBind和单独的每个控件绑定优化您的数据绑定。调用的Page.DataBind递归调用上的每个页面上的控件的DataBind。
你使用的DataBinder.Eval吗?
DataBinder.Eval的使用反射，从而影响性能。在大多数情况下，DataBinder.Eval的被称为从一个页面内多次，因此，实施替代方法提供了一个很好的机会，以提高性能。
避免以下做法：
- <itemtemplate>
- <table><tbody><tr>
- <td><%# DataBinder.Eval(Container.DataItem,"field1") %></td>
- <td><%# DataBinder.Eval(Container.DataItem,"field2") %></td>
- </tr></tbody></table>
- </itemtemplate>
使用显式转换。它提供了更好的性能，避免反射的成本。投作为一个DataRowView Container.DataItem，如果数据源是DataSet。
- <itemtemplate>
- <table><tbody><tr>
- <td><%# ((DataRowView)Container.DataItem)["field1"] %></td>
- <td><%# ((DataRowView)Container.DataItem)["field2"] %></td>
- </tr></tbody></table>
- </itemtemplate>
投作为一个String Container.DataItem如果数据源是一个数组或一个ArrayList。
- <itemtemplate>
- <table><tbody><tr>
- <td><%# ((String)Container.DataItem)["field1"] %></td>
- <td><%# ((String)Container.DataItem)["field2"] %></td>
- </tr></tbody></table>
- </itemtemplate>
aspx页面调用非托管代码吗?
使用下面的复习题，审查代码的互操作性使用：
你有没有启用调用STA COM组件ASPCOMPAT吗?
确保任何页面调用STA COM组件ASPCOMPAT页面级别属性设置。这将指示ASP.NET使用STA线程池线程来执行当前页面的请求。默认情况下，ASP.NET使用MTA线程池来处理页面请求。如果您正在使用STA元件，组件绑定到创建的线程。这将导致一个从线程池中的线程STA对象是创建的线程昂贵的线程切换。
你创建STA COM组件在页面的构造?
检查您的网页，以确保您没有创建STA COM组件在页面的构造。创建STA组件中的Page_Load，Page_Init或其他事件，而不是。页面的构造函数总是一个MTA线程上执行。当STA COM组件是从一个MTA线程创建，创建STA COM组件在主机上的STA线程。在同一个线程(主机STA)执行单元线程组件从MTA线程创建的所有实例。这意味着，即使所有的用户都有他们自己的COM组件实例的引用，所有到这些组件的调用序列化这一个线程，并在同一时间只有一个呼叫执行。这将有效地瓶颈一个单独的线程的页面，并造成重大的性能下降。如果您使用的是AspCompat属性，这些事件运行一个线程使用STA线程池，它在一个较小的性能结果击中由于线程切换。
你用Server.Create对象吗?
避免使用Server.CreateObject和早期绑定到您的组件在编译时尽可能。Server.CreateObject的使用后期绑定，主要是为了向后兼容提供。搜索您的代码库，看看是否使用这个例程，作为替代，创建互操作程序集，利用早期绑定的优势。
你有没有审查Machine.config中的设置吗?
使用下面的复习题，审查您的应用程序的部署计划：
调整适当的线程池?
CLR线程池调整适当的调整，提高了性能显著。在部署应用程序之前，确保该线程池已调整为您的应用程序。
适当配置的内存限制?
配置ASP.NET内存限制，确保最佳的ASP.NET缓存的性能和服务器的稳定性。在IIS 5.0中，或者当您使用在IIS 6.0的ASP.NET进程模型，配置Machine.config中的内存限制。在IIS 6.0中，您使用IIS MMC管理单元中配置的内存限制。
你删除不必要的HttpModules?
包括的HttpModules，你不需要添加额外的开销ASP.NET请求处理。检查您已删除或注释掉在未使用的HttpModules 的Machine.config。