Thursday, 1 May 2014

IIS App Pools, Worker Processes, App Domains

In a server you can have many sites that run together. Each one site is an app domain.
You must assign to each of them one application pool. Many application domains (sites) can have the same application pool, and because they have the same application pool they run under the same processes, and under the same account - and they have the same settings of the pool. If this pool restarts, then all sites under that pool restarts.

Now each pool can have one or more worker process. Each worker process is a different program that's run your site, have their alone static variables, they different start stop calls etc. Different worker processes are not communicated together, and the only way to exchange data is from common files or a common database. If you have more than one worker process and one of them make long time calculations, then the other can take care to handle the internet calls and show content.

When you assign many worker processes to a single pool then you make the called web garden and your site is like to be run from more than one computer if a computer is one processing machine.

Each worker process can have many threads. How the more worker process affect you: When you have one worker process everything is more simple, among your application all static variables are the same, and you use the lock to synchronize them.
When you assign more than one worker process then you still continue to use the 
lock for static variables, static variables are not different among the many runs of your site, and if you have some common resource (eg the creation of a thumbnail on the disk) then you need to synchronize your worker process with mutex.

One more note. Its sounds that when you make more worker process then you may have more smooth asynchronous page loads. There is a small issue with the session handler of that is lock the entire process for a page load - that is good and not good depend if you know it and handle it - or change it.
So let talk about one site only with many worker process. Here you face the issue that you need to synchronize your common resource change with mutex. But the pages/handlers that use session they are not asynchronous because the session locks them. This is good for start because you avoid making this synchronization of many points yourself.

No comments:

Post a Comment