|
xxx
Crashproof Overview by Charles Carroll
ASP.net brings fault-tolerance, crash recovery and many other
advanced tools to the party.
Any code that leaks memory, creates infinite loops, or does not close a
resource will only affect 1 thread. Once the ASP.net environment detects a thread
acting quirky it will direct new requests to new threads, and keep new requests
from interacting with this suspect thread. Eventually as the last user request
is processed on this damaged thread it will destroy and recycle the thread.
If code is undetectably bad, simple directives in a web.config file can
initiate destroying and recycling of threads when problems are detected, or
even when not (for example all threads are destroyed every 30 minutes). Threads are simply
destroyed and recycled just in case. This means SERVERS will never need to be
rebooted.
So if User1 executes an infinite loop, and the request is on Thread 3, then
the next user gets their script executed on Thread4, and a plan is put in place
to tear down and destroy thread3.
A simple web.config setting (the ASCII/XML config files that control
everything) ensures that ASP.net worker process never eats up more than n amount of RAM. If the ASP.net worker process begins eating more memory than specified, a new ASP.net worker
process is created to service new page requests, and the old worker process destroyed after finishing its requests
in progress.
<iisprocessmodel
enable="true"
timeout="1440"
idletimeout="1000000"
shutdowntimeout="5"
requestlimit="10000"
memorylimit="50"
cpumask="1"
usecpuaffinity="0"
requeststacks="0"
/>
http://www.aspfree.com/articles/08102000.asp
explains the settings more.
Since ASP.net worker does all the page composition and hands off static HTML
to IIS, IIS then becomes the next likely target to crash. It does this so if
ASP.net is moved to say Solaris, ASP.net could hand off static HTML to say
Apache or some-such. ASP classic and IIS are tightly coupled. see ASP Internals
by Jon Flanders
http://www.amazon.com/exec/obidos/ISBN=0201616181/learnasp
ASP.net and IIS aren't on same planet.
In Las Vegas, Scott Guthrie demonstrated the ASP.net worker noticing a trashed IIS website and creating another website on the fly to service a webpage request.
Scott Guthrie, Asp.net designer pipes
in
Here are a few ASP.NET features I can think of that improve reliability and
availability:
- Automatic detection/recovery of access violations (AVs)
- Automatic detection/recovery of memory leaks
- Automatic detection/recovery of thread deadlocks
- Ability to configure ASP.NET to proactively restart worker process every N
minutes (w/ no loss of service)
- Ability to configure ASP.NET to proactively restart worker process every M
requests (w/ no loss of service)
- Ability to update/replace running DLLs without interruption of service
- Ability to update/replace configuration without interruption of service
- Web farm session state (ensures no state is lost on web server restarts)
- Output caching and partial page caching to reduce load on servers
- Ability to run hosted apps in a secure "sandbox" to prevent
mischief
- Per application perfmon counters (easier to monitor/detect problems
- Application_Error event that can be used to log/notify admins of app
errors
|