Re: Combating nginx 499 HTTP responses during flash traffic scenario

[Eric Wong <normalperson@yhbt.net>]

Tom Burns <tom.burns@jadedpixel.com> wrote:
> We're looking at potential solutions to this problem, including:
> - modifying unicorn to select() on the client connection after reading
> the request, to see if it's been closed upstream, and avoid calling
> the app.

You should be able to get the socket out of
Unicorn::TeeInput/Unicorn::StreamInput object via:

  env["rack.input"].instance_variable_get(:@socket)

Make sure you don't have other middleware which wraps rack.input
such as Rack::Lint.  I highly doubt the ivar name will change in
the future.

If you're accepting uploads, you (or your app framework) will need to
drain the socket of upload data, first (Rails does this for you, I
think).

> - Replacing nginx with haproxy and queuing connections there.  This
> goes against the nginx recommendation at
> http://unicorn.bogomips.org/PHILOSOPHY.html

Haproxy is fine as long as you have nginx /somewhere/ in between unicorn
and clients.  You have some extra overhead in data copying, but it could
save you cycles...

I'm unsure about the ordering, however:

a) nginx -> haproxy -> unicorn
b) haproxy -> nginx -> unicorn

Though, I suspect a) will be better.

> Any input would be appreciated.

I'd love to hear back on how you eventually solve this, too :>
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying