IIS下Asp.Net应用程序多进程设置及Session共享

• 背景：

目前项目中在单个进程的应用程序经常会遇到w3c.exe崩溃的情况，于是就设想是否可以通过IIS多进程的方案来避免出现该问题。

于是搜了下“怎么实现多进程的方案”，找到了这篇文章：http://blog.csdn.net/anderslu/article/details/9040269。在此声明下，本文是参考该文章来写的。

• IIS下Asp.Net应用程序多进程设置：

打开iis管理器，找到"asp.net应用程"使用的“线程池”，右键在“属性”中找到“高级”,修改"最大工作进程数"（默认值为1），修改为32.

 

这样，就可以实现最大该asp.net应用程序可以同时启用32个并行进程。

 

注意事项：

1、最大并行进程数的值，需要设置一个合理范围的值。不能过大，可能会造成服务器资源耗尽；需要评估单个进程占用的最大资源数，之后合理的去设置该值；

2、设置了并行多进程后，asp.net应用程序的session在多个进程之间默认是不能实现共享的；

3、合理的去设置资源自动回收时间：合理设置【限制超时】和【回收时间间隔】属性值。

• Asp.Net应用程序多进程下实现Session共享：

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

表 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共享机制。

设置步骤：

1、cmd下运行services.msc打开“服务”窗口，找到“ASP.NET状态服务”服务项，修改属性为自动启动。

2、修改注册表: [HKEY_LOCAL_MACHINE/SYSTEM/ControlSet001/Services/aspnet_state/Parameters]
  设置 AllowRemoteConnection = 1 , 设置 Port = 42424 (十进制,默认即为42424)
  AllowRemoteConnection ,0仅能本机使用,1可以供其他机器使用.
  Port是服务的端口号

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

 

 

注意事项

 

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

2、 StateServer服务器必须为Windows Server操作系统，如Windows Server 2003或Windows Server 2008。

 

• 备注：

本文参考http://blog.csdn.net/anderslu/article/details/9040269，而且通过了测试。