Re: Our Unicorn Setup

[Eric Wong <normalperson@yhbt.net>]

Chris Wanstrath <chris@ozmm.org> wrote:
> Hi list,
> 
> I've just published a post detailing our Unicorn setup, migration
> process, and reasons for choosing it:
> http://github.com/blog/517-unicorn

Cool!

"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.



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;
  }

I'll add this bit somewhere in the Unicorn docs and release 0.93.3 with
the OpenBSD fix for Jeremy in a bit.

> Thanks again!

No problem :)


[1] - I'm not 100% sure if nginx still does this, but I don't see
      anything in the 0.6.x changelog that indicates otherwise.
      I don't see a huge amount of harm in doing this always, we've been
      using fail_timeout=0 for ~2 years now regardless of the backend.

-- 
Eric Wong