> 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? _______________________________________________ Unicorn mailing list - [email protected] http://rubyforge.org/mailman/listinfo/mongrel-unicorn Do not quote signatures (like this one) or top post when replying
