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

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周期,导致性能下降