ASP.NET性能探秘：不能并发查询的客户体验

该文适合遇到如下问题或需求的人：

您的ASP.NET系统中有些ASPX页面有比较耗时的查询。几秒，几十秒，甚至是分钟级别的。

您的客户需要。支持同一个登陆用户能打开几个不同或相同的页面，进行同时查询（当然不考虑他几个页面中点击查询的那几秒钟）。

 

此时，您或您的客户可能发现了。一旦我第一次点击的查询页面中的查询比较耗时。后面的页面查询，刷新。都一直等待在那里。直到第一个页面完成查询。   而问题是，你后面点击的页面。可能根本不是复杂的查询。甚至是什么也没有输出的ASPX页面。

 

是不是很郁闷。感觉您的系统就像单线程系统一样。

 

 

在默认开发的项目中，一般都启用了SESSION（包括InProc或者数据库SESSION等）。IE等浏览器中，从第一窗口进行登陆后。基于这个窗口的页面打开的连接窗口（或者选项卡），都共享了其SessionID（一般是在Cookies中）。  所以这个用户登陆后的多个页面查询。都是基于同一个SessionID。 对于ASP.NET服务器来说。都是同一个Session对象。

 

为了维护Session中的数据安全。微软在asp.net中设计了直接把Session加锁。第一个页面不查完。不释放Session对象。 第2个页面即使没有什么耗时的操作，也只能等待。   这样能保证Session中的数据成员之间不会被覆盖和改写。后面的页面也不会破坏第1个页面中Session里面的数据。

 

可是这样就导致了。同一个用户不能同时查询耗时的功能，甚至是不能简单的页面。后面的请求一直做为队列排队着等待。  这是很不好的体验。用户很不满意。

 

因为大多数不同页面之间。除了读取少数几个Session数据。几乎不会破坏Session的完整性。  难道就因为微软这样的设计。我们就满意法子了满足客户需求了吗，有时候根本不是客户需求。连你自己想的那关都过不了。

 

此时我们可以关闭SESSION。配置web.config文件中

<sessionState mode="Off">

 

 

这样第一个页面没有查完。后面的页面也能马上进去查询了。页面之间不会影响了。但此时又带来了新问题。 大部分系统都需要SESSION来标示用户会话。  如果没有SESSION。怎么解决这个问题呢？

 

 

这里提供一个建议：  自己实现一套SESSION机制。并在你Page的代码中隐藏原来Session属性改为你自己设计的Session。

protected new NewSession Session; // 实现你的SESSION。可以通过cookie存SessionID。并隐藏内置的SESSION public override void ProcessRequest(HttpContext context) { Session = CreateSession(Context); base.ProcessRequest(context); }

 

 

你的SESSION对象。实现和默认SESSION一样的基础方法。 这样可以不改变原来SESSION方式的情况下。以最少代码量改进你的系统。

 

下面给一个简单的自定义SESSION对象。某些细节还需完善。但基本能代替Page中默认的Session对象了。不要使用全局的Context.Session对象。

 

/// <summary> /// 自定义Session。 代替默认SESSION对象。 默认SESSION会影响同一个客户端用户的并发 /// </summary> public class CSession { /// <summary> /// SESSION 数据对象 /// </summary> private static readonly Dictionary<string, CSession> SessionData = new Dictionary<string, CSession>(); private string mSessionID; private Hashtable data = null; /// <summary> /// 获取SessionID /// </summary> public string SessionID { get { return mSessionID; } } /// <summary> /// 获取或设置数据项 /// </summary> /// <param name="index"></param> /// <returns></returns> public object this[int index] { get { lock (data) { int i = 0; foreach (object key in data.Keys) { if (i == index) { return data[key]; } i++; } } return null; } set { lock (data) { int i = 0; foreach (object key in data.Keys) { if (i == index) { data[key] = value; return; } i++; } if (i != index) { throw new Exception("index not find"); } } } } /// <summary> /// 获取或设置数据项 /// </summary> /// <param name="key"></param> /// <returns></returns> public object this[string key] { get { lock (data) { if (data.ContainsKey(key)) { return data[key]; } } return null; } set { lock (data) { if (data.ContainsKey(key)) { data[key] = value; return; } data.Add(key, value); } } } /// <summary> /// 移除当前用户SESSION中的数据项 /// </summary> /// <param name="key"></param> public void Remove(string key) { if (data != null) { lock (data) { data.Remove(key); } } } /// <summary> /// 移除当前用户SESSION /// </summary> public void Abandon() { lock (SessionData) { if (SessionData.ContainsKey(SessionID)) { SessionData.Remove(SessionID); } } } /// <summary> /// 创建SESSION /// </summary> /// <param name="context"></param> /// <returns></returns> public static CSession CreateSession(HttpContext context) { CSession session = null; string SessionID = null; if (context.Request.Cookies["SessionID"] != null) { SessionID = context.Request.Cookies["SessionID"].Value; } else { SessionID= Guid.NewGuid().ToString(); HttpCookie cookie = new HttpCookie("SessionID", SessionID); cookie.Path = "/"; cookie.HttpOnly = true; //cookie.Expires = DateTime.Now.AddMinutes(20); context.Response.Cookies.Add(cookie); } lock (SessionData) { if (SessionData.ContainsKey(SessionID)) { session = SessionData[SessionID]; } else { session = new CSession(); session.mSessionID = SessionID; session.data = new Hashtable(); SessionData.Add(SessionID, session); } } if (!context.Items.Contains("CSession")) { context.Items.Add("CSession", session); } return session; } }

 

 

问题并没有完全解决。 微软那样做是有道理的。 直接排队使用SESSION。可以让你的代码中不用考虑线程安全操作SESSION。因为同一时间同一个SESSION用户只能同时处理一个页面的逻辑。

 

现在没有这个限制了。但是SESSION中的数据。线程安全就需要你自己去考虑。 这部分您需要自己考虑同一份SESSION数据两个页面中对其同时读写迭代等的影响。   但大部分系统大部分逻辑中。不同的页面SESSION之间很少有冲突。即使少部分页面之间有冲突。  相信您肯定有自己的办法了。

 

如果有，也欢迎您的分享。