[cvshepherd]

> 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.

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.

[moe]

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.

[cvshepherd]

When you use Metal endpoints, as i mentioned in my comment, 6000 requests per second is actually very possible. Yes, you need a lot of resources, but I didn't suggest otherwise. And yes, on this hardware other frameworks will manage even more requests.

EDIT: My low budget netbook just gave me 327 req/s with an out of the box Rails config, and running the benchmarking tool on the same machine.

[awj]

> A good caching plan obviously helps with these kinds of issues.

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?

[cvshepherd]

> 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."

I'm not selling caching as a silver bullet (and I'm not saying it's trivial to implement, either). It's just something a lot of people either don't use at all, or just get wrong. And surely, if something can be cached, it should be.

> As someone else mentioned, Rails is much slower than other frameworks. It does an order of magnitude less than 5000 req/s

With Metal endpoints, proper configuration and lot's of resources, this is very possible.