IIS 之 链接数、并发链接数、最大并发工做线程数、队列长度、最大工做进程数

1、IIS链接数

　　通常购买过虚拟主机的朋友都熟悉购买时，会限制IIS链接数，顾名思义即为IIS服务器能够同时容纳客户请求的最高链接数，准确的说应该叫“IIS限制链接数”。

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

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

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

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

　　不少人对链接数的概念认识都很模糊，现介绍以下：
　　[1] 浏览者访问站点，必需与站点经过TCP协议，创建链接。这个链接在从服务器上读取信息时存在，读取结束时，通常即自动关闭。因此，当一个页面已经彻底地显示在客户端的显示器上时，使用的链接也许已经关闭了。
　　[2] 每一个浏览者，访问某站点时，可能会占用1-3多个链接，这是由计算机自动处理的，这样作的目的是为了加快速度。因此，对于链接数为30的基础型主机而言，有时只能十几我的访问。
　　[3] 虽然服务器中能够规定每一个站点的最大链接数，但同时也存在服务器的总计最大链接数。因此，即便规定用户站点的最大链接数为不限，当服务器达到了最大链接数时，仍不能访问站点。而服务器的最大链接数通常在1000—2000。
　　注意：
　　[1] 这就是为何服务商勇于开出不限链接数的主机，本质上不是无限链接数的。
　　[2] 西部数码提供的主机，容许链接数均较高，通常能够知足用户需求。

　　在IIS（6.2版及以上版本）中  “点击网站”->“右击切换到功能视图”->“点击界面右侧的 ‘限制...’ 连接”->“编辑网站限制”

　　

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

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

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

2、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了）。

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

3、IIS最大并发工做线程数

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

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

　　多是：

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

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

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

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

　　暂不知道“IIS最大并发工做线程数”有无地方能够设置。

4、队列长度

　　最大并发链接数，影响了排队的数量，那么进一步影响排队数量的设置就是队列长度。

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

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

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

　　

　　那么实际状况只会有20个进入排队状态了，70（队列中的20-90）个请求也会马上返回“HTTP Error 503. The service is unavailable”，IIS 默认队列长度设置是1000，范围在10-65535 之间。

5、最大工做进程数

　　IIS 6.0 及之后容许将应用程序池配置成一个Web园（Web Garden）。每一个应用程序池的单一工做进程，可以大约承受30-50个左右的并发。

　　“应用程序池” → 找到网站的所属应用程序池 → 右键“高级设置...” → “进程模型” → “最大工做进程数”，默认值为1。

　　

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

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

　　一、 最大工做进程数值的设置依据

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

　　二、 session共享问题

　　若是网站没有用到session机制，则不会引起此问题。若是用到了session机制进行传值和保存数据，则须要考虑在应用程序池多个工做进程间进行session共享，防止出现session丢失的问题。此问题的解决措施见 Asp.Net 之 Session共享设置。

　　2.1 Asp.Net的Session共享设置

　　Asp.Net提供了如下几种Session保存机制，如表 1所示：Session保存方式

方式名称	存储方式	性能
Off	设置为不使用Session功能	无
InProc	设置为将Session存储在进程内，就是ASP中的存储方式，这是默认值	最高
StateServer	设置为将Session存储在独立的状态服务中。一般是aspnet_state.exe进程	性能损失10-15%
SQLServer	设置将Session存储在SQL Server中。	性能损失10-20%
Custom	自定制的存储方案	由实现方式肯定

　　在Asp.Net程序的web.config配置文件中对Session的保存方式进行设置。若是不显示指定Session的保存方式，默认使用InProc的方式保存，即Session由提供服务的工做进程保存。

　　为了提升IIS对高并发的支持，能够增长应用程序池的工做进程数，IIS会根据内置的调度算法，将用户的请求在多个工做进程间动态分配，若是搭建了服务器集群和负载均衡，则用户请求会在多台机器的多个工做进程间进行动态分配。在上述状况下，若是Session的保存方式依然为InProc，则用户请求在多个工做进程间切换时可能出现Session丢失的状况，致使请求失败或出错。

　　为解决上述为，须要将Session的保存方式设置为共享，即表 1中的“StateServer”、“SQLServer”或“Custom”方式。这几种方法中，“SQLServer”方式须要安装独立的SQLServer数据库，“Custom”方式须要自行实现相应的Session存储与检索过程，部署起来相对复杂，相对上述两种方式，“StateServer”方式在功能性和可实施性上最好，所以下文重点介绍此种Session共享机制。

　　2.2 “ StateServer ”设置步骤：

　　[1] 肯定StateServer服务器。若是只有一台WEB服务器，可指定当前服务器为StateServer服务器。若是存在多台服务器集群，可指定集群中的一台符合较轻的服务器做为StateServer服务器。

　　[2] 修改注册表，容许远程访问StateServer服务。可直接导入以下脚本。

　　端口默认为42424，可根据须要进行修改，下文均以42424为例。

　　[3] 打开【管理工具】-【服务】，找到“Asp.Net State Service”，点击右键，选择【属性】，如图 4所示：

　　[4]在弹出的【属性】窗口中，将【启动方式】改成“自动”，而后点击【启动】按纽启动服务，如图 5所示：

　　[5] 打开待修改网站主目录下的web.config配置文件，搜索找到“<sessionstate>”配置节点，若是不存在配置节点，则在“<system.web>”节点下新建“<sessionstate>”配置节点，并将节点属性修改成：
　　<sessionState mode="StateServer" stateConnectionString="tcpip=127.0.0.1:42424" />
　　其中“tcpip=*”后的主机IP地址和端口可根据实际状况修改。修改完后保存配置文件便可。

　　注意：

　　[1] Session中保存的自定义对象必须显示标记为可序列化“[serializable]”。若是未显示标记为可序列化，则在访问页面时会报错。

　　[2] StateServer服务器必须为Windows Server操做系统，如Windows Server 2003或Windows Server 2008。

　　三、 合理的资源回收机制

　　大多数应用系统都存在工做时间使用量高、非工做时间使用量低的状况，针对这种现象，在系统非忙时应合理的释放操做系统资源，所以，应合理设置应用程序池的【限制超时】和【回收时间间隔】属性。

6、总结

　　当不少请求同时到来的时候，IIS会根据【最大并发链接数】来判断是否有多余的请求，多余的请求直接返回503，而后再根据【队列长度】来判断是否有多余的请求排不了队，排不了队的也直接返回503。因此，如何设置【最大并发链接数】和【队列长度】，其实是有公式能够计算的：

　　最大并发链接数 = 队列长度 + IIS最大并发工做线程数

　　IIS的默认值对咱们网站并发处理能力的影响：

　　IIS默认的" 最大并发链接数 "为4294967295（42亿多），而" 队列长度 "默认值为1000。对于windows server版本的IIS，最大并发工做线程数可能几百（猜想，可能没有限制），按照这个默认值，那么IIS同时处理的请求数也就1000多。1000多这个数字才是IIS真正的并发处理能力，而这个能力跟咱们的代码没有关系。

　　哪些指标是评判咱们网站的处理能力的呢？最重要的指标可能莫过于" 每秒处理请求数 "（在性能分析器里面能够查看），这个数字也叫吞吐率。若是每一个请求处理速度很是快，那么那么网站吞吐率就大，吞吐率大那么支持的同时在线人数就大。若是要作秒杀，那就看你的秒杀相关的URL支持多大的吞吐率吧。

　　CPU的计算能力是如何影响网站的处理能力的呢？仍是那么多请求，若是CPU很强大，可以缩减每一个请求的处理时间，那必然会提升吞吐率。还有不少的请求，若是花在网络传输或者到数据库的传输时间比较多，这部分等待时间CPU是闲置的，若是可以提升CPU的利用率，也可能提升网站的处理能力，最充分的利用服务器的资源。若是不想改代码而想提升CPU利用率，能够在IIS的应用程序池中设置最大工做进程数（默认值为1），能够设置为10若是当前CPU利用率只有百分之几的话，调整这个数值须要特别注意每个工做进程是独立的应用程序，全局静态变量不共享。