I do a lot of work in CodeIgniter as well as Rails (w/ Ruby 1.9.2 in production), and there's no doubt that my CodeIgniter apps on slower servers with little-to-no deliberate optimization are faster than my Rails apps.
For just one particular example, I have found rendering partials in Rails are such a point of poor performance that I have often found myself avoiding it.
There's this red herring (and a pet peeve) that making the framework 'less bloated' by dropping components or making them optional equals performance. You'll even see a comment on this blog post asking which components to remove to improve performance! It doesn't work that way when the core components of Rails remain slow.
While the speed of Rails had Ruby 1.8.7 to blame for a long time, now that it's being dropped I think 4.0 has a unique opportunity to optimize for 1.9 and make a big difference to the overall speed of the framework.
Here's the video where he talks about it (towards the beginning): http://www.youtube.com/watch?v=kWOAHIpmLAI
Dropping the rails router, controllers and rack in favor of something like webmachine and resources could potentially speed up rails and reduce the conceptual complexity as well as the stack depth.
A good caching plan obviously helps with these kinds of issues.
> There's this red herring (and a pet peeve) that making the framework 'less bloated' by dropping components or making them optional equals performance.
In the case of Controllers, inheriting from ActionController::Metal and not including unnecessary modules, speeds things up a lot.
In general Rails may be slow in comparison to other frameworks. But that doesn't mean it's too slow. I don't really care if my app only manages 5000 requests per second, versus framework x's 6000 or more on the same hardware.
Nitpick: Your numbers are a little off. Rails/REE tops out at around ~300 reqs/sec on a current commodity box (16 cores/16G). This is of course application-dependent and optimization can squeeze it some, but it's a different ballpark.
When you look outside of ruby-land you can indeed find frameworks that will handle your 6000/sec on the same hardware (e.g. twisted, node, some of the evented java-frameworks).
So, depending on what you compare to rails, the difference can easily be an order of magnitude.
Caching is suggested far too often and too frequently in the Rails world. The solution to "the default tools for template abstraction are too slow to use" is not "use a difficult-to-get-correct system with concerns that cut across the entire project."
As someone else mentioned, Rails is much slower than other frameworks. It does an order of magnitude less than 5000 req/s. Obviously you can just scale it out and load balance, but that suffers increasing costs from an operations perspective. Aside from per-machine cost, there are peaks where adding more servers requires a big change in your management techniques. Those costs shouldn't be trivially dismissed, and if we can look at reworking our tools to keep most (ideally, all) of the productivity but save on the utilization (read: management overhead), how is that a bad thing?
I haven't compared performance of an application in ree versus 1.9.3 but I have seen reports that 1.9.3 is slower than ree for many apps.
So rails dropping support for 1.8.7 is a bit worrying for me.
Btw ruby 1.9.2 had a huge performance regression related to loading files which made rails apps very slow. This has been fixed in 1.9.3. So you are better off using 1.9.3 if you want to use ruby 1.9.x
Here's the rbenv project page: https://github.com/sstephenson/rbenv#readme
It's functionally equivalent to rvm minus the aforementioned negatives.
