ASP.NET应用中常见的潜在问题有哪些？

Jeff Prosise在《MSDN杂志》2006年7月期上的文章历数ASP.NET应用中常见的，容易出错，影响性能和扩缩性的潜在问题

Keep Sites Running Smoothly By Avoiding These 10 Common ASP.NET Pitfalls
http://msdn.microsoft.com/msdnmag/issues/06/07/WebAppFollies/

1。设置输出缓存的用户控件，如果用LoadControl动态装载，LoadControl返回对象属于PartialCachingControl类，其中的CachedControl也许并不存在，无法转换成原用户控件对象类

2。在 IIS 6.0 中，在设置kernel模式输出缓存的情形下，OutputCacheModule模块有时会保留缓存输出的Set-Cookie header，导致会话串门(cross-session)，即一个用户能看到其他用户的会话数据

具体参考KB文章
An ASP.NET page is stored in the HTTP.sys kernel cache in IIS 6.0 when the ASP.NET page generates an HTTP header that contains a Set-Cookie response
http://support.microsoft.com/kb/917072

或者禁止kernel模式输出缓存
<httpRuntime enableKernelOutputCache="false" />

具体参考
http://support.microsoft.com/kb/820129

3。 Forms 认证Ticket的存活时间。在ASP.NET 1.*中，在没有用编码设置的情形下，如果是持久保存，存活时间是50年，如果是非持久保存，存活时间是30分钟。这个问题在ASP.NET 2.0中已经解决，默认存活时间会用web.config里的设置。在ASP.NET 1.*中，只能用编码来解决，具体编码参考原文中的例子。

4。 View State，如果滥用的话，是无声的性能杀手，特别是DataGrids和GridViews等，应该设置EnableViewState=false，或者考虑通过更改LoadPageStateFromPersistenceMedium/SavePageStateToPersistenceMedium把View State放在服务器端。

5。如果使用SQL Server做会话状态服务器的话，默认情形下，每个请求会访问状态服务器2次，造成性能下降。解决方案是，在不用会话状态的页面里，设置

<%@ Page EnableSessionState="false" ... %>

在只读会话状态的页面里，设置

<%@ Page EnableSessionState="ReadOnly" ... %>

6。在ASP.NET 2.0应用中，如果在web.config里设置

<roleManager enabled="true" />

默认情形下，角色数据是不缓存的，如果角色管理器需要确认当前用户的角色的话，会访问数据库，导致性能下降，解决方案是设置把角色数据缓存在Cookie里(这个Cookie是加过密的)

<roleManager enabled="true" cacheRolesInCookie="true" />

7。Profile 特性持久化问题，在默认情形下，ASP.NET profile管理器使用XML持久机制持久化自定义Profile类，不保存这些类的私有成员，解决方案是把这些类标为[Serializable]或实现ISerializable ，这样profile管理器会使用binary serializer

8。过长的数据库查询或I/O操作会导致线程池的饱和，导致ASP.NET的性能下降。ASP.NET 2.0提供了异步网页(asynchronous page)机制来缓解这个问题。具体参考Jeff Prosise在《MSDN杂志》2005年10月期上的文章

Asynchronous Pages in ASP.NET 2.0
http://msdn.microsoft.com/msdnmag/issues/05/10/WickedCode/

9。<identity impersonate="true" /> 导致客户端用户的身份模拟，要慎用，避免用身份模拟(Impersonation)替代ACL授权。

10。别太有信心，多用Profiler剖析你的应用对数据库的访问情形。重视数据库的设计，认识到DataSet和DataAdapter对web应用也许并不合适，数据访问层要恰当设计，防止粗劣细分(poor factorization)，避免在相对简单的操作上浪费太多的CPU周期，导致性能下降