Develop Reference

How does the w3wp.exe work with a web application?

If I create a web application and host it on a Windows Server, then as I understand it, IIS handles the initial request and routes it to the appropriate website or application. I'm under the impression that a w3wp.exe (worker process) instance is created for each application. IIS works with the worker process, which in turn works with the web application.
What happens if the application gets twenty requests per second? Will the worker process create twenty instances of the application to handle each request, or will it queue the requests passing them to a single instance of the application as and when?
I suspect it's the latter. If that is the case then am I right to think that the worker process will keep an application alive whilst it is getting requests?
I'm trying to fully understand what a web application does when it handles many con-current requests. I've tried asking this question before but struggled with the wording, so hopefully this makes sense.
EDIT:
Thanks to Mason I realised that the answer was right in front of me! Web applications use DLLs, which can't run by themselves. It's the w3wp.exe (worker process) which call the DLLs to handle the requests.

The number of worker processes per web site is controlled in the application pool advanced settings (in IIS management console).
The configuration of number of concurrent requests each of the workers can handle depends on the IIS version. In IIS 7 was in the same place, for more recent versions you will have to check your machine.config (looking for maxWorkerThreads)

WCF Service Hosted in Windows Service running 10x slower than console app

I have a C# library that does some file processing. I created a console and desktop application that uses the library and processes a 256mb file in about 1min. I then created a WCF service hosted in a windows service which uses the same file processing library yet takes 10x longer to process the same 256mb file when called from a website. The windows service is running under a domain account with administrator privileges.
The overhead in calling the WCF service is very fast yet the LoadFile method takes much much longer. I tried increasing the process priority during startup via
Process.GetCurrentProcess ().PriorityClass = ProcessPriorityClass.High;
to no avail. I've run this service on a Win7 64bit desktop system (6gb), 2003 XP 32bit server (4gb) and 2008 R2 32bit server (4bg) all with similar results. The console and desktop apps each process the file in about 1min on the above system. The process does not appear to be memory constrained and entering swapville.
Are windows services somehow process constrained? Would I get better results running the WCF service under IIS?
EDIT: I tried calling the library directory from the website and that too takes 10x longer than the console or desktop application.
UPDATE: Turns out it was Log4PostSharp. The console and desktop apps didn't have any traces of log4net in the configuration files yet the website and windows service did. There was a log4net TraceAppender silently eating up precious CPU cycles.

I cannot think why the behaviour you describe is happening - it does seem very strange. Since you are processing a relatively large file in memory though, the garbage collector may be affecting it. You could try changing the mode the garbage collector runs in to see if it has any effect.
The garbage collector has three modes - workstation, server and concurrent. Each one behaves in a different way and is optimised for different types of applications. Workstation mode is the default mode, and is what all processes run using unless configured to use something else. More info about the modes can be found here.
Try explicitly setting the garbage collector to use server mode (it will only have an effect on a multi-processor machine though). To do this, put the following in your app.config file:
<configuration>
<runtime>
<gcServer enabled="true" />
</runtime>
</configuration>

Why does IIS stop after a while?

I am not too clear about the IIS lifecycle, but my general understanding is:
Every couple of hours IIS resets itself. This is apparently done so as to fix up any memory leaks, resource deadlocks etc. etc. ie. It seems to be a cleanup operation.
Every couple more hours (I think I read 23 hours) the server just stops listening to inbound requests and runs Application_End. An external page request will restart the app.
Can I get a bit more reasoning to why these behaviors occur? Especially with regards to item #2... My server runs internal scheduling behaviors which completely died last night. The reason was that Application_End occurs and no customer requests were happening to start the IIS server again. This seems weird. Why not just clean up memory leaks etc. and then keep IIS running exactly as it was? The only reason I can think of is that it lets the server reclaim memory/cpu used by IIS, but that seems nonsensical and the cause of bugs, such as my scheduler issue!

Each website in IIS sits in an application pool and you have three different sections that influence when an application pool recycles it's worker process; Recycling, Performance and Health. When the process recycles, a new worker process (w3p.exe) is created first to handle any new requests. Any existing requests are completed on the old process before that is then closed. Application_Start and Application_End will run on each process so you can setup and teardown resources appropriately.
The Recycling settings have the most direct impact on when the worker process will recycle and you can choose to restart after a specific number of minutes running, number of requests processed or at a specific time each day. In a web farm using a specific time can ensure that you never have all the severs in the farm recycle at the same time. You can turn all these off so your worker process doesn't recycle but as you stated in your question this leaves the server vulnerable to memory leaks and threads hanging which will stop IIS serving any requests for websites in that application pool.
The Performance settings can shutdown a worker process if it has been idle for an specified number of minutes or if the CPU reaches a specified threshold. You can also increase the number of worker processes for an application pool and create a web garden.
The Health settings monitor worker processes and will shut them down if they fail repeatedly and will check that they start and stop within a specified time.

Technically, IIS is not stopping or resetting. It's the application pool that is being recycled which ensures that the application domain in which your web applications run does not bog down over time due to bugs/inefficiencies in your code, bugs in the framework, etc.
The IIS model is actually very good for the health of a long-running application. Windows Services for example don't get these benefits. If the process crashes, it's done. But because IIS can measure various aspects of your web application like response time, memory consumption, inactivity, etc, it can offer to reset your application under certain circumstances. They're all configurable but you should always strive to develop web applications in such a way that one request does not depend upon a prior request.
You should also not rely on things happening in the web application that are not directly in response to a web request. So if you are starting up a background thread to do some background tasks then I'd recommend moving that out into a separate process (such as a Windows Service or Scheduled Task.) Although if you really don't want to do that, there is an IIS 7 Application Warm-Up Module that will periodically ping your web application in order to start it.
If you are using in-process session state and the resets are causing problems, you may want to consider using a SQL-based session state provider.
In any event, you can read more about configuring the IIS 7 application pool recycling behavior here. http://technet.microsoft.com/en-us/library/cc753179(WS.10).aspx

I think the other posters have already answered your main question sufficiently well however I'd like to address the final part of your question.
Why not just clean up memory leaks etc. and then keep IIS running exactly as it was? The only reason I can think of is that it lets the server reclaim memory/cpu used by IIS, but that seems nonsensical and the cause of bugs, such as my scheduler issue!
and
Why do I need to wait for a web page request to start up my pool, rather then having the server automatically running and gung-ho about receiving client web requests?
Let's think about the following scenario and what would happen if IIS behaved in this way. If we have a machine hosting several thousand websites (i.e. your typical shared hosting environment) each website has it's own application pool (w3p.exe) running. Say that IIS started up a worker pool for each website regardless of if a request to that site had been made, you'd have a few thousand processes starting up at once each idling at say 2MB of RAM. If you've got 2000 websites you've just allocated 4GB of RAM to sit and essentially do nothing and the OS might start eating into the page file without any real need.
Is this desirable? I think you'd agree that the answer is no.

These behaviors can be controlled by changing the app pool recycle settings of your website. Our production website at work recycles its pool every night at 3am, but our QA environment recycles several times a day.

Global.asax and web application lifetime

Question: When a webapplication gets started, it executes Application_Start in global.asax.
Now, a web application gets started as soon as the first request for a page in that application reaches the server.
But my question is: how long will the application run until the application is stopped.
I mean when after the first page request, there's no traffic on the server.
I need to know because I intend to start a server that listens on a tcp port in global.asax.
And when the application stops, the server ceases to listen to its port.

It depends on your IIS settings. Your application will run in an application pool, which takes a bunch of settings defining the behaviour of this pool.
The thing you're looking for are recycling settings. In IIS 7, you can access these easily from the management console. Go to Application Pools, right click on the application pool your app runs in (if you don't know which one that is, then it's probably the DefaultAppPool) and select recycling.
Here you'll find the options you have to control the recycling behaviour of your app pool, which in turn controls when your app 'resets'.

in a word (well 2) - shared hosting.
on shared hosting beware, (godaddy/webhost4life etc) this timeout could well be less, plus you don't have option to configure that on these hosting environments. i've had cases where the app pool is recycled after 5 mins at certain peek times, so you might have to investigate 'wakeup' routines to poke your app to keep in in the memory. i do this for a few shared hosting apps to great effect using pingalive.com.
hope this helps, even if in an abstract way.
jim

Check if IIS Application is running without causing it to run

I am writing a web monitor app that gives information about all app pools / apps on my IIS server. I am looking for a way in C# to programmatically check if an IIS application is running without causing it to run if it is not.
Here is what I have found...
application is running, there are one or more sessions active.
all sessions dropped off...application still "running", app pool worker process is running.
At some point determined by IIS, the Application_End is finally executed...however, the app pool worker process is still running.
After 20 minutes, the app pool worker process finally shuts down due to inactivity.
It is between #3 and #4 that I am having trouble. The application has ended, but if I try to send an Http Request to the app, it will automatically start up. I am looking for a way to programmatically determine if the application has ended (while the worker process is still active awaiting shutdown) without restarting the Application.
I can try to provide more details if you are unsure what I am talking about.
Regards,
Jeremy

I found this on MSDN
public bool CheckIISRunning()
{
ServiceController controller = new ServiceController("W3SVC");
return controller.Status == ServiceControllerStatus.Running;
}
For this to work you need to have
System.ServiceProcess added as a reference.

Microsoft has created a VBScript file to identify the IIS Application Pools (by Process Id). If you search "iisapp.vbs" on google it should point you in the right direction.
Note: I'm not 100% sure that it will work with Windows Server 2008, but does work with 2003.

In IIS7 you can use appcmd apppool /? to see what possibilities are available.