Mongrel vs. WEBrick

steveny — Tue, 03 Apr 2007 16:08:13 +0000

We had the need to hook up a simple ruby web process (non-rails) to our production apache server. As Leslie Hensley pointed out, fcgi and scgi are on the way out, and mongrel + mod_proxy_balancer is the new way to go. We use mongrel extensively in our rails deploys, but always just used WEBrick to do simple serving. To make a long story short, we had to ask ourselves….is mongrel that much better (and in this case better == faster) than WEBrick?

At first I decided my test would just respond with the yamlized request (just like the mongrel sample did). This worked fine but there was a significant size difference in the two documents (WEBrick’s was much bigger). In the end, I just decided to respond with a few bytes of text.

The Code

mongrel_service.rb:

require 'rubygems'
require 'mongrel'
require 'yaml'

class SimpleHandler < Mongrel::HttpHandler
  def process(request, response)
    response.start do |head,out|
      head["Content-Type"] = "text/html"
      out << "I am mongrel, hear me roar"
    end
  end
end

config = Mongrel::Configurator.new :host => "localhost", :port => 4000 do
  listener {uri "/", :handler => SimpleHandler.new}
  trap("INT") { stop }
  run
end

config.join

webrick_service.rb:

require 'webrick'
require 'yaml'
include WEBrick

class SimpleServlet < HTTPServlet::AbstractServlet
  def do_GET(request, response)
    response["Content-Type"] = "text/html"
    response.body = "I am WEBrick, hear me roar"
  end
end

s = HTTPServer.new( :Port => 4001 )
s.mount("/", SimpleServlet)
trap('INT'){ s.shutdown }
s.start

The Test

There are serveral good benchmarking tools available, but I had apache bench (ab) handy, so that is what I used. I just used the stock gem install of mongrel and the WEBrick that comes with ruby 1.8.4 (the one non-stock change I made was to comment out access logging for WEBrick since mongrel doesn’t log by default).

The Results

Total Requests	Concurrent Connections	WEBrick (seconds)	Mongrel (seconds)
1000	1	1.889523	0.365838
10000	10	19.443034	4.411788
10000	100	20.906522	4.174591

The Conclusion

Looks like mongrel it is….

Scary apache errors moving from prefork to worker

steveny — Wed, 07 Mar 2007 20:52:52 +0000

We were helping a client push more data through their apache/tomcat web application running on a Solaris box and decided to switch from the process (prefork) to the threaded(worker) processing model. When we fired up the new apache we started getting errors like these:

[emerg] (45)Deadlock situation detected/avoided: apr_proc_mutex_lock failed. Attempting to shutdown process gracefully.

Not good. After a little digging we found that the default AcceptMutex switched from pthread to fcntl between apache 2.0.49 and 2.0.52.

Adding:

AcceptMutex pthread