Ruby on Rails and Scalability, Opinions?

[Joseph Hurtado]

Friends,

Lately a lot of people have been complaining about Ruby on Rails scalability, especially there is a comeback story from Twitter.

I have heard that Ruby is not the problem, it is Rails, which apparently has bad design decisions and does not scale easily.

Scale here means massive web application, with massive hits to pages and to the database.

Is this just FUD or is there any truth to this?  What alternatives are out there within Rails?

Is it worth it to try the alternatives?  I say this because I am sure the core of Rails must be evolving all the time, and fixes to scalability must be on the pipeline.... are they?

Opinions, experiences, suggestions?

Some more commentary on this issue:

http://www.alexhopmann.com/2008/05/12/twitter-ruby-on-rails-and-scalability/

http://romeda.org/blog/2008/05/scalability.html

Joseph Hurtado
Toronto, Canada

[Bob Hutchison]

Hi,

On 13-May-08, at 10:31 AM, Joseph Hurtado wrote:

> Friends,
> Lately a lot of people have been complaining about Ruby on Rails
> scalability, especially there is a comeback story from Twitter.
>
> I have heard that Ruby is not the problem, it is Rails, which
> apparently has
> bad design decisions and does not scale easily.
> Scale here means massive web application, with massive hits to pages
> and to
> the database.
>
> Is this just FUD or is there any truth to this? What alternatives
> are out
> there within Rails?
> Is it worth it to try the alternatives? I say this because I am
> sure the
> core of Rails must be evolving all the time, and fixes to
> scalability must
> be on the pipeline.... are they?
>
> Opinions, experiences, suggestions?

I find it hard to believe that Ruby or Rails has a lot to do with
twitter's problems. And everyone directly involved in twitter seem to
confirm that.

Here is a two part article that you might find interesting:

<http://www.hueniverse.com/hueniverse/2008/03/on-scaling-a-mi.html>

And read this for an overview of the twitter architecture:

<http://highscalability.com/scaling-twitter-making-twitter-10000-percent-faster
>

I've extracted some of the stats from the 10000% article. It is
worthwhile keeping in mind just what we are talking about.

• Over 350,000 users. The actual numbers are as always, very super
super top secret.
• 600 requests per second.
• Average 200-300 connections per second. Spiking to 800 connections
per second.
• MySQL handled 2,400 requests per second.
• 180 Rails instances. Uses Mongrel as the "web" server.
• 1 MySQL Server (one big 8 core box) and 1 slave. Slave is read only
for statistics and reporting.
• 30+ processes for handling odd jobs.
• 8 Sun X4100s.
• Process a request in 200 milliseconds in Rails.
• Average time spent in the database is 50-100 milliseconds.
• Over 16 GB of memcached.

Cheers,
Bob

[Kieran]

Hi Joseph,

While there is a certain amount of truth to Rails' difficulty with
scalability, the issue is a little murky.

From a purely technical perspective, Rails can be somewhat slow at
times. There are a few patches that significantly increase
performance, one of which is a simple garbage collection patch (not
sure if it's been folded into core yet) that makes a dramatic
improvement.

I've always preferred the simplicity and lean design of merb, a rails-
inspired alternative that focuses on performance. As far as frameworks
go in general, it's tough to imagine a better design. See http://merbivore.com
for more.

Specifically in the case of Twitter, I can't help but feel that Rails
was a poor fit to begin with. It's simple design and the high
throughput probably warrants compiled code IMO. It would almost
certainly benefit from being written (at least partially) in C, seeing
as the app is small enough to be maintainable. Incidentally, I seem to
recall that 37 Signals rewrote parts of Basecamp in C, though I could
be mistaken.

Bottom line: Rails is an excellent tool, merb doubly so. However, as
is always the case, using the right tool for the job is key to the
success and sustainability of your app. You'll have to judge that
based on your requirements.

Cheers,
Kieran

[Rowan Hick]

+1

The other thing (god knows how many times this has come up with). You have to take the mental leap is that twitter really isn't a web site, twitter.com is the front end to a massive messaging service. Regardless of what technology used, the way it was architected on day 1 I bet really didn't envisage what they would become. Hindsight as they say is always a wonderful thing.

Rails let them build something fast, but it arguably was not the right approach to make. Kieran is hitting the nail on the head that it should be having some compiled c stuff underneath, but that's only part of the problem, the bigger problem is how to get a users messages/pushing/pulling messages and how the messages are stored in the database/messaging layer. Which is a really scary/interesting question. Regardless of whether it's C, Java, Perl PHP etc as the application layer, it wouldn't matter - they'd still have issues, it's just unfortunate that RoR was involved as that's where the finger is pointed by people who don't appreciate what's involved. The more users piling on the system, the more it's going to get to be a problem. 

Make no mistake here I'm not sitting in an ivory tower pretending to have the answer. I'm just saying people offering their 2cents worth on techcrunch etc who have no real appreciation of what's going on under the hood, shouldn't be commenting on this, and should therefore be taken with a grain of salt :)  There's been an interesting thread on read write web about it which is actually looking in depth at the problem, suggest reading it.  http://www.readwriteweb.com/archives/making_twitter_scale.php 

The vast majority of people will never have to worry about scaling, most apps built are lucky to put through a number of requests a minute (or hour), very few are doing numbers of requests per second and fewer still are in the tens/hundreds per second. Which is why the premature optimisation argument gets bandied around so much - most people concentrate way too much on "I need to scale I need to scale" without looking at the realities of what is actually going to happen. In actuality what 98% of people likely need is to build something fast, and if the Rails way suits your business need, there's probably no faster tool to get something up and running. 

If you do need to scale, throw the premature optimisation argument out the window and think about it from day 1, start looking at Merb, what can be offloaded into compiled code, look at your db layer, plan the thing out properly. There's enough examples in the wild to prove that Rails (or more importantly, not Rails but the programmers using Rails) can develop massive sites. 

Just take a look around and hire the right team and use the right tool for the right job. 

Cheers

Rowan 

---

work.rowanhick.com

[trumpetinteractive]

Bob, Kieran, Rowan,

Great articles and amazing statistics on Twitter; and the true nature
of scalability. Thank you all!

Below, I write some points that became evident after reading
Hueniverse.com; one of the best discussions I've read on this subject.
Whenever I quote, I am referring to Hueniverse part I here:
http://www.hueniverse.com/hueniverse/2008/03/on-scaling-a-mi.html


1. Twitter is Close to Real Time, No Framework or Language will have
an easy Run with it.

- Twitter is as close to real time messaging as it gets, that's their
challenge. Ruby on Rails is not really the issue, the issue would
apply to almost any language, even C. Since the bottlenecks are
potentially everywhere the hits come, go or bounce too.
A quote from Hueniverse: " Facebook offers users abstract controls
over what kind of content to show and then provides a feed that is an
approximation of what the actual accurate aggregated status really is.
What this means is that Facebook is showing a timeline that is good
enough but not fully reliable and in the context of a friends feed is
good enough. The same cannot really apply to Twitter or other
messaging platforms where reliable delivery of messages in order is
critical. "


2. Twitter is not Facebook, is not MySpace, it is about messaging
- Facebook gives you an approximation of what's going on, there can be
a significant lag in updates, same goes for MySpace, Flickr and almost
any other social network. Those delays help to scale. Twitter has no
such luxury.
- The problem is that for this over 10,000 request a second universe
of Twitter, a database IS NOT the solutions, and every bottleneck
becomes significant. Related:
http://www.mooseyard.com/Jens/2007/04/twitter-rails-hammers-and-11000-nails-per-second/


3. New Tools are Needed and They will be built... in the meantime:
It's the Architecture Stupid!
Tools like Merb, database Sharding, intelligent caching and more are
needed. None is perfect, none can solve the issue ahead. Even Twitter
has released Starling for queuing http://rubyforge.org/projects/starling,
more is needed, more will come... but in the meantime architecture,
intelligent humans thinking is the only real solution to this
challenge.


The moral of the story would be: stop thinking the database is enough,
stop thinking the framework will do everything for you, stop and
architect early on for success, and big traffic or face the
consequences of your decisions.

For one, I still like Ruby on Rails, I will surely look into MERB now,
and also never I will never discount PHP; it seems that somehow PHP
developers have been able to scale that language beyond anyone's
expectations. Flickr is a good example: http://highscalability.com/flickr-architecture;
so for the most part "scripting" languages seem not to be the real
culprit. And the benefits of scripting outweigh the cost of "not
compiled" here.

Or as Blaine Cook of Twitter said, quite accurately:

"For us, it’s really about scaling horizontally - to that end, Rails
and Ruby haven’t been stumbling blocks, compared to any other language
or framework. The performance boosts associated with a “faster”
language would give us a 10-20% improvement, but thanks to
architectural changes that Ruby and Rails happily accommodated,
Twitter is 10000% faster than it was in January."
http://highscalability.com/scaling-twitter-making-twitter-10000-percent-faster

Take care everyone,

Joseph Hurtado
Web Developer
Toronto, Canada

> <http://highscalability.com/scaling-twitter-making-twitter-10000-perce...

>  >
>
> I've extracted some of the stats from the 10000% article. It is  
> worthwhile keeping in mind just what we are talking about.
>
> • Over 350,000 users. The actual numbers are as always, very super  
> super top secret.
> •  600 requests per second.
> •  Average 200-300 connections per second. Spiking to 800 connections  
> per second.
> •  MySQL handled 2,400 requests per second.
> •  180 Rails instances. Uses Mongrel as the "web" server.
> •  1 MySQL Server (one big 8 core box) and 1 slave. Slave is read only  
> for statistics and reporting.
> •  30+ processes for handling odd jobs.
> •  8 Sun X4100s.
> •  Process a request in 200 milliseconds in Rails.
> •  Average time spent in the database is 50-100 milliseconds.
> • Over 16 GB of memcached.
>
> Cheers,
> Bob
>
>
>
> > Some more commentary on this issue:

> >http://www.alexhopmann.com/2008/05/12/twitter-ruby-on-rails-and-scala...