David
Thu Nov 30 15:49:33 CST 2006
My experience is that 99.999% of the time, it is the multitude of
applications/framework running ON TOP of IIS which are flaky or having
issues. Or the application has an unstated dependency or configuration
that hampers proper performance. The problem is that for most users, it
is hard to tease apart this difference, so to them it is "IIS is not
working" when in fact it is far from the case.
I mean, it is not the server's job to automatically make an application
perform perfectly -- that would be like mind-reading, and we don't have
that capability. Instead, it is the application's job to declare its
dependencies and for the server admin to use it and tune the
application, but most of the time, neither happens. And then people
wonder why things don't work.
For example, it is analogous to saying that:
- "Windows is not working" when Word crashes and fails to save a
document. I see it as a problem with Word because it is the cause of
the data loss; many people would conclude that they are working with a
PC running Windows and "Windows" lost their data.
- Or that when a spark plug goes out in the engine, it's "the car's not
working" and not "the engine is not working"
I'm ok with the misconception, unless one is involved with
troubleshooting - in which case I insist that one understands the
differences because it directly affects the effectiveness of
troubleshooting.
IISRESET is totally unnecessary for IIS6 and can actually be harmful,
so I recommend against it. I recommend figuring out WHY one needs to
reset IIS and fix that problem instead. I detail an approach in this
blog entry:
http://blogs.msdn.com/david.wang/archive/2005/12/31/HOWTO_Basics_of_IIS6_Troubleshooting.aspx
Recycling the application pool is equivalent to killing the process
running your application and bringing up a new one. So if you still see
problems afterwards, it is probably not within the IIS portion of the
application since it basically all restarted with the recycle. It is
probably within some other dependency of your application which exists
outside of IIS -- the question is whether YOU know about it...
For example, your issue (changing .Net assembly) has nothing to do with
IIS because it is an ASP.Net-related behavior. Maybe you should
consider that there is an independent NT service dedicated to
pre-compiling .Net assemblies... so maybe when you update your DLL,
ASP.Net tells that service to churn away pre-compiling your dependent
.Net assemblies... independent of IIS. And that's why restarting IIS or
recycling the AppPool changes nothing -- because IIS had nothing to do
with the behavior in the first place -- some other independent process
is churning the CPU... which of course rebooting would terminate.
I realize that you have found a sequence of steps that "works" to solve
your perceived issue. It is not clear to me why its rationale and
explanations are automatically sound.
//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//
nick@holidayguide.co.nz wrote:
> Thanks David,
>
> Have added a thread on www.asp.net.
>
> In my experience IIS is flaky and requires resetting quite a lot - so
> interesting to hear your comments on this! Recycling the application
> pool does not stop the problem - whereas rebooting does. It appears
> that IIS reset does not do a complete reset.
>
> David Wang wrote:
> > You are seeing a CPU utilization issue, not application crash. Big
> > difference.
> >
> > The behavior you are asking about is an ASP.Net-specific behavior, not
> > IIS. So, I recommend asking for a solution pattern within the ASP.Net
> > community. Recompilation caused by touching /bin files is a big deal to
> > ASP.Net.
> >
> > You can start with the Forums on www.asp.net
> >
> > FYI: One should never need to restart IIS6 except for some global
> > configuration changes. Handling application issues should not require
> > restarting IIS6. I don't think you need to restart IIS6 repeatedly --
> > only recycle the Application Pool containing this application. Or
> > stop/start it if you want.
> >
> >
> >
> > //David
> >
http://w3-4u.blogspot.com
> >
http://blogs.msdn.com/David.Wang
> > //
> >
> >
> > nick@holidayguide.co.nz wrote:
> > > I run a number of ASP.Net 1.1 websites on IIS6 / Win Server 2003.
> > > Whenever I update the dll files in the bin directory on one of the
> > > projects the server CPU maxes out and the only way to fix the problem
> > > is to restart IIS - I have to repeat this a number of times until the
> > > server goes back to normal. The other websites work fine - I can
> > > happily update dlls without any problems.
> > > Performance of the website in question is good with low CPU and disk
> > > activity and no evidence of memory leaks - despite being a high traffic
> > > website. I also have all the right patches installed..
> > > I suspect that the problem is caused by a large number of .aspx files
> > > with code on the page itself rather than as code behind pages (this is
> > > because website users can add pages themselves) - when the website is
> > > reset IIS appears to recompile a whole load of these files..
> > > I am in the process of re-writing the website in .Net 2 - although my
> > > testing showed that this alone would not solve the problem.
> > > Does anyone have any suggestions at what I can do to resolve this?