Quote:
Originally Posted by
Corona688
I don't know why you quoted me, you didn't answer either question.
I think I did answer the first but in a round-about way. It's not that leaving it down performs some function. It's that leaving it down keeps it out of the pool. So if the app is bad I don't start sending customer to it again.
The second question just go wrapped in with the first but my answer applies here as well. No it doesn't prevent me from debugging them. Just prevents me from returning a potentially bad server to the pool.
---------- Post updated at 03:37 PM ---------- Previous update was at 03:26 PM ----------
Quote:
Debugging why processes fail is another topic and certainly should not be used as an excuse to shave uptime down.
I agree with you on this. Where I work, however, "uptime" is measured as an SLA. So if I'm hosting a web service, we're not judged by the individual uptime of the hosts and services that make up a pool, we're judged by the availability of the service. So "Does the service respond with the proper data in < 1 sec" is far more important than "Did all the servers in the web service pool stay up this year".
If I restart apache (as an example) automatically, and there is something wrong with that instance that causes it to respond in 5 sec instead of <1, I'll have to answer for that.
So my general philosophy is that you provide high availability with hot spares, load balancing, or some other type of redundancy. Not with auto-restarts. But it sounds like I may be alone in this.
Are most people being measured by uptime on individual hosts/apps as opposed to service availability?