25

We are about to deploy a bunch of sites to some new servers. I have the following questions about application pools:

  1. It seems advisable to have one application pool per website. Are there any caveats to this approach? Will one application pool hog all the CPU, Memory, Etc...?

  2. When should you allow multiple worker processes in an application pool? When should you not?

  3. Can private memory limit be used to prevent one application pool from interfering with another? Will setting it too low cause valid requests to recycle the application pool without getting a valid response?

  4. What is the difference between private and virtual memory limits?

  5. Are there compelling reasons NOT to run one application pool per site?

3
  • First question back to you: Are these web sites (ie: .htm/.js), or web applications (ie. .aspx / .php)? Oct 14, 2011 at 18:49
  • Mostly .Net 3.5 applications. One is a third-party PHP application. Oct 14, 2011 at 18:58
  • 1
    This is kind of a broad range of topics - The subject (and @CodingGorilla's answers) are interesting, but it might not be the best fit for SF's Q-and-A style
    – voretaq7
    Oct 14, 2011 at 19:14

2 Answers 2

20

1) It seems advisable to have an application pool per website. Are there any caveats to this approach? Can one application pool, for example, hog all the CPU, Memory, Etc...?

This is a pretty good approach; there aren't any good reasons that I can think of to have different "sites" (applications) share the same pool. Unless they need to share a single resource of some sort. One application could theoretically hog a lot of CPU or memory, but changing how the applications are pooled won't really affect this much.

2) When should you allow multiple worker processes in an application pool. When should you not?

This is best left alone, using the default settings. Unless you really know what you're doing this can actually negatively impact your website/application.

3) Can private memory limit be used to prevent one application pool from interfering with another? Will setting it too low cause valid requests to recycle the application pool without getting a valid response?

a) Theoretically

b) Yes setting it to lower can have negative effects. Again, unless you have specific needs, and know what you are doing, just leave these alone.

4) What is the difference between private and virtual memory limits?

That's very complicated, here's a quick post I found that might help: http://cybernetnews.com/cybernotes-windows-memory-usage-explained/

5) Are there compelling reasons NOT to run one application pool per site?

Again, only reason I can think of is if there is some sort of "shared resource" the multiple applications need, then you would want to run them in the same process.

For general purpose applications and websites, IIS is pretty well set up with it's default values.

****UPDATE****

In regards to your request for additional information on #2, you shouldn't do this unless you have a specific need to do so. Even with server actions that take a long time, requests are served up using multiple threads, and you would want to use "Async Requests" to handle long running tasks (which frees up a thread pool thread to handle other requests). Realistically, I can't think of any good reason to allow multiple processes for the a single pool.

Once you're start talking multiple processes, then you potentially run into things like: losing session state because a session is alive in process 1, but the request is being handled by process 2. Or even worse, you have to figure out how to do some inter-process communication, which is a real pain.

No matter what you come with in regards to a reason for multiple processes, I would be willing to bet there is a better way to deal with it (rather than firing up another process).

8
  • I appreciate the thoughtful answer, and have accepted it. If you have any more specific information to #2, I'd appreciate it. "Best left alone" is certainly sage advice, but when to use multiple worker processes would be good to know as well. I assume this is more relevant when you have some server actions that take a long time to return a response, like a big report, web service that accepts large posts, and the like. I also assume all the normal thread concurrency stuff applies? Oct 15, 2011 at 0:20
  • Just to add: if you expect your apps to play poorly together, the installation dialog for IIS notes that Windows System Resource Manager can be installed and used to constrain CPU and memory use by app pools.
    – TristanK
    Oct 15, 2011 at 10:51
  • @TristanK, thank you for the tip. That was immensely helpful. Oct 18, 2011 at 16:38
  • @Coding Gorilla - Thanks again for the insight. I decided to do some serious digging into "why use a web garden" and came up with several responses. All the caveats you mentioned apply, in particular dealing with asynchronous access to shared resources like various caches and user sessions. The web garden feature essentially just lets you load balance requests on a single server with more than on core. So, you have to deal with all the caveats you normally deal with in a load balanced scenario, except for routing the requests. Oct 18, 2011 at 16:40
  • @Coding Gorilla - Continued... The best "reason" I found to use the multiple worker process feature is to increase performance. Check out this link: iis-aid.com/articles/performance_testing/…. Of course, you had better know what you are doing with all the asynchronous aspects of programming that we often neglect to take into account with websites, since most of them (at least to begin with) run a single worker thread. So the short answer to my question is: Try it if you are having performance problems. Oct 18, 2011 at 16:42
4

I always configure a dedicated application pool for a web site. Low-cost web site hosting scenarios are where having a large number of sites per application pool makes sense.

The memory limits are really only primitive safety thresholds to prevent a site from consuming all system resources. Note that this is more of a potential issue on Windows 2008 R2 x64 than on IIS 6.0 x86, because x86 applications had a natural 2 GB memory ceiling. It is much easier on IIS 7.5 for an application with a memory leak to consume vast amounts of memory.

I'm also not a big fan of recycling application pools. If I have an application pool and I'm the only application running, if there is nothing wrong with our code, there is probably no need to recycle the app pool. And if there is a defect in the application, the ultimate appropriate action would be to fix the code.

2
  • Thanks for pointing out the 32bit cap on memory. I don't know how I forget these things. I also think the correct approach if you have an application defective enough to crash an app pool is to fix it, assuming you have access to the code. I appreciate the advice! Oct 15, 2011 at 0:17
  • We did some testing of our own. Running an application pool seems to have overhead of about 64K per app pool above running the applications all in the same application pool. That is over a sample period of 12 hours using performance monitor to monitor memory consumption. This was on a 64-bit server. I think that if this simple test turns out to be correct, then the resource cost of one app pool per application is basically negligible on modern hardware. Oct 18, 2011 at 16:45

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .