[Mongrel] multi threaded theoretically useful?
wyhaines at gmail.com
Fri Sep 7 16:50:50 EDT 2007
On 9/7/07, Erik Hetzner <erik.hetzner at ucop.edu> wrote
> What problem domain? Web servers in general? Web applications? Web
> applications which are heavily database dependent? I show below
> that there are web apps whose throughput can be improved by green
The general area of Ruby web applications and the serving thereof.
> A process can use almost all the cycles available on a machine if the
> scheduler allows it to, and if it has something to do. Threads and a
> thread scheduler allow a process to have something to do.
Sure, but the _only_ way to get this with Ruby green threads is if you
have threads that are blocking on something within Ruby code, so that
Ruby can context switch to a different thread and get something done
with it while the first one sits around, waiting. You artificially
construct exactly that scenario in your example below. I'll comment
on it more in a minute. In real apps, though, most of the time, that
just isn't happening.
> > The work involved in handling web browser requests and rendering
> > responses back to them, though, doesn't tend to fall into this
> > category. It tends to be CPU intensive, and when one is waiting for
> > something external, like a database query, one is usually waiting
> > inside the body of the low level extension based database driver, so
> > thread context switching doesn't happen there, anyway.
> In my experience web applications tend to spend most of their time
> waiting for other things, from databases, web services, etc. So
> obviously your mileage may vary.
And when you are waiting on something like a database, you are doing
it within the DB driver extension, so there are no context switches
happening -- your green threads are blocked.
> Below is an example of what I'm getting at. You can tweak it to test
> various things. It is a simple mongrel server that sleeps for 5 usecs
> and then calculates the fibonacci number of 15. You can turn it into a
> multi-threaded server by commented out the synchronize stuff. On my
> uniprocessor machine you get half again the performance in terms of
> requests/sec from multithreaded.
The reason you get more performance when multithreading is because of
that sleep call. It is all happening inside of Ruby, so when running
in a multithreaded context, when one thread goes to sleep, the others
just get the execution cycles. It's artificial, though. Read Ruby
web apps don't tend to have latencies like that. When they are
waiting, they are waiting inside of things that block the entire Ruby
process, and not just waiting for something that is blocking a single
More information about the Mongrel-users