Hacker News Reader

As the number of Rack middleware pieces in a base Rails app grows, it gets slower. MRI and YARV spend a lot more time doing GC as the stack depth grows. Aaron Patterson mentioned that he was working on a modification to the Rack API where each piece of middleware did not call the next piece, reducing the stack depth and drastically improving the runtime performance of Rails apps.

Here's the video where he talks about it (towards the beginning): http://www.youtube.com/watch?v=kWOAHIpmLAI

I think part of the problem is that rails isn't really RESTful. Here is a good talk about it: http://confreaks.net/videos/699-rubyconf2011-resources-for-r...

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.

Interesting. Thanks for that link.

I'm curious, have you looked at http://reneerb.com/? I contend as well that Rails is not well suited to REST. As it stands, I think Renee is about 2x faster than Sinatra.

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

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.

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.

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

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

When using ree, the time to load an empty rails app is half that of ruby 1.9.3 (for both 3.0.x and 3.2 rails versions) https://img.skitch.com/20111206-xt99xy9m5wsejknn4dnxng1g9m.j...

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

On a pretty large rails app, we switched to 1.9.2 about a year ago. Startup time for our app is much, much worse than it was under ree, but our average response time significantly improved -- we saw close to a 50% drop in the time spent in ruby code across nearly all requests. I wouldn't use slow startup time as a reason to avoid benchmarking your app in production mode against 1.9.x, since it could result in a huge perf boost across the whole app.

There's also a reduction in the memory footprint in switching from ree to 1.9.x. I can't seem to find the article detailing memory usage, but there's a decent difference.