Overview
This article is an overview of the ASP.NET worker process in IIS5.
IIS6 offers a slightly different architecture (maybe my next article).
Introduction
One of the most important requirements for ASP.NET framework applications is reliability.
The architecture of applications running inside the server process (in IIS, Inetinfo.exe)
does not produce a solid foundation for building reliable applications that can continue
to run over a long period of time. Too many resources are shared on the process level,
and it is too easy for an error to bring down the entire server process.
To solve this problem, ASP.NET provides an out-of-process execution model,
which protects the server process from user code. It also enables you to apply
heuristics to the lifetime of the process to improve the availability of your web
applications. Does it scale up to its promises? Lets see, but before that, we should have a
concept of AppDomains, marshalling and inter-process communication.
ASP.NET & application domains (AppDomain)
Every Windows application runs inside a certain process. Processes on the other hand
own resources like memory and kernel objects. One single process can have multiple
threads running inside it, which executes the code loaded in the process.
Operating system takes the responsibility to protect processes from unexpectedly
running into each other. Possible reasons behind this can be memory leaks in
applications, out of bound memory access, null object referencing
(GC not involved in this case) etc. If for some reason, one of the
applications crashes; other applications running in other processes
remain undisturbed. Processes provide a high level of application fault tolerance,
which is why IIS and COM+ use them, when running in high isolation mode.
So far so good, but there is one big problem with processes,
which is they are an extremely expensive resource to produce and manage, since
every process consumes memory. It is quite impractical to use large number of
processes since they don�t scale well. Apart from that, communication between
processes is also very resource consuming since we have to marshal objects by reference,
serialize/deserialize and cross process boundaries, which passes several layers including
operating system checks.
However if we run multiple applications in the same process, we will use fewer resources,
thus resulting in a faster execution cycle, since DLLs will only be loaded once,
and we don�t have to sacrifice for out of boundary calls. There are downsides to this
approach, as one application fails, others will be affected as well.
To overcome such issues, .NET introduced application domains, which have the same
benefits as the process, but multiple application domains can run within a single process.
Application domains can run safely in one single process because of the code verification
feature of the CLR, which ensures that the code is managed and safe to run. Every instance
of an ASP.NET application is created in an application domain within
the ASP.NET worker process.
Worker process creation and recycling
Whenever an old worker process recycles, a newer one is created, which replaces the
old one to serve requests. The configuration settings for the creation and control of
the worker process are stored in the root configuration file for the computer,
Machine.config. The process model is enabled by default. The process model
supports two types of recycling: reactive and proactive. The 'userName' and 'password'
attributes define the account under which the ASP.NET worker process runs.
These default to 'machine' and 'autogenerate' respectively.
These values tell ASP.NET to use the built-in ASPNET account and to use a
cryptographically strong random password stored in the Local Security Authority (LSA)
for that account.
Reactive process recycling
Reactive process recycling occurs when a process is misbehaving or unable to serve requests. The process typically displays detectable symptoms, such as deadlocks,
access violations, memory leaks, and so on, in order to trigger a process recycle.
You can control the conditions that trigger a process restart by using the configuration
settings described in the following table.
Setting description�
requestQueueLimit: Handles deadlock conditions. The DWORD value is set to the maximum
allowed number of requests in the queue, after which the worker process is considered
to be misbehaving. When the number is exceeded, a new process is launched and the
requests are reassigned. The default is 5000 requests.
memoryLimit: Handles memory leak conditions. The DWORD value is set to the
percentage of physical memory that the worker process can consume before it is considered
to be misbehaving. When that percentage is exceeded, a new process is launched and the
requests are reassigned. The default is 60%.
shutdownTimeout: Specifies the amount of time the worker process has to shut
itself down gracefully (string value in hr:min:sec format). When the time out expires,
the ASP.NET ISAPI shuts down the worker process. The default is 00:00:05.
Proactive process recycling
Proactive process recycling restarts the worker process periodically even if
the process is healthy. This can be a useful way to prevent denials of service due to
conditions the process model is unable to detect. A process can be restarted after a
specific number of requests or after a time-out period has elapsed.
Setting description
timeout: String value in hr:min:sec format that configures the time limit after
which a new worker process will be launched to take the place of the current one.
The default is Infinite, a keyword indicating that the process should not be restarted.��
idleTimeout: String value in hr:min:sec format that configures the amount of inactivity,
after which the worker process is automatically shut down. The default is Infinite,
a keyword indicating that the process should not be restarted.
requestLimit: DWORD value set to the number of requests after which a new worker
process will be launched to take the place of the current one. The default is Infinite,
a keyword indicating that the process should not be restarted.
Conclusion
We are not done yet; the next part of this article will explain session state management,
issues regarding working process recycling, best practices and performance tips.
Please feel free to report things, which I have missed out or misreported.
I will update them. I can be reached at mohsin@ecxs.net.
References
I have collected some text from the following resources:
