.Net application pools

Why it is a bad idea to isolate ASP.Net applications by using Application Pools.

1. ASP.Net applications all require the .Net Framework, which is a fixed overhead (in the neighborhood of at least 20MB RAM) paid by every process that loads an ASP.Net application. Suppose you have 10 ASP.Net applications. If each application is in its own Application Pool, you can have up to 10 copies of the .Net Framework loaded in memory by each w3wp.exe of each Application Pool. Efficiency says that you really only need one copy of the .Net Framework for all of the ASP.Net applications, and this is possible only if all 10 ASP.Net applications are in the same Application Pool.

2. ASP.Net applications do not benefit from Application Pool based isolation (by process identity) because ASP.Net runs managed code, which already has CAS and does NOT rely on user identity nor process space for isolation. AppDomain is the logical concept that is enforced by ASP.Net to isolate the ASP.Net applications. Of course, this is a different story for native code applications like ASP, ISAPI, CGI which do benefit from using process space for isolation.
Application pool is used to not affect the applications running in other application pools while errors in one application pool. It only affects current application pool. Modifying web.config will cause the application to restart. There is a difference between application pools and application. The application pool will consist of one or several worker processes and may host one or several applications. When application restarts, which doesn’t cause application pool to recycle, instead, it only restarts one of the applications hosted by the application pool.


Read More..