> 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?