记一次WCF调优实战
最近单位的单点登录认证系统常常莫名其妙的宕机,这套系统使用asp.net 4.0的技术开发,部署环境为Windows Server 2008 R2 Enterprise IIS7.5。核心功能为使用WCF为其余应用提供登录认证和业务受权,一旦该系统没法正常运行单位其余系统都会出现没法登录的状况。web
问题描述,该系统出现问题时,WCF服务没法访问,同时经过IISRESET命令重启IIS时也会失败直接抛出以下异常服务器

经过查看服务器的配置发现该服务器硬件配置不错的,CPU Intel Xeon(R) E5620 2.4GHz 双处理器8核心,内存12GB,笔者分析单位的全部经过该系统进行认证和受权的其余系统结合单位任务2000人左右,该系统的最大并发度应该在1500左右,后来经过Windows的性能监视器分析发现系统的最大并发量在1560左右,平时的并发在100上下,如此配置的服务器按理彻底够用的。并发
WCF和IIS的可配性都很高,是否是相关的配置没有作优化形成的呢,先看一下WCF应用的配置,发现serviceThrottling的三个参数maxConcurrentCalls、maxConcurrentInstances和maxConcurrentSessions的配置值并不高分别为100,200,300。经过查询微软的网站发现,这三个参数配置决定了WCF服务的并发度,根据单位全部的系统和相关用户笔者将这三个值都设置为了5000。asp.net
<serviceThrottling maxConcurrentCalls="5000" maxConcurrentInstances="5000" maxConcurrentSessions="5000" />

在经过分析站点使用的IIS应用程序池发现,该认证系统和其余应用共享了同一个应用程序池切程序池的设置采用的时默认设置。首先将单点登录认证系统迁移至为其专门新建的应用程序池中,同时将应用程序池的配置作以下优化:性能
-
队列长度:有1000改成20000(最大能够设置为65535)优化
-
禁用重叠回收:设置为True网站
-
回收固定时间间隔:设置为0(不根据此项配置回收)spa
-
特定时间:设置为凌晨4:30(这样应用程序池回收不影响用户操做).net
-
设置超时:设置为0(空闲状态不回收)code
-
关闭快速故障防御
通过这么一番设置,系统的并发度和稳定度都有提升,最终效果还有待观察。