踩坑
近日在对一个ASP.NET WEBFORM项目进行调优过程中,偶然发现页面POSTBACK事件是串行处理的,甚至不同页面的请求都是串行处理的(一个页面加载完毕后,才开始加载第二个页面)。但是网站明明是并发处理请求的啊,当时十分不解,把代码翻来覆去排查了大半天,寻找业务框架中什么地方是不是锁了资源。各种断点、调试、日志全部用上,还是找不到原因。
仔细思考了一下,ASP.NET肯定不会是串行处理的,难道是某一个Session中,ASP.NET对其串行处理请求?
排雷
在项目中新增一个页面,只能加最简单的事件代码:
log.Info("start");
System.Threading.Thread.Sleep(5000);
log.Info("end");
浏览器中开打两个标签页同时访问该页面,结果请求时并行处理的。
16:24:44[9]start
16:24:45[10]start
16:24:49[9]end
16:24:50[10]end
接着先访问下登陆页面,然后再重复上次动作,请求变成串行处理了!
16:26:11[9]start
16:26:16[9]end
16:26:16[10]start
16:26:21[10]end
换成两个浏览器,分别登陆后访问该页面,请求被并行处理。
自此确认肯定是SESSION的问题!
GOOGLE搜索了一番,找到原因及解决方案:
The session state module implements a locking mechanism and queues the access to state values. A page that has session-state write access will hold a writer lock on the session until the request finishes. A page gains write access to the session state by setting the EnableSessionState attribute on the @Page directive to True. A page that has session-state read access -- for example, when the EnableSessionState attribute is set to ReadOnly -- will hold a reader lock on the session until the request finishes.
原来SessionStateModule模块实现了一个写入锁,并对其进行排队处理,所以同一SESSION下的所有请求都会被串行执行。
解决方案也很简单,在页面上增加EnableSessionState="ReadOnly"指令即可。 当然,增加了这个指令后,这个页面也就不能修改SESSION值了。
衍生
GOOGLE的过程中,发现.NET MVC同样也有这个问题,其解决方案是在controller上增加特性[SessionState(SessionStateBehavior.ReadOnly)]
随手实验一番,不加以上特性时,在有SESSION的情况下,同SESSION的请求会被串行处理。增加SessionStateBehavior.ReadOnly后不同action中,请求会被并行处理,但是相同action仍然是串行处理的。
即使是Task<ActionResult>,任然无法逃脱串行执行的魔掌。
网友评论