You don't use Mongrel by itself. You use a mongrel cluster with a
load balancer, like Apache. That takes the load of any static files
off of Ruby. Then there's your app. The execution of an application
request dwarfs any work that Mongrel is doing. If 99% of a request is
application processing then it doesn't matter if you switch from
Mongrel to an infinitely fast (magic) app server--you'll still only
get 1% improvement.
There's a lot of Rails performance hysteria out there right now, but
it's important to remember that Ruby is only slow relative to other
languages, and not terribly slow at that. You don't see people
running out and building web frameworks in C++ just because "Java is
slow".
Exactly, what is slow? My productivity has increased tenfold and the performance is top-notch. Serving static files through Apache and balancing the rest to a mongrel cluster is just a dream come true.
The benchmarks I've seen put Ruby at the slowest language out there that anyone's actually using. That said, slow is often relative to what you're doing, how you code it, and what other facilities you use. Rails has a lot of mechanisms (caching, etc.) to help speed up your *app*.
-faisal
*also*
The Ruby performance issue is around execution speed. Threads won't particularly help with that, except insofar as they reduce the memory footprint of the application server. It isn't clear how much they'll help there, since a lot of the infrastructure will need to be replicated anyway.
-faisal
Another issue, that hasn't yet been raised, is that if your Ruby code
is spending 90%+ of it's time waiting on you SQL queries to return,
then the performance difference between Ruby and any other language
becomes irrelevant. In my experience this is true a very large
percentage of the time. Most of your performance tweaking will be
database related anyway.
