How are downed upstream servers detected as alive again?

Hi everyone! I am new to nginx (switching over from using Pound) and
absolutely LOVE it! What a fantastic solution. I am using it primarily
as a reverse proxy for load balancing across my Amazon EC2 instances.

I’ve spent the past week digging in deep and learning the ropes and its
been easy to get up to speed. However I haven’t been able to find out
some pieces of information despite lots of research so I’m hoping you
can help out. I’ll post these as a series of questions since the
subjects are pretty diverse, rather than as a block of multiple
questions in one message. So let’s get started!

I’ve searched this list, the FAQs and Wiki but couldn’t find a
discussion about what process nginx uses to monitor upstream servers to
see if they come back up once they become skipped due to
proxy_next_upstream rules.

For instance, let’s say I have 3 upstream servers defined, and there is
a problem with one, such that my proxy_next_upstream rules dictate it
should be skipped over. What frequency does nginx check to see if that
server comes back online? Does it check in the background at some set
interval, and if so, is there a way to set the frequency (check once
every x seconds)?

Or does it check the bad server on every single request nginx receives?
That seems like it would not be efficient. At any rate, in playing with
it I couldn’t seem to figure out what process is uses for this. Can
someone please let me know? Thank you!

  ____________________________________________________________________________________

Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now.
http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

On Wed, 23 Apr 2008 13:37:10 -0700, Rt Ibmer wrote:

See http://wiki.codemongers.com/NginxHttpUpstreamModule, documentation
on
the ‘server’ directive explains the conditions by which nginx downs a
server. This also explains, in the writing about fail_timeout, how long
nginx considers a failed upstream server down for.

Also, if you can, please refrain from posting messages as HTML to the
list. We don’t all use webbrowsers to read our email.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs