使用默认设置配置单个网站在IIS下运行，任务管理器中可以看到w3wp.exe的工作进程在运行。但是，IIS不只可以为单个工作进程运行。可以配置器使用多个进程，每个进程为一个或者多个网站处理请求，或者为同一网站处理请求（web园）。为同一组网站处理请求的一组IIS进程就是应用程序池AppPool，单个apppool可以支撑多个网站。
设置AppPool，Apppool默认情况下设置为每1740分钟（29个小时）回收一次。回收时，apppool中的进程会停止，然后以重叠的方式启动，所以不会有请求的丢失。回收有助于预防因为内存泄漏或者其他的资源泄漏导致的中断，或者因为应用程序的bug造成apppool中单个线程使用完所有的CPU,或者网络资源。但是，它也会给服务器带来额外的负载，影响性能和吞吐量。要避免不必要的中断用户操作，一种方法是将回收时间设置为每天网站的流量很低的特定时间，另外一种是根据处理特定数量的请求来配置回收。结合合适的负载均衡算法，比如根据每台服务器的连接数，可以防止所有服务器在同一时刻进行回收。
在同一个apppool内运行的网站会共享对这些进程可用的资源，比如线程池就是根据每个进程分配的。这也就是说如果某个网站的问题导致apppool进程崩溃或者充值，那所有使用该程序池的网站都会受到影响。web园是通过使用多个进程为同一个网站处理请求来降低这种风险，但是web园也导致了应用程序专用的所有内存在每个进程中都有重复的问题，包括用户模式的输出缓存。因此我们不推荐使用它，除非网站运行在单台服务器上，而不是采用负载均衡的配置，如果有足够的RAM，web园可以提供基本的荣誉，如果一个工作进程崩溃，其他进程也会继续处理请求。
考虑增加额外的程序池的主要原因的是有些网站需要和其他网站在正常运行时间或可靠性上有很大的不同，将应用程序隔离到各自的程序池中，有效的防止一个网站里的bug或中断导致其他网站出问题，因为在线程之间上下文切换比进程中的快，所有使用更多的进程也有性能的成本，通常建议每个CPU核心不要超过1～2个工作进程，可以减少上下文切换的开销，比如一个4核的CPU通常不应超过4～8个工作进程。
在win 2008中使用WSRM来辅助管理应用程序池之间的连接；合理的使用HttpModule和请求处理器组合进IIS的请求处理管道；使用log Parser在日志文件中查找http错误（使用了类似SQL的方式查询日志）；使用一直的URL来避免不必要的HTTP重定向；移除X-Powered-By、Server、ETag以及X-Aspnet-Version的HTTP头。启用静态和动态压缩，优化压缩配置，为压缩的内容启用缓存，可以使用编程的方式启用压缩，保持使用HTTP Keep-alive，使用虚拟目录缩短URL的长度，使用URL重写优化URL。
log Parser相关文章
http://blog.csdn.net/downmoon/article/details/4509513
http://support.microsoft.com/kb/910447
http://www.cnblogs.com/shanyou/archive/2011/06/06/2073427.html
http://www.cnblogs.com/shanyou/archive/2011/03/17/1987496.html