Do Ruby on Rails sites have performance issues? [closed]_问答_开发者

Closed. This question is opinion-based. It is not current开发者_运维百科ly accepting answers.

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 9 years ago.

Improve this question

Are Ruby on Rails site usually slower than java or .net sites? (This is assuming developers are not abusing the technology.)

A lot of Ruby sites I have seen have performance issues.

Yes, Ruby on Rails sites do have performance issues, just like any other site. And just like any other site, those performance almost always are rooted in architectural decisions, not the language or the framework.

There was a nice presentation a couple of years back by Joyent (might have been RailsConf 2007?), which showed on one slide all the servers that are running on a single instance of their Rails platform. About 40 processes. Only one of those processes was the Ruby interpreter, everything else was stuff like the DNS resolver, web server, database server, MTA, memcached, message queue, reverse proxy, load balancer, etc. Every single one of those can screw up your performance. That's a 97.5% chance that your performance problems have nothing whatsoever to do with Rails or Ruby.

There's some really nice E-Mails on the JRuby mailinglists, and also some Tweets and blog posts by people who rewrote their Java web applications in Ruby and got a 10% performance improvement.

A really good example is Twitter. Twitter is one of the biggest Ruby on Rails sites in the world. It is also one with a very unusual usage pattern that will give any framework that is designed for "normal" web applications a tough nut to crack.

Now, you might think, why did I choose Twitter of all things as an example of performance and scalabilit, when clearly it is the exact opposite that they are known for? Well, that's exactly the point: they have had a ton of scaling, performance and reliability problems. And not a single one of those had anything to do with Rails or Ruby. In fact, Rails and Ruby were pretty much the only pieces in their stack that they did not have problems with.

They had problems with unexpected growth. It doesn't matter which language or framework you use: if users are signing on faster than you can buy new servers, there is nothing you can do.

They had problems with the performance and scalability of MySQL. Again, MySQL has nothig to do with Rails or Ruby. In fact, MySQL is written in C, so if you really absolutely must make any ridiculous conclusion about a programming language, based solely on a single incident, then it would be this: C is slow. If you want performance, stay away from C.

(In this particular case, in one interview, they actually did blame Rails: they said that because Rails only supported a single connection to a single database, their MySQL instance simply got overloaded. Within hours of that interview being posted, two Rails developers independently of one another both released Rails plugins to implement multiple connections. The lesson is: only the 80% solutions are in the core. Twitter clearly isn't in the 80%. The plugin API is there for a reason.)

They had problems with the performance and scalability of the overall system. It turned out that, in order to get the product out quickly, they implemented absolutely no caching whatsoever. Even the "static" Twitter homepage was completely dynamically generated for every single request. Again, this had nothing to do with Rails or Ruby. You can bring any site down by turning off their caches, I guarantee you that.

They hit some very bad scalability problems (and the MySQL problems mentioned above are related to that) which were simply caused by the fact that people used the site in a way not anticipated by the developers. Everybody knows that Twitter is a micro-messaging platform. Well, except for the Twitter founders. They had this brilliant idea for a micro content management system.

And so, they did build a micro-CMS. And of course, the central piece of a content management system, is a content repository, IOW a database. Users however used Twitter as a micro-messaging platform. And the central piece of a messaging platform is a message queue.

As a result, MySQL was being used as a message queue. No two things could be further apart than a database (especially a SQL database) and a message queue. The two have almost exactly opposite requirements and constraints.

And of course, the entire architecture was built around that content repository which was now being abused as a message queue.

In response to that, the Twitter developers wrote their own message queue in Ruby, which helped performance and scalability a lot. But not enough. So, they wrote another message queue, this time in Scala.

It is this single rewrite that is wholly responsible for, I would estimate, at leat 70% of all the Rails FUD out there. But, I don't know about you: when I write something that I have absolutely no idea how to write it, and then I write the exact same thing a second time, when I actually do know what the heck I'm doing … the second one is always better than the first. And I suspect that this is the case here, too.

In several interviews, the Twitter developers have pointed out that Ruby on Rails was not responsible for their scaling problems. On the contrary, only the maintainability of Ruby made it possible to do such large-scale architectural changes to fix their scaling problems.

To cut a long story short: today, Twitter is actually using Ruby on Rails for what it was intended to be used: for a web application. And they use a database for storing data and not as a message queue. And they use an actual proper message queue. The message queue and some other backend stuff is written in Scala. The frontend is written in Ruby on Rails. Some stuff is written in C.

And all is peachy.

The real moral of the story here is that you can substitute pretty much any large web app, any language, any framework into the above story and it would still be true. MySpace is one of the slowest, most unreliable websites I know, and that is a .NET site. GitHub is one of the fastest websites I know, while being the biggest hosting platform (it has over a million repositories after just over 2 years, that's more than SourceForge and Google Code combined) and it is written in Ruby on Rails for the frontend, Sinatra for the web service, Ruby for the Git interfacing and Git infrastructure, Erlang for the federation and cloud infrastructure and Node.JS for the download server.

Here's a start

Scaling ROR

Why Rails can run slowly

Framework Preformance Comparison

SO related question

Related interest article Twitter abandons ROR its old I know but I didnt actually know that lol

Short answer
Could potentially sure.
Might be more likely than some other languages.
Depends on the application, the programmer and the architecture.

As I see it - RoR is only a bit slower. At least slower than .Net, cause ruby is interpreted language.

But in general - it depends on quality of developers. RoR app that uses nice caching will work n times faster than .net/java app that loads half database into memory and sends plenty database requests cause of select n+1.

yes it is slower, but in production it will probably only hurt you once your load "exceeds a certain point" ("x requests/sec") and most sites never see more load than that.