Ruby on Rails does not do multithreaded request-responses very well, or at least, ActiveRecord doesn’t.
The notion of only one request-response active at the same time can be a hassle when creating web applications which fork off a shell-command that takes long to finish.
What I’d like are some of your views on these kinds of setups? Is Rails maybe not a good fit for some applications?
Also, what are the current state of affairs in regard to concurrency in Ruby on Rails? What are the best practices. Are there workarounds to the shortcomings?
Rails currently doesn’t handle concurrent requests within a single MRI (Matz Ruby Interpreter) Ruby process. Each request is essentally wrapped with a giant mutex. A lot of work has gone into making the forthcoming Rails 2.2 thread-safe, but you’re not going to get a lot of benefit from this when running under Ruby 1.8x. I can’t comment on whether Ruby 1.9 will be different because I’m not very familiar with it, but probably not I’d have thought.
One area that does look very promising in this regard is running Rails using JRuby, because the JVM is generally acknowledged as being good at multi-threading. Arun Gupta from Sun Microsystems gave some interesting performance figures on this setup at RailsConf Europe recently.