I just made a startling discovery: Ruby on Rails is not thread safe.
That reminds me of PHP’s libraries thread-unsafeness and the problems it had with Apache2 multithreaded worker module.
The workaround implemented in the Webrick is to serialize calls. See this comment in /usr/local/lib/ruby/gems/1.8/gems/rails-1.1.6/lib/webrick_server.rb
# A custom dispatch servlet for use with WEBrick. It dispatches requests # (using the Rails Dispatcher) to the appropriate controller/action. By default, # it restricts WEBrick to a managing a single Rails request at a time, but you # can change this behavior by setting ActionController::Base.allow_concurrency # to true. class DispatchServlet < WEBrick::HTTPServlet::AbstractServlet
This kills performances if an action has to perform more than a basic computation. I undestand now why everybody’s using FastCGI or equivalent technologies. I experimented FastCGI months ago but it was difficult to setup and manage. I’ll probably give a try to mongrel.
However all of this makes one wonder if it’s worth investing into the Rails framework. Sure, developing with RoR is faster than with Java but can one use RoR for high load, business critical applications and still sleep the night? Are there any other discoveries ahead? This one makes me think once more that RoR’s application domain is prototyping and low traffic systems. Let’s see how mongrel can be used to patch this up.