This also explains, in the writing about fail_timeout, how long
nginx considers a failed upstream server down for.Thank you for the clarification. Wow, I did not realize that is what the fail_timeout was for. I had seen that, but thought it was related to how long the timeout had to be before being considered down.
I really wish it worked differently. For instance with Pound, you
specify a retry interval and it automatically checks downed servers at
that interval without first redirecting any requests to it. Any chance
we may see that type of enhancement in the future?
For instance in my case I’ll then want to keep the fail_timeout short,
like 60 seconds. So this means every 60 seconds nginx will assume the
downed server is back up, and send requests to it only to find that it
is not back up yet and causing users to experience the delays. I will
use the other params to keep the delays short (like 3s). However every
minute some users will be experiencing a 3s delay.
I’ve recently switched to nginx from pound and let me just say that
nginx is so much better in just about every other way its not even a
contest. However I must say that pound does have a clear advantage in
this regarding, in that it will not direct clients to a downed box until
some other background process it runs verifies it can get a response. At
least, that is my understanding of how things went.
For as robust of a package that nginx is and performance oriented it is
a bit surprising that it would blindly assume a downed box is back up
just because x interval has passed. Would love to see it verify things
first before redirecting real users to it. Thanks for the opportunity
to provide feedback and a truly incredible tool!
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now.