你真的了解：IIS链接数、IIS并发链接数、IIS最大并发工做线程数、应用程序池的队列长度、应用程序池的最大工做进程数 吗？

IIS链接数

---

 

通常购买过虚拟主机的朋友都熟悉购买时，会限制IIS链接数，这边先从普通不懂代码用户角度理解IIS链接数

顾名思义即为IIS服务器能够同时容纳客户请求的最高链接数，准确的说应该叫“IIS限制链接数”

这边客户请求的链接内容包括：

一、网站html请求，html中的图片资源，html中的脚本资源，其余须要链接下载的资源等等,任何一个资源的请求即一次链接（虽然有的资源请求链接响应很快）

二、若是网页采用框架（框架内部嵌套网页请求），那么一个框架即一次链接

三、若是网页弹出窗口（窗口内部嵌套网页请求），那么一个窗口一个链接

 

虚拟主机供应商在IIS（6.2版本，如下全部截图均此版本）中  “点击网站”->“右击切换到功能视图”->“点击界面右侧的‘限制’连接”->“编辑网站限制”

 

限制链接数即为虚拟主机供应公开的IIS链接数标准，若是购买的IIS链接数为50,那么咱们不得不考虑网站的内容框架和访问量

若是网站图片够多，弹窗窗口随意（可能连时间选择框、简单条件筛选框也用弹出新窗口），加上不得已的打开新页面浏览内容，那么仅仅能容忍10我的同时操做也很正常，我不会把这个操做描述为不少网站说的“10同时在线”，这很容易让人误解，在用户的一次请求（表面上多是刷新一次网页，实际上内部请求不止一次，事实上不多只有一次）都完成获得服务器响应完毕以后，链接所有会被释放，固然在你看到展现的页面以前，内部嵌套若是有请求图片等链接请求，链接会早早的被释放

事实上，不少企业门户网站访问量低的惊人，IIS链接数为50也是绰绰有余了

这边给出更加详细参考连接：http://www.west263.com/info/html/IDCzixun/zhujizuyong/20080221/1677.html

 

IIS并发链接数

---

 

“管理网站”->“高级设置”->"限制"->"最大并发链接数"

其实，普通用户常说的“IIS连接数”就是这边的“最大并发链接数”，若是PC端有IIS的朋友，能够测试上面两个图片的设置，是相互影响的

这边默认最大并发链接数为：4294967295，这是一个很惊人的数字，难道这表明着网站能具备并发执行链接数为4294967295的能力？

这边我作几个假设：

一、不少虚拟主机供应商所说的无并发链接数限制真的成立吗？

二、每一个链接的处理，IIS都会开启一个线程去处理，假设这个处理方式成立，那么4294967295个并发链接请求来了是否IIS会当即启动4294967295个线程去处理？

 

对于1：很显然不成立，最大并发链接数的设置绝对有上限

对于2：这是不少朋友的误区，假设4294967295并发链接同时来了，IIS不会当即启动4294967295个线程去处理，由于这不现实，对于处理链接，IIS是有“最大并发工做线程数”限制的，这是我下面要介绍的，我从一些资料上查阅到，该数字跟操做系统相关，win7系统的IIS的值是10（或者其余不肯定），VS2012自带的IIS Express的值是80。对于windows服务器版本的系统的具体值不清楚，即4294967295个并发链接来了后，（这边以win7下的10为例），iis第一时间只能启动10个工做线程去处理，那么其余4294967285必须排队，排队对用户的体验来讲就是网页正在加载，可是什么都不显示，而后此时购买了据虚拟主机供应商所说的无并发链接数限制的客户就要开始狂暴了，为什么购买了所谓的“无限并发链接数”，仍是会一直在加载的状况，我只能说这就是IIS处理能力有限的问题了

 

固然服务器没有直接返回“HTTP Error 503. The service is unavailable.”应该也算是一些你花更多钱的安慰吧，由于你只购买了IIS链接数为50的话，那么第50+1个链接请求操做获得的就直接是“HTTP Error 503. The service is unavailable.”了

另外，若是web服务器的硬件设备够爽朗（牛逼），那么IIS的工做线程也会处理的更快，那么响应的用户等待的时间也会更短（前提是你的IIS链接数够大哦，不然就直接503了哦）

总的来讲，最大并发链接数，影响了排队的数量，

不少时候须要咱们评估本身的网站的最大并发链接数，而后来进行设置最佳数量

这边给出更加详细参考连接：

http://www.th7.cn/system/win/201407/63593.shtml

http://blog.csdn.net/shigaofei1/article/details/8222048

 

IIS最大并发工做线程数

---

 

这个在上面有所涉及，简单的说就是IIS在并发链接请求过来时的处理机制，它会更机智的以某个数量级为单位来分批处理，让没有处理链接请求排队等待，用户浏览器中对于排队等待的响应就是“正在加载”，这比页面直接显示“HTTP Error 503. The service is unavailable.”更加能让人接受，可是切勿气急败坏的怒点刷新按钮，由于点的越多，你的请求在排队队伍中越靠后。

固然不少朋友会说，为何我有时候第一次刷不出来，从新多刷一次内容就出来了，

多是：

一、页面脚本哪一个地方下载或者处理出了问题，致使页面显示异常或者直接不显示

二、你从新刷新的那个秒级别的操做，web服务器更快速的已经处理好了其余队列的请求或者他人放弃了对web服务器链接请求的操做

三、路由或者宽带网络运营商问题（不稳定）

四、浏览器或者自己电脑问题

我不知道“IIS最大并发工做线程数”有无地方能够设置，知道的朋友能够给我留言，谢谢

那么如今问题来了，最大并发链接数，影响了排队的数量，那么有没有进步影响排队数量的设置? 有的：队列长度

 

队列长度

---

 

假设最大链接数设置为100，1000个并发链接请求过来了，首先900直接返回给客户“HTTP Error 503. The service is unavailable.”

而后IIS先启动（假设最大并发工做线程数为10）10个线程处理请求，其余90个进入排队状态，若是此时以下操做：

找到网站的所属应用程序池，“右击高级设置”->"常规"->"列队长度"，设置为20

那么实际状况又会变成什么样子呢？只会有20个进入排队状态了，70（90-20）个请求也会马上返回“HTTP Error 503. The service is unavailable”

iis默认队列长度设置是1000，范围在10-65535 之间

 

最大工做进程数

---

 

IIS 6.0容许将应用程序池配置成一个Web园（Web Garden）

找到网站的所属应用程序池，“右击高级设置”->"进程模型"->"最大工做进程数"，默认1

若是这个值大于 1，那么当有链接请求时会启动多个新的工做进程实例，可启动的最多进程数为您所指定的最大工做进程数，后续更多的请求将以循环的方式发送至工做进程，这个每一个工做进程都能承担负载一些链接请求，固然是以消耗cpu等硬件作代价，这是值得的，若是web服务器cpu使用率很低可是又须要更高效的处理并发链接请求，为什么不这么作呢？

若是网站中用到了依赖进程的Session和Cache等对象，则不能保存在服务器内存中，存储方式选用StateServer或者SQLServer会更好，另外多个工做进程切换时会有上下文复制，这也是资源消耗更多地方

最大工做进程数的设置方法：（拷贝）按照每工做进程能承载30个并发的原则来肯定应用程序池的最大工做进程数。同时要注意，每一个工做进程大约会占用200M左右的系统内存，在设置最大工做进程数的时候，要主要最大工做进程数与200M的乘积不要超过系统最大可用内存数。通常状况下，建议按照每次增长5个工做进程数的方式对最大工做进程数进行调整，调整完后对网站观察一段时间，如依然没法知足要求，再继续增长5个工做进程数。

这边给出更加详细参考连接：

http://www.itmano.com/87.html

http://www.xuebuyuan.com/174816.html