Unicorn hangs on POST request

Tom Pesman tom at tnux.net
Tue Apr 2 20:25:02 UTC 2013

> Probably not, at least it won't improve _consistency_ of performance
> without changing your app.
> The problem with buffering in Rainbows!+EM is the buffering happens after
> the work is distributed to different worker processes (Rainbows!+EM is
> still single-threaded).
> I don't believe there's a universal Rainbows! configuration which is
> good for most apps.  With Rainbows!+EM, the buffering happens in a late
> stage, after workload is distributed, so you end up with head-of-queue
> blocking inside each process.
> All of the modules _without_ "rack.input streaming" will fully buffer
> responses (similar to how Rainbows!+EM) does it:
> http://rainbows.rubyforge.org/Summary.html
> However, CoolioThread{Pool/Spawn} should help you with the work load
> distribution problem if your app is thread-safe, but these both do body
> buffering.
> However, the multithreaded options _with_ "rack.input streaming" still
> give pretty good performance and let you get around the workload
> distribution problem of the single-threaded + internal buffering
> options.  You'll reduce disk seek overhead with input streaming.
> For reference, nginx+unicorn is single-threaded, but with external
> buffering (nginx does the buffering, not unicorn).

Thank you for your extensive response!

To verify my thoughts on this, if I want to prevent the head-of-queue
blocking behaviour, I need to take a module without
rack.input_streaming. But we need to make sure the body is buffered
before it's given to a worker. On which property do I select the
correct module?

Are Coolio modules still a sensible choice as the Coolio project isn't
actively maintained?

More information about the mongrel-unicorn mailing list