Wishlist 0 ¥0.00

IIS应用程序池自动回收问题的解决办法

IIS可以设置定时自动回收,默认回收是1740分钟,也就是29小时。IIS自动回收相当于服务器IIS重启,应用程序池内存清空,所有数据被清除,相当于IIS重启,在快速开发平台服务器端,为了减小数据库负担,内存中暂存了很多信息,不适合频繁的回收,因为回收会造成服务器端所有存在内存中的数据丢失,如果没有及时保存到数据库中,可能导致程序出现问题。而如果系统使用高峰时期,并不适合回收,回收可能导致几十秒IIS无响应,对于正在工作的人员来说,是一种很不好的体验,会以为是网络或者掉线等问题。因此,基于以上的分析,我们需要设置IIS在指定的时间内定时回收。
      快速开发平台服务端需要正确的配置IIS(Internet Information Service)才能保证服务端可靠、稳定的运行,以给客户提供更好的用户体验。IIS为保护服务器资源,有一个应用程序池的回收功能,并且已经默认设置1740分钟回收一次(29小时),为了更好的设置该属性,我们有必要对IIS回收功能设置进行掌握,并根据应用的实际情况配合调整,以达到系统运行的最佳效果。
IIS应用程序池回收,找到相应的应用程序池并点击高级设置,就可以看到回收的相关设置(本文以windows2008R2下的IIS7为例,Windows2012类似)。

(图1) 

发生配置更改时禁止回收:如果为True,应用程序池在发生配置更改时将不会回收。
固定时间间隔(分钟):超过设置的时间后,应用程序池回收,为0意味着应用程序池不会按固定间隔回收。系统默认设置的时间是1740(29小时)。
禁用重叠回收:如果为true,将发生应用程序池回收,以便在创建另一个工作进程之前退出现有工作进程。
请求限制:应用程序池在回收之前可以处理的最大请求数。如果值为0,则表示应用程序池可以处理的请求数没有限制。
生成回收事件日志条目:每发生一次指定的回收事件时便产生一个事件日志条目,里面的明细设置不一一介绍。

    根据平台服务端配置情况看,IIS默认设置的1740分钟回收进程的策略并不合理,因为每1740分钟回收,在过程中可能就处于用户使用系统的高峰时段,为避免可能在高峰时段引起非可控问题,我们建议在每周六深夜(例如晚上1点,2点)进行IIS回收。

    如果我们在IIS应用程序池的高级设置中,进行回收设置,那么只有两种方式进行,一种是固定时间间隔,一种是手动回收。固定时间间隔设置,并不太好在深夜设置,以保证每周周六深夜执行回收。我们推荐采用windows “任务计划程序”配置一个操作系统定时任务执行脚本程序来实现IIS回收,设置方便,也可以灵活调整。 要通过脚本执行IIS的功能,需要在IIS安装配置的时候,勾选上管理工具中的“IIS管理脚本和工具”(见下图)。

用vbs脚本及批处理文件,结合任务计划程序,保证在每周六深夜1点执行IIS回收。

Recyclepool.vbs 文件内容:

appPoolName = WScript.Arguments(0)

Set oWebAdmin = GetObject("winmgmts:root\WebAdministration")

Set oAppPool = oWebAdmin.Get("ApplicationPool.Name='" + appPoolName + "'")

oAppPool.Recycle

set fso=createobject("scripting.filesystemobject")

if (fso.fileexists("d:\appPool\recycleIISPool.log")) then

   '1-forreading,2-forwriting,8-appending

   set file=fso.opentextfile("d:\appPool\recycleIISPool.log",8,ture)

else

   set file=fso.createtextfile( "d:\appPool\recycleIISPool.log",8,ture)

end if

'write(x)写入x个字符,writeline写入换行,writeblanklines(n)写入N个空行

file.writeline  now&" 应用程序池“"&appPoolName &"”已经回收成功。"

file.close

Recyclepool.bat文件内容:

cscript D:\appPool\recyclepool.vbs platweb

 

用vbs脚本及批处理文件,结合任务计划程序,保证在每周六深夜1点执行IIS回收。

成功用windows计划任务解决IIS定时回收问题。

网站发布以后频繁不能访问,需要重启IIS服务才能正常工作的解决办法

公司的网站经常出现不能正常访问的情况,查找IIS的错误日志(C:\WINDOWS\system32\LogFiles\HTTPERR\httperr1.log)后发现,日志文件中大部分记录的信息都是:Timer_ConnectionIdle。

站点代码(站点用C#开发)中添加的记录错误日志的文件中出现的错误如下:

   at System.Threading.Thread.AbortInternal()
   at System.Threading.Thread.Abort(Object stateInfo)
   at System.Web.HttpResponse.End()
   at System.Web.HttpResponse.Redirect(String url, Boolean endResponse)
   at System.Web.HttpResponse.Redirect(String url)

   Thread was being aborted.

========================================================================================

   System.InvalidOperationException: Timeout expired.  The timeout period elapsed prior to obtaining a connection from the pool.  This may have occurred because all pooled connections were in use and max pool size was reached.
   at System.Data.ProviderBase.DbConnectionFactory.GetConnection(DbConnection owningConnection)
   at System.Data.ProviderBase.DbConnectionClosed.OpenConnection(DbConnection outerConnection, DbConnectionFactory connectionFactory)
   at System.Data.SqlClient.SqlConnection.Open()
   at CAccessDataClass.Open()

 

刚开始的解决办法都是重启IIS服务,网站恢复正常运行。

可后来问题频繁出现,甚至有时一天出现10几次以上,并且发现当w3wp.exe进程占用内存过多时,网站就会无法访问。

通过查找资料得出如下结论:

w3wp.exe进程是IIS中网站使用的应用程序池对应的进程。只要网站被访问就会在web服务器上启动一个网站的应用程序池对应的进程。

 

IIS6.0应用程序池回收和工作进程的相关介绍如下:

 

应用程序池是将一个或多个应用程序链接到一个或多个工作进程集合的配置。因为应用程序池中的应用程序与其他应用程序被工作进程边界分隔,所以某个应用程序池中的应用程序不会受到其他应用程序池中应用程序所产生的问题的影响。

为Web程序配置应用程序池需要以下步骤:1)创建应用程序池,右键单击“应用程序池”,“新建/应用程序池”,命名为KefuAppPool;2)为Web程序指定应用程序池,在网站虚拟目录属性“应用程序设置”里面的“应用程序池(N)”里选择KefuAppPool;3)应用程序池自动回收方式的设置。回收方式有如下几种:

a.根据运行时间

系统默认是1740分钟,也就是29个小时,这个不是很好控制,建议不用。

b.请求数目

这个要看具体的情况了。如果只有10个请求,可是有5个都在请求那个比较占资源的页面(可能是统计年度报表之类),这个时候就会出现进程当掉的情况,如果请求有1000个可是一个也没运行比较占资源的页面,这个时候进程肯定是很正常的,所以根据请求的数目来决定也不一定符合实际需要。

c.计划的时间

这个其实很好,不过具体什么时间回收好呢?通常我们都是设置在凌晨两三点钟,这个时候回收是有必要的,不过针对出现随时可能出现是高内存占用并不是很适用。

d.内存(虚拟内存或已使用的内存)

这个针对出现内存问题引起的进程当掉实在太合适了,不过设置多大的值比较好是一个很重要的问题,值不能太小了,否则如果访问量都很大超过这个值的时候也会自动回收,这个就很没必要了。一定要多多观察进程的实际占用情况再做决定。

下面重点谈谈对工作进程回收应用程序池的理解。

默认情况下,WWW服务建立“重叠回收”,即继续运行要终止的工作进程,直到启动新的工作进程后为止。 在重叠回收方案中,要回收的进程继续处理请求,同时 WWW 服务创建一个替代工作进程。在停止旧工作进程之前启动新的工作进程,然后将请求定向到新的进程。此设计可以防止服务中断,因为旧进程关闭前仍然保持与 HTTP.sys 的通信以处理请求。因为可重叠关闭或启动的关闭超时值是可以配置的,所以在工作进程仍在处理请求的同时可以终止该进程(如果它在时间限制内没有处理完请求的话)。

注意:当 WWW 服务回收某个工作进程时,它并不断开现有的 TCP/IP 连接。HTTP 协议堆栈 (HTTP.sys) 建立并维护 TCP/IP 连接。

IIS中的每个应用程序池由一个“工作进程”进行管理,也就是"W3wp.exe" 进程。如果有多个应用程序池中的程序运行,我们就能看到多个w3wp.exe。这点可以在任务管理器中看到,如下图所示,任务管理器中有两个w3wp.exe进程,恰好对应两个有应用程序在运行的应用程序池。

在命令提示符下运行iisapp -a,可以查看w3wp.exe和哪个应用程序池关联。

 

下图显示了手动执行应用程序池KefuAppPool的回收,在回收前,回收中和回收后应用程序池和工作进程情况。我们注意到:回收过程中增加了一个工作进程(PID=3896),该工作进程(PID=3896)启动好后,旧的工作进程(PID=5716)才被停止,新工作进程(PID=3896)正式替代旧进程工作,这就很好的防止了应用程序池回收过程中服务被中断,保证了程序的连续运行。而其他两个应用程序池对应的工作进程 PID都没用变。该图很好的展示了应用程序池回收的过程。

应用程序池这个东西着实让管理服务器的人头疼,如果不设置好网站随时有可能罢工,甚至拖累服务器。因此特地找来此文章供大家参考。

另外说一点,如果网站访问量不是很大,晚上没什么人访问,可以尝试凌晨重启服务器,这样可以提高服务器的速度,为第二天的访问做准备。

IIS 6的核心在于工作进程隔离模式,而应用程序池则是定义工作进程如何进行工作,因此,可以说应用程序池是整个IIS 6的核心。

和IIS 5中只能使用单个应用程序池不同,工作在工作进程隔离模式的IIS 6可以创建多个应用程序池,不同的应用程序池之间是完全隔离的,某个应用程序池停止服务时不会影响到其他应用程序池。

在使用应用程序池之前,你应该确定你所需要的应用程序池数量。可能有很多朋友会认为,既然不同的应用程序池之间是完全隔离的,那么我只需要为每个Web站点创建一个应用程序池就可以了。这个办法在IIS服务器上具有较少的Web站点数量时可以使用,但是如果IIS服务器上具有很多Web站点数量,那么这个办法就不适用了,因为不同的应用程序池在被访问时都会创建各自的工作进程,当大量的工作进程并发工作时会消耗大量的系统资源和CPU利用率,反而会降低服务器性能。你应该根据Web站点的重要性、隔离性、所运行代码的安全性和稳定性等来对IIS服务器上所具有的Web站点进行划分,然后根据情况来决定所需要的应用程序池数量。对于那些非常重要的Web站点、需要单独隔离的Web站点、所运行代码稳定性和安全性并不可靠的Web站点配置为使用各自独立的应用程序池,而将其他普通的Web站点配置为使用一个公共的应用程序池。

默认情况下,在安装IIS时会创建一个默认网站并创建一个名为DefaultAppPool的应用程序池为其使用;默认配置下的应用程序池已经可以很好的进行工作,建议你只有在特别需要时才对应用程序池进行配置。

配置应用程序池属性

在IIS管理控制台中展开应用程序池文件夹,然后右击对应的应用程序池,点击属性,你可以在应用程序池的属性中进行以下配置:

回收

在回收标签,你可以设置工作进程的回收方式:

回收工作进程(分钟):在工作进程运行多少分钟后回收工作进程,默认启用,并且设置为1740分钟(29小时);

回收工作进程(请求数目):在工作进程处理多少 个HTTP请求后终止此工作进程,默认禁用,如果启用则默认值为35000;

在下列时间回收工作进程:在指定的时间回收工作进程,默认禁用;如需启用,勾选后点击添加按钮添加回收的时间即可,使用24小时制定义回收的时间;

消耗太多内存时回收工作进程:

最大虚拟内存(兆):当工作进程使用的虚拟内存达到设置的值时回收工作进程,默认禁用,如果启用则默认值为500 M;建议设置为不超过虚拟内存总数的70%;

最大使用的内存(兆):当工作进程使用的物理内存达到设置的值时回收工作进程,默认禁用,如果启用则默认值为192 M;建议设置为不超过物理内存总数的60%;

另外需要注意的是,应用程序池具有以下两种工作进程回收方式,不过这两种回收方式均不会造成Web服务的中断:

默认情况下,应用程序池使用重叠回收方式。在这种方式下,当应用程序池要关闭某个工作进程时,会先创建一个工作进程,直到新的工作进程成功创建后才关闭旧的工作进程;

应用程序池也可以先关闭旧的工作进程,然后再创建新的工作进程。

如果Web 应用程序不支持多实例运行,那么你必须配置应用程序池禁止使用重叠回收方式。此配置无法在IIS管理控制台中进行修改,只能通过在 metabase.xml中修改对应应用程序池的DisallowOverlappingRotation metabase属性为true进行。

性能

在性能标签你可以设置工作进程的运行方式:

在空闲此段时间后关闭工作进程(分钟):当工作进程空闲多少分钟后关闭此工作进程,这降低了空闲工作进程对系统资源和CPU性能的消耗,默认启用并且设置为20分钟;

核心请求队列限制为(请求次数):当HTTP.sys接收到某个客户端发送的HTTP请求时,如果处理此请求的对应应用程序池的工作进程还处于忙状态,则HTTP.sys将接收到的请求保存在对应应用程序池的请求队列中,直到工作进程空闲为止。此选项即用于设置此应用程序池的请求队列所能容纳的请求数量,默认情况下每个应用程序池的请求队列限制为保留1000个请求,如果超出则向客户端返回503错误,你可以根据需要适当进行修改,最大可以设置为65535。但是如果设置太大则会消耗大量的系统资源 ,而设置太小会导致客户端访问时频繁出现503错误。

启用CPU监视:监视此应用程序池的CPU使用率,默认未启用;如果某个应用程序池占用的CPU利用率过多,那么可以通过配置此选项来限制此应用程序池;

最大CPU使用率(百分比):所设置的应用程序池所能使用的最大CPU使用率;启用CPU监视时默认值为100;

刷新CPU使用率(分钟):刷新CPU使用率的间隔时间;启用CPU监视时默认值为5;

CPU使用率超过最大使用率时执行的操作:当此应用程序池的CPU使用率超过所设置的最大CPU使用率时所进行的操作,启用CPU监视时默认为无,此时IIS只是在事件日志中进行记录而不进行其他操作;如果选择为关闭,那么IIS将关闭此应用程序池中的所有工作进程;

Web园:在Web园中你可以配置此应用程序池所使用的最大工作进程数,默认为1,最大可以设置为4000000; 配置使用多个工作进程可以提高该应用程序池处理请求的性能,但是在设置为使用多个工作进程之前,请考虑以下两点:

每一个工作进程都会消耗系统资源和CPU占用率;太多的工作进程会导致系统资源和CPU利用率的急剧消耗;

每一个工作进程都具有自己的状态数据,如果Web应用程序依赖于工作进程保存状态数据,那么可能不支持使用多个工作进程。

运行状况

在运行状况标签你可以配置应用程序池监视工作进程的运行状况,

启用Ping:默认情况下应用程序池配置为每隔30秒Ping工作进程,当工作进程没有进行响应时,则认为此工作进程出现故障并默认配置为关闭此工作进程。你可以修改Ping的时间间隔,但是太长的Ping间隔可能会导致Web服务的中断,而太短的Ping间隔又会消耗更多的系统资源和CPU利用率,因此建议你保留默认配置;

启用快速失败保护:如果Web应用程序代码编写有问题,它可能会导致工作进程持续出现问题。默认情况下应用程序池配置为启用快速失败保护,当工作进程在配置的时间段(默认为5分钟)内发生的失败次数超过了配置的值(默认为5次),则禁用此应用程序池。

启动时间限制:IIS等待属于此应用程序池的工作进程启动的时间,当工作进程启用时间超出此设置值时,IIS会在事件日志中进行记录;

关闭时间限制:当IIS检测到某个工作进程出现故障时,将此工作进程标记为关闭,此选项指定了IIS等待工作进程自动关闭的时间限制,如果超出此时间限制后工作进程尚未关闭,则IIS强行关闭工作进程。

标识

在标识标签,你可以配置工作进程所运行的用户账户。在IIS 5或者当IIS 6运行在IIS 5隔离模式时,工作进程运行在本地系统账户,而运行在工作进程隔离模式下的IIS 6的工作进程运行在网络服务账户下,这降低了系统被攻击的可能性。

你可以配置工作进程运行在预定义的本地系统、本地服务或网络服务账户下,也可以配置为使用某个自定义的用户账户。建议使用默认的网络服务账户;不过如果为了更高的安全性,可以配置使用自定义的用户账户,不过建议你只是将此自定义用户加入到IIS_WPG用户组中,因此IIS_WPG用户组包含了可以启动和运行工作进程的最小权限。

1)在任务管理器中增加显示pid字段;2)在命令提示符下运行iisapp -a。注意,第一次运行,会提示没有js支持,点击确定。然后再次运行就可以了。这样就可以看到pid对应的应用程序池。如上图左侧所示,应用程序池 KefuAppPool和PID=3232的w3wp.exe相关联,应用程序池ReportServer和PID=3572的w3wp.exe相关联.

IIS 之 功能详解

IIS (Internet Information Services)信息服务管理器,本文以Windows10环境下的IIS为例,主要包含:FTP 服务器、Web 管理工具、万维网服务三大部分,如下表所示:

IIS 启用默认 一级组成 启用默认 二级组成 启用默认 三级组成 启用默认 说明

Internet

Information

Services

不启用,需通过

“启用或关闭Windows功能”

来启用。

FTP 服务器  FTP 服务 -  - 在Web 服务器上启用 FTP 发布。
 FTP 扩展性 -  - 通过编写您自己的软件拓展名来自定义 FTP 发布。
Web 管理工具 部分  IIS 6管理兼容性  IIS 6 WMI兼容性  安装 IIS 6.0 WMI脚本接口。
IIS 6 管理控制台 安装 IIS 6.0 管理控制台,通过它可从本计算机管理远程IIS6.0服务器。
IIS 6 脚本工具 安装 IIS 6.0 配置脚本。
IIS6 元数据库和IIS6配置兼容性 安装 IIS 元数据库和兼容性层以允许元数据库调用与新 IIS 10.0配置存储区交互。
IIS 管理服务  -  - 允许通过 Web服务器管理控制台从另一台计算机远程管理Web服务器。
IIS 管理工具和脚本  -  - 使用 IIS 配置脚本管理本地 Web服务器。
IIS 管理控制台  -  - 安装 Web服务器管理控制台,它支持本地和远程Web服务器的管理。
万维网服务 部分 安全性 部分  IIS客户端证书映射身份验证  否 将客户端证书以1对1或多对1的形式映射到 Windows 安全标识。
 IP安全  否 基于IP 地址或域名来允许或拒绝内容访问
 URL授权 授权客户端访问包含 Web 应用程序的 URL
 Windows身份验证 使用 NTLM 或 Kerberos 对客户端进行身份验证
 基本身份验证 要求连接时提供有效的 Windows 用户名和密码
 集中式SSL证书支持 使您能够使用文件共享来集中管理 SSL 服务器证书。在文件共享上维护 SSL 服务器证书可简化管理,因为是在一个位置管理他们的。
 客户端证书映射身份验证 使用 Active Directory 账户验证客户端证书。
 请求筛选 配置相应的规则来阻止选定的客户端请求。
 摘要式身份验证  通过向 Windows 域控制器发送密码哈希来对客户端进行身份验证。
常见 HTTP 功能 部分  HTTP 错误 允许自定义返回客户端的错误消息。
 HTTP 重定向 将客户端请求重定向至特殊目标。
 WebDAV 发布 通过使用 HTTP 协议,在Web 服务器上发布和管理文件。
 静态内容 从网站上提供.htm、.html 和 图像文件。
 默认文档 允许指定当用户没有在请求 URL 中指定文件时将加载的默认文件。
 目录浏览 允许客户端查看您的 Web服务器上某个目录的内容。
性能功能 部分 动态内容压缩 先压缩动态内容,然后将其返回到客户端
静态内容压缩 在静态内容返回到客户端之前先对它进行压缩
应用程序开发功能 部分 .NET Extensibility 3.5 使您的Web服务器可以承载 .NET Framework 3.5 应用程序
.NET Extensibility 4.6 使您的Web服务器可以承载 .NET Framework 4.6 应用程序
ASP 使您的Web服务器可以承载经典的 ASP 应用程序
ASP.NET 3.5 使您的Web服务器可以承载  ASP.NET 3.5 应用程序
ASP.NET 4.6 使您的Web服务器可以承载  ASP.NET 4.6 应用程序
CGI 启用对 CGI 可执行文件的支持
ISAPI 扩展 允许 ISAPI 扩展处理客户端请求
ISAPI 筛选器 允许 ISAPI 筛选器修改 Web 服务器行为
WebSocket 协议 IIS 10.0 和 ASP.NET 4.6支持编写通过 WebSocket 协议通信的服务器应用程序
服务器端包含 服务器端包含
应用程序初始化 应用程序初始化
运行状况和诊断 部分  HTTP 日志  是 对此服务启用网站活动日志。
 ODBC日志记录 支持登录到符合 ODBC 的数据库。
跟踪 启用对 ASP.NET 应用程序和失败请求的跟踪。
请求监视器 监视服务器、站点和应用程序运行状况。
日志工具 安装 IIS 10.0 工具和脚本。
自定义日志 启用对Web服务器、站点和应用程序的自定义日志的支持。

 

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"/>

 

About Us

Since 1996, our company has been focusing on domain name registration, web hosting, server hosting, website construction, e-commerce and other Internet services, and constantly practicing the concept of "providing enterprise-level solutions and providing personalized service support". As a Dell Authorized Solution Provider, we also provide hardware product solutions associated with the company's services.
 

Contact Us

Address: No. 2, Jingwu Road, Zhengzhou City, Henan Province

Phone: 0086-371-63520088 

QQ:76257322

Website: 800188.com

E-mail: This email address is being protected from spambots. You need JavaScript enabled to view it.