IIS7、IIS7.5配置方案与负载均衡 多文合集【转载】

IIS 之 在IIS7、IIS7.5中应用程序池最优配置方案

　　找到Web站点对应的应用程序池，“应用程序池” → 找到对应的“应用程序池” → 右键“高级设置...”

　　

一、一般优化方案

　　1、基本设置

　　[1] 队列长度： 默认值1000，将原来的队列长度改为 65535。

　　[2] 启动32位应用程序：默认值False，改为True， 否则安装一些32的组建或32位的php都会出错。

　　[3] 托管管道模式：Integrated 或 Classsic。 

　　

　　2、高级设置

　　[1] 闲置超时（分钟）：默认20分钟，修改设长。

　　[2] 快速故障防护 → 已启用 ：默认True，改为False。 

　　

　　3、解决PEP第一次打开PEP速度慢

　　回收间隔时间

　　

　　使用windows server 2008 r2解决回收假死的问题

　　打开应用程序池 -> 高级设置 ->在“禁止重叠回收”里选择“true”，这样就有效避免了应用程序池回收假死问题。

　　

二、支持同时10万个请求

　　通过对IIS7的配置进行优化，调整IIS7应用池的队列长度，请求数限制，TCPIP连接数等方面，从而使WEB服务器的性能得以提升，保证WEB访问的访问流畅。

　　站点碰到如下问题：

　　Error Summary:

　　HTTP Error 503.2 - Service Unavailable
　　The serverRuntime@appConcurrentRequestLimit setting is being exceeded.

　　Detailed Error Information:

　　Module IIS Web Core 
　　Notification BeginRequest 
　　Handler StaticFile

　　Error Code 0x00000000

　　由于之前使用的是默认配置，服务器最多只能处理5000个同时请求，今天下午由于某种情况造成同时请求超过5000，从而出现了上面的错误。

　　为了避免这样的错误，我们根据相关文档调整了设置，让服务器从设置上支持10万个并发请求。

　　具体设置如下：

　　1. 调整IIS 7应用程序池队列长度

　　将原来的队列长度由默认值 1000 改为 65535。当然这里的队列长度你可以根据自己的 访问用户*1.5 来设置，例如：有2000用户，此处就可以设置为3000(3000=2000用户数*1.5）。

　　2.  调整IIS 7的appConcurrentRequestLimit设置

　　由原来的默认5000改为100000。

　　[1] 在cmd中执行：

　　c:\windows\system32\inetsrv\appcmd.exe set config /section:serverRuntime /appConcurrentRequestLimit:100000

　　[2] 在%systemroot%\System32\inetsrv\config\applicationHost.config中可以查看到该设置：

　　<serverRuntime appConcurrentRequestLimit="100000" />

　　

　　

　　3. 调整machine.config中的processModel>requestQueueLimit的设置

　　[1] 单击“开始”，然后单击“运行”，或者 windows + R。

　　[2] 在“运行”对话框中，键入 notepad %systemroot%\Microsoft.Net\Framework64\v4.0.30319\CONFIG\machine.config，然后单击“确定”。(不同的.NET版本路径不一样，可以选择你自己当前想设置的.NET版本的config)

　　[3] 找到如下所示的 processModel 元素：<processModel autoConfig="true" />

　　[4] 将 processModel 元素替换为以下值：<processModel enable="true" requestQueueLimit="15000" />

　　

　　[5] 保存并关闭 Machine.config 文件。
　　由原来的默认5000改为100000。

<configuration>
    <system.web>
        <processModel enable="true" requestQueueLimit="100000"/>

　　参考文章：http://technet.microsoft.com/en-us/library/dd425294(office.13).aspx

　　4. 修改注册表，调整IIS 7支持的同时TCPIP连接数

　　由原来的默认5000改为100000。在cmd中执行：

　　reg add HKLM\System\CurrentControlSet\Services\HTTP\Parameters /v MaxConnections /t REG_DWORD /d 100000

　　

　　可在注册表中查看

　　

　　5. 运行命令使用设置生效

　　net stop http  & net start  http & iisreset

　　完成上述5个设置，就可以支持10万个并发请求，博客园博客服务器已经启用上述设置。

　　为了方法大家与自己使用，我把上面能用bat操作简单放到一个bat文件里面了。将下面的内容保存为do.bat文件运行就可以了，需要手工的自己操作

 

三、支持高并发的IIS Web服务器常用设置 　　

　　适用的IIS版本：IIS 7.0, IIS 7.5, IIS 8.0

　　适用的Windows Server版本：Windows Server 2008, Windows Server 2008 R2, Windows Server 2012

　　1、应用程序池（Application Pool）的设置：

　　[1] General->Queue Length设置为65535（队列长度所支持的最大值）
　　[2] Process Model->Idle Time-out设置为0（不让应用程序池因为没有请求而回收）
　　[3] Recycling->Regular Time Interval设置为0（禁用应用程序池定期自动回收）

　　2、.Net Framework相关设置

　　[1] 在machine.config中将
　　< processModel autoConfig="true" />

　　改为

　　<processModel enable="true" requestQueueLimit="100000"/>

　　（保存后该设置立即生效）

　　[2] 打开C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config\Browsers\Default.browser，找到<defaultBrowser id="Wml" parentID="Default" >，注释<capabilities>部分，然后在命令行中运行aspnet_regbrowsers -i。以解决text/vnd.wap.wml问题。

 

　　设置命令：

　　c:\windows\system32\inetsrv\appcmd.exe set config /section:serverRuntime /appConcurrentRequestLimit:100000
　　设置结果：
　　< serverRuntime appConcurrentRequestLimit="100000" />

　　（保存后该设置立即生效）

　　4、http.sys的设置

　　注册表设置命令1（将最大连接数设置为10万）：
　　reg add HKLM\System\CurrentControlSet\Services\HTTP\Parameters /v MaxConnections /t REG_DWORD /d 100000

　　注册表设置命令2（解决Bad Request - Request Too Long问题）：

　　reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\HTTP\Parameters /v MaxFieldLength /t REG_DWORD /d 32768
　　reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\HTTP\Parameters /v MaxRequestBytes /t REG_DWORD /d 32768

　　(需要在命令行运行 net stop http  & net start http & iisreset 使设置生效)

　　5、针对负载均衡场景的设置

　　在Url Rewrite Module中增加如下的规则：

 

　　注意事项：添加该URL重写规则会造成IIS内核模式缓存不工作，详见微软的坑：Url重写竟然会引起IIS内核模式缓存不工作。

　　6、 设置Cache-Control为public

　　在web.config中添加如下配置：

<configuration>
 <system.webServer>
  <staticContent>
   <clientCache cacheControlCustom="public" />
  </staticContent>
 </system.webServer>
</configuration>

 

　　在machine.config的<processModel>中添加如下设置：

< processModel enable="true" maxWorkerThreads="100" maxIoThreads="100" minWorkerThreads="50" minIoThreads="50"/>

首先让我们来看看IIS里面的这2个数字：最大并发连接数，队列长度。先说这2个数字在哪里看。

 

最大并发连接数：在IIS中选中一个网站，右键网站名称，在右键菜单中找到并点击【管理网站】->【高级设置】。打开对话框如下图：

 

队列长度：在IIS中选中【应用程序池】，在应用程序池列表中，右键你想查看的，在右键菜单中选择【高级设置】。打开如下对话框：

 

这两个数字表面上看是影响我们站点的并发处理能力的，但是具体是如何影响一个网站的并发处理能力的呢？要完全理解IIS的并发处理能力，除了这2个数字，实际上还有一个非常关键的数字：IIS最大并发工作线程数。

 

1. IIS最大并发工作线程数

在以前很长一段时间，我一直以为IIS的【最大并发连接数】就是影响IIS最大并发工作线程数。我以为将【最大并发连接数】设置为1万，那么当1万个请求同时到来的时候，IIS会开启1万个线程进行处理，如果同时到来2万个请求，由于最大并发连接数只有1万，那么剩余1万个请求就会放在队列里面，当前面的1万个线程中某个完成了请求之后，再从队列里面取一个请求。但，这个理解是完全错误的，相信很多朋友也跟我有同样的理解。

 

现在，首先让我们来理解什么是【IIS最大并发工作线程数】。这个数字在IIS里面是没有界面进行设置的，我以前根本就不知道有这个数字。这个数字跟操作系统相关，我的win7系统的IIS的值是10，VS2012自带的IIS Express的值是80。对于windows服务器版本的系统的具体值是多少没有测试过，但我猜应该也是有限制的。

 

这个数字到底是什么意思呢？回到上面举的例子，当1万个请求同时进入IIS的时候，由于win7系统的IIS只有10个工作线程，那么这时1万请求中只有10个请求会在第一时间被处理，剩余9990个请求都需要排队。也就是说，IIS最多能够安排10个线程同时处理请求（win7版本的IIS，有的可能是20）。

 

所以，如果你用自己的win7系统测试IIS的性能的时候，你可能发现，不管你怎么设置【最大并发连接数】，你的IIS处理能力都很有限。

 

2. 最大并发连接数

上面讲的IIS最大并发工作线程数，看上去就是IIS的并发处理能力，如果是这样，那么【最大并发连接数】有什么意义呢？

 

还是上面的例子，如果1万个请求同时到来，而我们的win7系统的IIS最大并发工作线程数只有10，这时如果将【最大并发连接数】设置为100，会有什么效果呢？答案是：只有100个请求会收到正常响应，剩余9900个请求直接返回503（服务不可用）的错误。这时，实际上进入排队等待的只有90个请求。

 

再换下测试参数，如果将【最大并发连接数】设置为5000，又会有什么效果？答案你可能已经知道了，那就是一开始就有5000个请求直接返回503，剩下5000个请求慢慢正常返回。

 

这里你看明白了吧，【最大并发连接数】在我们的测试例子中，影响到了排队的数量。这样的话，看上去【队列长度】又不知道什么意思了？

 

3. 队列长度

在上面的例子中，如果1万个请求同时到来，【最大并发连接数】设置为100。这时我们知道，IIS首先会安排那10个线程去处理10个请求，剩下90个请求都需要排队。这时如果我们将【队列长度】设置为50，那会出现什么情况？答案是，40个请求会直接返回503服务不可用的错误（因为队列只有50个的长度，剩下的40个就无法排队了），最终只有60个请求会被正确处理。

 

读到这里，你明白了吗？

 

结论

当很多请求同时到来的时候，IIS会根据【最大并发连接数】来判断是否有多余的请求，多余的请求直接返回503，然后再根据【队列长度】来判断是否有多余的请求排不了队，排不了队的也直接返回503。所以，如何设置【最大并发连接数】和【队列长度】，实际上是有公式可以计算的：

 

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

 

最后再说说IIS的默认值对我们网站并发处理能力的影响。IIS默认的【最大并发连接数】为4294967295（42亿多），而【队列长度】默认值为1000。对于windows server版本的IIS，最大并发工作线程数可能几百（猜测，可能没有限制），按照这个默认值，那么IIS同时处理的请求数也就1000多。1000多这个数字才是IIS真正的并发处理能力，而这个能力跟我们的代码没有关系。那么哪些指标是评判我们网站的处理能力的呢？最重要的指标可能莫过于【每秒处理请求数】吧（在性能分析器里面可以查看），这个数字也叫吞吐率。如果每个请求处理速度非常快，那么那么网站吞吐率就大，吞吐率大那么支持的同时在线人数就大。如果要做秒杀，那就看你的秒杀相关的URL支持多大的吞吐率吧。了解了这么多指标，还没有涉及到CPU的计算能力。CPU的计算能力是如何影响网站的处理能力的呢？还是那么多请求，如果CPU很强大，能够缩减每个请求的处理时间，那必然会提高吞吐率。还有很多的请求，如果花在网络传输或者到数据库的传输时间比较多，这部分等待时间CPU是闲置的，如果能够提高CPU的利用率，也可能提高网站的处理能力，最充分的利用服务器的资源。如果不想改代码而想提高CPU利用率，可以在IIS的应用程序池中设置最大工作进程数（默认值为1），可以设置为10如果当前CPU利用率只有百分之几的话，调整这个数值需要特别注意每一个工作进程是独立的应用程序，全局静态变量不共享。

 

 

 

 

 

IIS负载均衡

 

春节将至，在此祝愿各位园友春节愉快！新年大吉！万事如意！！！

 

在大型Web应用系统中，由于请求的数据量过大以及并发的因素，导致Web系统会出现宕机的现象，解决这一类问题的方法我个人觉得主要在以下几个方面：

1.IIS 负载均衡。

2.数据库 负载均衡。

3.系统架构优化，比如报表服务器和应用服务器分开等。

本文主要介绍以下IIS负载均衡的实现方法，作者也是慢慢摸索的，如有不当之处还请各位大神指点以下，以求共同进步！！

 

演示环境介绍：

Server 1: 18.13 (用来分流的IIS服务器)。

Server 2: 18.49 (用来分流的IIS服务器)。

Server 3: 50.32 (用户所访问的服务器)。

 用来演示的网站：一个名为WebTest的网站，内容就是一张图片，足以达到演示效果。

安装Server Farms ,如下图所示：

整个安装步骤非常简单，跟着提示走即可，安装完成之后在IIS里面可以看到Server Farms的项目了，如下图所示：

 

现在我们通过Server Farms 来创建Server，如下图所示：

有多少个IIS服务器就创建多少个，我这里创建了2个，创建完成之后可以在“运行状态测试”中进行测试，如下：

Server Farms判断目标IIS服务器是否正常，是通过目标服务器里面的某一个文件返回的数据来判断的，具体配置如下所示，health.txt是用来作为验证的一个文件，里面的内容是OK，那么如果这个文件返回的数据是OK，Server Farms则会判断该服务器为正常状态，反之则不正常：

 

 

对于如何去平衡服务器的压力，Server Farms已经提供了一些算法，具体如截图所示，这里不做详细的介绍，大家有兴趣的话可以逐个测试一下，

 

两台IIS服务器验证成功，说明我们的配置是正确的，下一步我们来测试一下：我直接访问50.32服务器，这个时候呈现出来的页面是18.49这个服务器上面的图片。

 

 

OK,现在我将18.49这台服务器的IIS停止掉，如下图所示：

 

当18.49这台服务器的IIS停止以后，我们再次查看Server Farms里面的服务器状态，如下图所示：

 

当18.49挂了之后，我们再次访问50.32服务器，结果出来了：

 

结论：当配置了多台IIS服务器之后，根据我们定义的均衡规则和算法，它会自动为我们协调和分配当前的请求来达到分流的目的，上面的演示中，当18.49无法访问的时候，自动贝切换到了18.13服务器。

PS:虽然是不同的服务器，呈现出来不同的内容，这里我是为了便于查看效果，所以采用的不同的图片来显示，不然不容易区分。

 

 

有一个待解决的问题：不知道Session如何处理？欢迎讨论。

 

如果您觉得对您有用，烦请帮顶，感谢！！

 

如需转载，请注明出处，感谢！！

 

 

用 IIS 实现请求转发

 

最近部门要开发一个简单的APP，部分数据是现有项目已经存在的，为了方便维护，希望只提供一个交互的入口，并且协议的规则不变。

基于这个需求，有两套解决方案：

1.用代码将现有的api封装一层，对请求数据和返回数据不做任何改变，只是中转，然后和新的数据接口一起部署在一个项目里；

2.用IIS进行请求转发，调用现有接口回应请求，剩余部分开发新的api，部署在一个项目里，用URL Rewrite进行过滤分发。

第一个方案很传统，没什么好评价的，这里主要讲一下第二种方案的实现，第二个方案的好处是可以节省时间成本，需要依赖IIS插件（Application Request Routing + URL Rewrite）。

先下载ARR 和 URL Rewrite 进行安装，使用过程中发现ARR对IIS的“目录浏览”功能有依赖（未验证，如果无法使用，可以查看一下是否安装了“目录浏览”功能）：

http://www.iis.net/downloads/microsoft/application-request-routing#additionalDownloads

http://www.iis.net/downloads/microsoft/url-rewrite#additionalDownloads

安装好插件，重新打开IIS

 

双击IIS根目录

 

 

双击Application Request Routing Cache

双击右边的 Server Proxy Settings

 

 

勾上 Enable proxy

取消勾选“Reverse rewrite host in response headers”，否则所有的响应内容的host都会被重写为当前站点域名，简单来讲，最直接的影响就是对外部站点的重定向都会失败，所以这里取消勾选。

 

 

点击“应用”后，新建一个站点，用来接受请求做转发

 

 

双击站点，双击 URL Rewrite -> Add Rules(新建规则) -> Blank rule(空白规则) 

 

 

Name：填写你的规则名称

Match URL 是匹配Requested URL的规则

http://www.test.com?name=michael&age=30

host: www.test.com

requested url: ?name=michael&age=30

query string: name=michael&age=30

Requested URL 选择 Matches the Pattern （匹配符合规则的url）

Using 选择 Regular Expressions （使用正则表达式来匹配）

Pattern 里填写 ^(.*) 这里不对正则表达式做讲解，有需要的可以自己了解。

勾选 Ignore case 忽略大小写

 

 

展开 Conditions 条件筛选

Logical grouping 选择 Match Any

Match All 是列表中所有规则都要匹配才符合（与）

Match Any 是列表中有一个规则匹配就算符合（或）

track capture group across conditions 跟踪捕获组，这个功能跟正则有关，这里不需要不勾选，可以查询关键词 capture group  自行了解详情

 

 

点击 Add 添加条件 

Condition input 填写  {HTTP_HOST}  ，HTTP_HOST 代表请求头里的host，就是上面例子里的 www.test.com 部分， 更多可过滤条件查询 Server Variables  自行了解

Check if input string 选择 Matches the Pattern 

Pattern 填写 ^arrtest.com$  ，这里的意思是如果host是 arrtest.com 则匹配通过，例：http://arrtest.com?asdf=1234

如果这里填写的是 ^www.arrtest.com$  ，则匹配 http://www.arrtest.com?asdf=1234

勾选 Ignore case 忽略大小写

 

 

双击展开 Action 部分

Action type 选择 Rewrite 重写转发

Rewrite URL 里填写 https://cn.bing.com/{R:1} 转发目标地址， {R:1} 代表 Match URL 部分匹配到的 Request URL 

勾选 Append query string 追加查询字符串 

到此配置结束，保存这个规则，在浏览器访问 http://arrtest.com/search?q=测试 就等同于访问 https://cn.bing.com/search?q=测试  

 

为了防止该站点下的其他接口被这个规则无脑转发，我们需要新增一个转发条件

现有的需要转发的 API 格式如下 http://arrtest.com?PROTOID=123456 

其他接口是没有 PROTOID 这个关键词的，并且 PROTOID 后面的value都是数字，那么这里就用这个关键词来过滤需要转发的请求

再回到刚刚的 Conditions 部分，点 Add 新增条件

Condition input 填写 {QUERY_STRING} 

Check if input string 选择 Matches the Pattern

Pattern 填写 PROTOID=\d+ 这个规则的意思是，匹配查询字符串为 PROTOID 开头参数值为数字的请求（例：http://arrtest.com/?PROTOID=456789）

勾选 Ignore case 忽略大小写

确定保存，修改 匹配逻辑为 Match All （与），列表内所有的规则都匹配，请求才会通过

现在只有 QueryString 为 PROTOID 开头参数值为数字的请求才会被转发了

例子：http://arrtest.com/search?PROTOID=4564&q=测试   =>   http://cn.bing.com/search?PROTOID=4564&q=测试

http://arrtest.com/search?q=测试&PROTOID=4564  则不会被转发 

至此请求转发的功能就实现了，除此之外，强大的 ARR + URL Rewrite 还可以实现高可用负载均衡。