Combating nginx 499 HTTP responses during flash traffic scenario
normalperson at yhbt.net
Mon Oct 29 18:45:49 UTC 2012
Tom Burns <tom.burns at 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:
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
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
> - Replacing nginx with haproxy and queuing connections there. This
> goes against the nginx recommendation at
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 :>
More information about the mongrel-unicorn