Tags

, , ,

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.

Sharing a web server between development teams is always [NOT] fun.  If a developer creates a web application on IIS that uses .Net 1.1 for example (not an uncommon occurance) and some other developer creates a web application on that same server but this second one uses .Net 2.0 (something becoming more common every day).  Odds are that the developers and even sometimes the network engineer or web master will allow the defaults to lull them into the false sense that it was an easy and straightforward task.The problem is that they both allowed the “Default Application Pool” to remain selected and now the second of these sites to load will crash IIS.

You can’t have two different versions of .Net loaded into the same process and Application Pool often (though not always) means the same process.

Your daily dose of geek