Re: Unicorn hangs on POST request

[Eric Wong <normalperson@yhbt.net>]

Tom Pesman <tom@tnux.net> wrote:
> > 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?

Erm, no.  You'll have head-of-queue blocking behavior with any
single-threaded Rainbows! option and worker_connections > 1

Unless you rely on Cool.io or EM-specific features in your app,
:EventMachine and :Coolio (and :Epoll/:XEpoll for Linux-only) are the
same from an app-perspective in Rainbows!

Using multi-threaded application dispatch (CoolioThread{Pool,Spawn})
will mitigate and reduce head-of-queue blocking.  Likewise for using
XEpollThreadPool/XEpollThreadSpawn (all the *Epoll* stuff is Linux-only)

Alternatively, you won't get _any_ head-of-queue blocking in a
multi-threaded app, you can use Thread{Pool,Spawn}.

Sorry for the confusion.

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

Fwiw, Cool.io works pretty well in my experience.

Last I checked, EM still had a problem by calling close(2) directly
instead of rb_io_close(), triggering Errno::EBADF.  There's a bug
opened by somebody on the ruby-core team, but I'm not sure if it ever
got resolved...

I can also help fix Cool.io bugs since it's written in C, but I can't
fix EM bugs: C++ is too big for my tiny brain.
_______________________________________________
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