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).
Recycling
Recycling is usually* where IIS starts up a new process as a container for your application, and then gives the old one up to ShutdownTimeLimit
to go away of its own volition before it's killed.
*- usually: see DisallowOverlappingRotation
/ "Disable overlapped recycle" setting
It is destructive, in that the original process and all its state information are discarded. Using out-of-process session state (eg, State Server or a database, or even a cookie if your state is tiny) can allow you to work around this.
But it is by default overlapped - meaning the duration of an outage is minimized because the new process starts and is hooked up to the request queue, before the old one is told "you have [ShutdownTimeLimit
] seconds to go away. Please comply."
Settings
To your question: all the settings on that page control recycling in some way. "Shutdown" might be described as "proactive recycling" - where the process itself decides it's time to go, and exits in an orderly manner.
Reactive recycling is where WAS detects a problem and shoots the process (after establishing a suitable replacement W3WP).
Now, here's some stuff that can cause recycling of one form or another:
- an ISAPI deciding it's unhealthy
- any module crashing
- idle timeout
- cpu limiting
- adjusting App Pool properties
- as your mum may have screamed at one point: "Stop picking at it, or it'll never get better!"
- "ping" failure * not actually pinging per se, cos it uses a named pipe - more "life detection"
- all of the settings in the screenshot above
What To Do:
Generally:
Disable Idle timeouts. 20 minutes of inactivity = boom! Old process gone! New process on the next incoming request. Set that to zero.
Disable Regular time interval - the 29 hour default has been described as "insane", "annoying" and "clever" by various parties. Actually, only two of those are true.
Optionally Turn on DisallowRotationOnConfigChange (above, Disable Reycling for configuration changes) if you just can't stop playing with it - this allows you to change any app pool setting without it instantly signaling to the worker processes that it needs to be killed. You need to manually recycle the App Pool to get the settings to take effect, which lets you pre-set settings and then use a change window to apply them via your recycle process.
As a general principle, leave pinging enabled. That's your safety net. I've seen people turn it off, and then the site hangs indefinitely sometimes, leading to panic... so if the settings are too aggressive for your apparently-very-very-slow-to-respond app, back them off a bit and see what you get, rather than turning it off. (Unless you've got auto-crash-mode dumping set up for hung W3WPs through your own monitoring process)
That's enough to cause a well-behaved process to live forever. If it dies, sure, it'll be replaced. If it hangs, pinging should pick that up and a new one should start within 2 minutes (by default; worst-case calc should be: up to ping frequency + ping timeout + startup time limit before requests start working again).
CPU limiting isn't normally interesting, because by default it's turned off, and it's also configured to do nothing anyway; if it were configured to kill the process, sure, that'd be a recycling trigger. Leave it off. Note for IIS 8.x, CPU Throttling becomes an option too.
An (IIS) AppPool isn't a (.Net) AppDomain (but may contain one/some)
But... then we get into .Net land, and AppDomain recycling, which can also cause a loss of state. (See: https://blogs.msdn.microsoft.com/tess/2006/08/02/asp-net-case-study-lost-session-variables-and-appdomain-recycles/)
Short version, you do that by touching a web.config file in your content folder (again with the picking!), or by creating a folder in that folder, or an ASPX file, or.. other things... and that's about as destructive as an App Pool recycle, minus the native-code startup costs (it's purely a managed code (.Net) concept, so only managed code initialization stuff happens here).
Antivirus can also trigger this as it scans web.config files, causing a change notification, causing....
Best Answer
To answer your specific question, yes, you can view application pool recycle events in the Windows System event log. Filter for event source 'WAS'.
By default only the following recycle reasons are logged;
You can change the defaults and enable logging for other recycle events in
Application Pool | Advanced settings | Recycling | Generate Recycle Event Log Entry
By default the application pool won't recycle for virtual memory limit or private memory limit (the default limit is set to 0 = never).