On Fri, Oct 9, 2009 at 1:30 PM, Eric Wong <[email protected]> wrote:
> "The Unicorn master manages the workers and balancing"
>
> Actually, the master never manages balancing, just the workers. The
> diagram is a little inaccurate as it looks like the master sees the
> requests, it never does.
>
> The request flow is like this:
>
> requests
> |
> |
> |
> shared socket(s)
> /|\
> / | \
> | | |
> | | |
> worker pool
>
> While the shared socket is opened and configured by the master, but the
> master does nothing else with the sockets. You're completely right
> about the pull balancing, it's one of the most distinctive differences
> between Unicorn and other setups.
Thanks! I've updated the diagram and some of the language to be accurate.
> Also, for the 502s, do you get more 502s after the initial worker times
> out? I think nginx may (still)[1] mark a backend as completely dead/down
> when a backend dies. That may cause nginx to stop forwarding to that
> backend entirely and throw more 502s for a few seconds until nginx
> decides to actually try that backend again.
>
> Setting fail_timeout=0 causes nginx to never mark backends as down and
> always try to send a request to them:
>
> upstream github {
> server unix:/data/github/current/tmp/sockets/unicorn.sock fail_timeout=0;
> }
We'll try this out, thanks for letting us know about it.
Cheers,
--
Chris Wanstrath
http://github.com/defunkt
_______________________________________________
mongrel-unicorn mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
