- 讨论今天这个问题之前,我们先来看下浏览器公布的资源并发数限制个数,如下图
不难看出,目前主流浏览器支持都是最多6个并发
需要注意的是,浏览器的并发请求数目限制是针对同一域名的
意即,同一时间针对同一域名下的请求有一定数量限制。超过限制数目的请求会被阻塞,这就是很多网站专门解决这个问题的原因。
有的请求会持续很长时间,如果把 img, css, js… 都放到http://一个域名下面,其他请求就迟迟无法完成,浏览者看来就是『卡住了』。而把图片放到另一个域名之后,css和图片就可以并发请求了。
浏览器并发请求就简单说到这里,原文地址:https://www.zhihu.com/question/20474326
- 下面步入正题,在开发中我遇到一个和奇怪的问题,就是我们接入SSO之后,发现并发请求反而更慢,如图
前面是接入sso之后,后面是没接入sso的情况
后来,找sso那边的同事查问题,他给我发了一个地址 https://blog.csdn.net/littlewrong/article/details/48134535
以下为问题的原因
问:为了可以顺序访问Session的状态值,Session是否提供了锁定机制? 答:Session实现了Reader/Writer的锁机制: 当页面对Session具有可写功能(即页面有<%@Page EnableSessionState="True" %>标记),此时直到请求完成该页面的Session持有一个写锁定。 当页面对Session具有只读功能(即页面有<%@Page EnableSessionState="ReadOnly" %>标记),此时知道请求完成该页面的Session持有一个读锁定。 读锁定将阻塞一个写锁定;读锁定不会阻塞读锁定;写锁定将阻塞所有的读写锁定。这就是为什么两个框架中的同一个页面都去写同一个Session时,其中一个要等待另一个(稍快的那个)完成后,才开始写。
“写锁定将阻塞所有的读写锁定”,也就是说页面在EnableSessionState="True"的情况下没返回输出时,一直持着Session写操作,其他页面对Session的读操作必须等待,而asp.net的aspx页面默认是EnableSessionState="True",每个页面从请求开始至返回一直持着Session写操作,需验证页面必须读取Session值判断,这就是为什么需验证的页面请求被阻塞的原因。只要耗时页面(A页面)没有Session的写操作,也就不会阻塞其他页面的请求,于是修改A页面的EnableSessionState="ReadOnly",例如:<%@ Page Language="C#" AutoEventWireup="true"CodeFile="TBS_Monitor_List.aspx.cs"EnableSessionState="ReadOnly" Inherits="TBS_Monitor_List" %> ,问题解决。
也就是说,在无需对session进行写操作的页面,加上EnableSessionState="ReadOnly"属性,就不会造成Request阻塞的情况了。
这个是asp.net的解决方式,后来我又查了下MVC的解决方案,这里是随意找的一篇:https://blog.csdn.net/paolei/article/details/38052129
具体解决方案就是在 controller上打个[SessionState(SessionStateBehavior.ReadOnly)] 的标签,由于我的项目中没有对session进行写操作的地方,所有我在BaseController上打了标签,最终的结果就是问题解决了,亲测有效
|