记一次IIS优化

        我们开发的一套设备状态监控系统，最近在公司内部关注的人突然增多，每天上午8:30-10:30访问量会增大，如果超过1000连接数，站点就无法正常访问，数据库访问正常，问题定位到了IIS问题。每次都是紧急重启IIS应用程序池，过几分钟又恢复正常循环往复，很是烦人，渐渐别人也对我们的系统的稳定性有些质疑。于是开始了漫长的试错过程。

        调优第一阶段，在网上找了很多资料说是调大队列长度65535，设置过期时间等等，满心欢喜，观察一下服务器状况，过了一天没有挂掉，第三天早上还在说是不是问题解决了，结果没过一小时又挂掉了，一声叹气，继续找资料试配置。

        调优第二阶段，队列长度参数已经设置过了，超过1000站点还是无法访问，问题依旧。于是想到增加进程数来增加并发处理的能力，于是把“最大工作进程数”设置为4，继续观察。结果站点登陆后说是无权限访问页面，明明在测试环境可能正常登陆，正式环境却提示无权限，权限都是在后台使用session验证。这次问题出在了IIS的“最大工作进程数”参数上，原来数量为1，session都在一个进程中，设置为4后，登陆时候session在第1进程中，中转其他页面时再去读取session时候可能是第2进程返回的数据，无法读取到1进程中session数据。赶紧把参数又设置回1。

        调优第三阶段，朝着怎样让IIS共享状态的方向调参。一个同事误打误撞，找到了会话状态相关的资料，这时候我感觉我们已经离解决问题非常近了。赶紧启用了ASP.NET State Service服务，又重新设置了最大工作进程数”为4，“状态服务器-连接字符串” tcpip=loopback:42424，再继续观察。

        转眼又到了下一周，一到办公室我就打开了服务器监控页面，看着平稳的数据，我的心放下了，这次服务器终于经受住了考验。这次曲折的IIS参数优化过程终于结束了。