[Mongrel] multi threaded theoretically useful?

Erik Hetzner erik.hetzner at ucop.edu
Fri Sep 7 16:40:20 EDT 2007

At Fri, 7 Sep 2007 12:32:22 -0700,
"Kirk Haines" <wyhaines at gmail.com> wrote:
> On 9/7/07, Erik Hetzner <erik.hetzner at ucop.edu> wrote:
> > processes. True, on a multiprocessor machine Ruby isn't going to take
> > advantage of the situation without native threads or running multiple
> > processes. But it may turn out that a mixture of multiple processes
> > AND green threads provides greater performance than plain old multiple
> > processes.
> I can state with a great deal of confidence that in this problem
> domain, Ruby's green threading will not get you greater throughput.

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

> A given process can only do so much work. If, in the course of doing
> that work, there is an external latency, such as waiting on some IO,
> that can be done in a non-blocking way, then it's possible to get more
> work out of that process per unit time by using threads.

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.

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

> The most efficient way of dealing with these sorts of things, from a
> throughput perspective, is to avoid the overhead of threads completely
> and just pound them through, one at a time, with 100% of the process
> resources working on that single request at a time.
> This doesn't change if you have one process or ten processes for
> your app/site.

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.

This probably does not model a typical web app. But my original
response was to a blanket statement that it was impossible to get
better performance from more threads. Here is an example of a web app
that gets better performance with more threads.

Erik Hetzner


require 'rubygems'
require 'mongrel'
require 'monitor'
port = ARGV[0]

class MyHttpHandler < Mongrel::HttpHandler
  @@lock = Monitor.new
  def fib(n)
    if n == 1 or n == 2 then
      return 1
      return fib(n - 1) + fib(n - 2)
  def process(request,response)
    @@lock.synchronize do
      sleep 0.005
      response.start(200) do |head,body|
        body << fib(15).to_s

config = Mongrel::Configurator.new :host => "localhost" do
  listener :port => port do
    uri "/", :handler => MyHttpHandler.new
  while true do
    sleep 1000000
rescue Interrupt

===============;; Erik Hetzner, California Digital Library
;; gnupg key id: 1024D/01DB07E3
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20070907/d7d2cc73/attachment-0001.bin 

More information about the Mongrel-users mailing list