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文件中

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

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

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

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

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

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

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

猜你喜欢

转载自blog.csdn.net/zj53hao/article/details/5779768