ASP.NET海量访问的处理经验分享

IIS给我们开放了平台，我们不再需要用复杂的socket去解析客户端的http请求，而且IIS他本身提供了一套完善的，处理海量链接的方案。

 

 

不过据我所知，很少人使用了ＩＩＳ的高级功能或者使用第三方服务去优化海量链接，大部分程序员对于Web开发都是单进程模式，没有任何缓存的开发，大部分系统的处理能力都非常有限。

 

其实要做到处理海量链接，也不是一件容易的事。在这里我分享一下我的少许经验。IIS里面，对于站点和对于虚拟目录，都可以指定相应的应用程序池。不同的站点，不同的虚拟目录，对于不同的应用，特别是访问量巨大的，最好设置不同的应用程序池。

 

应用程序池很多人都可以设，但是要用好，也不是一件容易的事。在这里我重点讨论一下应用程序池的第二个选项里面的Web园。在Web园的选项里面可以将应用程序池设置成多进程，这样就可以大大提高IIS的处理能力。

 

Web园也的确很多人会设，但是设置了Web园之后，程序架构上出现的问题，这是我讨论的重点。由于Web程序里面的static和session这些变量是保存在进程里面的，但是进程却是应用程序的最后边界。设置了多进程的web后，static和session这些变量的值就会有可能丢失了。比如处理a页面的进程设置了一个static或者session变量，当打开b页面的时候，有可能读得到，也有可能读不到，因为处理b页面的时候IIS可能已经启动另一个进程去处理这个页面了。

 

在这种情况下，对于session变量，asp.net提供了一个完善的解决方案。只要在配置文件里面

设置一下<sessionState mode="StateServer"></sessionState>，然后到系统服务里启动asp.net status server这个服务就可以了。

 

但是，static类型变量的处理就没有那么简单了。static很有用，只要有完善的内存及时释放机制，可以将处理的中间结果保存在static变量里面，就例如一个数据查询服务，第一次访问的时候执行查询，将结果保存在static变量里面，假如数据量很多的，客户端就可以异步分页来加载，第二次访问的时候直接读static变量，不需要再执行占cpu很高的数据查询和分析操作了。

 

可是，由于设置了多进程，static类型不再可用了，那么解决办法是什么呢？其实我们可以再建一个windows service或者web service程序，假如是建windows service, IIS可以通过remoting将数据保存到windows service里面，windows service负责保存这个数据，然后给IIS返回一个ＩＤ，然后ＩＩＳ将这个ＩＤ返回给客户端，以后客户端假如想去取数据，就不用再到数据库里去取了，直接使用这个ID post给IIS，IIS再使用remoting到windows service取这个中间结果；假如是建web service，那么不能和原来的web应用程序同一个应用程序池，而且这个保存状态数据的web service的应用程序池只能设成单进程。然后对外的web应用程序和这个web service打交道，处理方法和windows service的一样，其实和asp.net status 服务的原理也一样的。

 

这样就可以在多进程的web程序里面保存状态数据了，web性能得到大大的提升。我做过一个每秒钟要处理数百个请求的系统，假如只有单进程的IIS，w3wp.exe的线程数是越来越多，处理不过来，结果最后会崩溃的，后来我使用了这种方法，w3wp.exe进程出现了多个，而且每个进程的线程数不会越来越多，很好的处理了海量链接的请求。