The acceptable level is zero.
There may be specific things that are environmental and out of your
control (such as dependence on outside web services, network, etc) but
those faults should be handled internally by your app and therefore do
not bleed through to your users as faults.
The place to start is your logs, and if you don't have any then start
logging. There's generally an accepted thought in you should only
catch exceptions if you can do something about that. This is wrong
(IMO). You should catch and rethrow exceptions with additional
information whenever you have additional information to provide (which
is pretty much always--your method parameters, values in relevant
variables, etc). Then once you have logging in place look at the
stack traces and track errors down one by one.
HTH,
Sam
------------------------------------------------------------
We're hiring! B-Line Medical is seeking .NET
Developers for exciting positions in medical product
development in MD/DC. Work with a variety of technologies
in a relaxed team environment. See ads on Dice.com.
On Fri, 09 Nov 2007 23:31:17 -0000, none <ba*******@gmail.comwrote:
>I have an ASP.NET application, hosted on two web servers. I am looking
for advice on what should be an acceptable level of page faults on
these production servers. If the acceptable level is zero, then where
should I begin reducing page faults in code? What should I look for in
code to reduce page faults?
Having to reduce page faults is something I have not had been tasked
with before, so I am not sure what is acceptable and where to begin.
Thanks,
Alex