Will RoR Scale?

rubyonrails-talk
1

I'm trying to decide which path to go down for developing a new web app. Scalability in the long run is a huge requirement, but without sacrificing the development time.

The rails community is huge, there's support everywhere, documentation is fantastic, but I keep hearing things from others about how if we use rails we're not going to be able to scale.

Some have said Rails is great for prototyping, but going to production it's going to fail. The largest sites out there never use Rails. I believe Twitter tried and failed. I'm not sure what they ended up doing though.

I really want to develop using RoR, but I'm hesitant because of the scale factor.

Can anyone give me some information concerning this?

Thanks!

2

I'm trying to decide which path to go down for developing a new web app. Scalability in the long run is a huge requirement, but without sacrificing the development time.

The rails community is huge, there's support everywhere, documentation is fantastic, but I keep hearing things from others about how if we use rails we're not going to be able to scale.

Some have said Rails is great for prototyping, but going to production it's going to fail. The largest sites out there never use Rails. I believe Twitter tried and failed. I'm not sure what they ended up doing though.

Twitter is still using rails.

Fred

3

also large sites like Revolution Health are using rails

I think that if you're smart about your use of the DB, if you use caching, etc you can get pretty far.

...but I also wonder about this

4

Do you think the troubles Twitter were realizing was just a well advertise demise while all the others go through just as much scaling problems?

In short, would scaling be less of a problem with a PHP framework like Symfony?

I think the reason why not many of the larger sites are using RoR is because it's so new. And twitter was the newest one to go big, and because of the quick development, maybe they staggered into the scaling problems early?

I've read a ton of articles this afternoon, and they all say how much more processing power Ruby uses, and that scaling is seemingly more complicated.

5

-kinetic wrote:

I've read a ton of articles this afternoon, and they all say how much more processing power Ruby uses, and that scaling is seemingly more complicated.    Usually people writing these articles never had any real application to scale themselves.

Sure, some applications might have better performance on a single box with Java in a micro-benchmark because they are CPU bound and Java is much faster than Ruby (now) for CPU intensive processing but this has nothing to do with scaling as most people mean it which usually is : "go beyond the point where your application can fit on a single server and get more performance by adding pizza boxes".

So saying that an application framework scales more than another is pure bulls**t. Every modern web framework uses a "share-nothing" approach to solve scalability problems so about anyone can scale by adding application servers today.

When anybody comes to the point where the only shared component becomes a bottleneck (usually the relational database but might be filesystems, LDAP servers, network, whatever) scaling is a matter of architecture and solving the bottleneck is specific to the application not a problem the framework can come with a solution for.

The problem is that the "share-nothing" term is misleading: you always share something and this is what comes back to bite you when your application is under stress. You'll need one(/several) good specialist(s) to find the bottlenecks and re-architecture your application when the problem arises.

For example, I recently had to spend some time optimizing some parts of one Ruby process that was getting slower. After I finished, on the same hardware the application was 10 times faster. Turns out that some database queries weren't optimal, the database lacked some indexes and PostgreSQL 8.0 was much slower than 8.2. Ruby didn't have anything to do with it. I'm pretty confident that even if I spent the rest of my life recoding this application from Ruby to raw assembler I wouldn't get more than a 10% speedup and a ton of bugs.

In the software industry believing that software in a shiny box will solve your problems is amateurism: people solve your high-level problems using tools, the tools are only meant to low-level ones like minimizing the time spent coding simple tasks and providing easy access to lots of libraries from which to extend your application as quickly as possible (in fact most of them probably create more problems than they solve :slight_smile: ). So if you have problems to solve, I suggest you look for bright people who know how to solve them, not bright software, as bright software is only a marketing myth...

Whow, looking at what I just typed it seems I was tired of coding and needed to vent a bit :slight_smile:

Lionel

6

The fact that Ruby uses more processing power is actually irrelevant to the scalability of a RoR app. Scalability is "how effectively the system architecture can grow in proportion to increasing demand." (The Rails Way by Obie Fernandez). The important thing is your algorithms, not the language they are written in.

If your algorithms are well written, then you can hopefully just double the number of servers when you double your users. This isn't always possible, but that has nothing to do with Ruby and everything to do with the complexity of the business problem at hand.

So if you write it in PHP, you might need to buy a new $1000 server for every 100 new users. If you write it in Ruby, then you might need to spend $1200 (or even $2000, but not likely) for the server that supports 100 users. So if you have 1,000,000 users, in PHP you'd need 100 servers X $1000 equals $100,000. In RoR you'd need 100 servers X $1200 equals $120,000. You spend more on hardware, but far less on software development and maintenance.

I think part of why people still wonder if Rails can scale is that there are many parts of ActiveRecord that put simplicity before performance. There are 1000s of projects using rails that don't need high performance so I think this is a great decision. It is also a rails convention (or maybe best practice) to not pre-maturely optimize. That means it is ok to have unscalable algorithms when you don't have tons of users--start by keeping your code simple. Ruby (and the good practices that the rails community encourages) makes refactoring pretty easy.

Cheers,

7

Interesting article on Twitter:

8

Agreed. This issue of scalability is much more an issue of application design than anything else. If you make good design choices, taking into account things like caching, background processing, etc up front, you'll be able to scale. But those design decisions will exist in every framework you choose.

The main advantage that you'll get in RoR iss in the code base. Well- written Ruby code is more expressive than most other languages and consequently tends to be easier to maintain. Similarly, the power of the language itself tends to reduce the number of lines of code that are required. I recently read of an application (forget the name... maybe YellowPages.com?) that reduced its code base from 200K+ LOC to around 120K. If you're like me, less is better... less to break, less to remember, less to archive.... Also, the goal of Matz in designing Ruby was to make programming enjoyable, even fun. Ask any hardcore RoR developer and i think you'll find general agreement that he's achieved his goal. Writing in Ruby is fun.

One other note, the latest version of Ruby (1.9.x) had performance as its primary target. Rumors are that there has been significant gains across the board. Part of the Rails core is working towards Ruby 1.9 compatability so we should see that fairly soon (maybe at RailsConf?). Soon you may not be shouting back to Scotty for more power...

9

Wow, great information everyone.

My app needs to scale to hundreds of thousands of users per day to a million or so. The numbers are ideal, but as all engineers say, you must prepare for the worst, and you must prepare for the best.

There's a huge need to develop the application with scaling in mind every step of the way. Ruby on Rails seems to skim over that initially, and just have you develop quickly and efficiently. Would you recommend using RoR for something like this? The trade off might not be worth it?

Thanks again!

10

I could write a lot, to answer this question, but Chris @TheKeyboard has phrased it very simple and beutiful:

http://www.littlehart.net/atthekeyboard/2007/01/02/just-build-it-damnit/

- Carsten

11

In my view all this talk of scalability is premature. People plan for a million users from start and that is a premature optimization. It’s much easier to do the site in Rails and when bottlenecks become a pain scale like this

  1. Optimize using fragment/page cahing, server static files from apache, profile and optimize the code(check for N+1 bugs and stuff)
  2. Optimize the SQLs. Use ‘explain’ on your mysql queries and see how much you can optimize.
  3. Use more mongrels, write mongrel handlers for slow requests(or requests which depend on 3rd party servers like fetching rss feeds et al)
  4. Use memcache servers to cache the queries for data that queried a lot.
  5. Add more application servers
  6. Write cpu intensive functions in C and add a ruby wrapper for these
  7. Cluster you database servers

I run a few sites which serve upto 100-150k requests per day much of the above(1 app server, 2 mongrels, 1 db server and step 1). Scaling upto 1 million with all the above steps should not be a big problem)

Piyush

12

My app needs to scale to hundreds of thousands of users per day to a million or so.

It need right now? Or you think it will need? There is a big difference here. Some wisdom from the 37 signals:

Regards, Rimantas

13

My app needs to scale to hundreds of thousands of users per day to a million or so. The numbers are ideal, but as all engineers say, you must prepare for the worst, and you must prepare for the best.

That's not really a useful question. For example... my site has 10 million users (it doesn't but let's pretend :slight_smile: but they only visit once a month. Or, perhaps I have 10,000 and they visit my site 5-6 times a minute each.

You need to look at how many requests you are going to get over a day, or an hour, what your peaks are, how much *traffic* you have to be able to sustain during those times.

That all said... I agree with everyone else... just build it :slight_smile:

14

I've read a ton of articles this afternoon, and they all say how much more processing power Ruby uses, and that scaling is seemingly more complicated.

RoR is a LAMP system. The P stands for an interPreted language, and the M stands for MySQL.

Write developer-friendly code with the P, and put the M on another server. If the P gets slow, put more servers under it. This system allows you to optimize developer time, while keeping the potentially slowest part of the system - MySQL - on a dedicated server.

15

Um, LAMP actually stands for something more along the lines of Linux, Apache, MySQL, and Perl/PHP. RoR can run on Windows, Linux, or Mac and can use any of quite a few databases. Some (maybe many) choose MySQL. I don't. I use PostgreSQL.

Peace, Phillip

16

You guys interested in scaling with RoR might be interested in

http://blog.caboo.se/articles/2007/7/29/scale-rails-from-one-box-to-three-four-and-five

Basically covers how to scale and the steps to take.

17

I could write a lot, to answer this question, but Chris @TheKeyboard has phrased it very simple and beutiful:

http://www.littlehart.net/atthekeyboard/2007/01/02/just-build-it-damnit/

That post is good advice, in general, but it starts from a premise that is never explicitly mentioned -- that the site you are building is new. While it's refreshing when clients ask for something brand-spanking-new, the work is more likely to be "do exactly what my site already does, plus this set of additional features."

In that case, the traffic is already coming to the site. If you're lucky, the traffic is light enough that you can still ignore scaling issues while you're developing the new Rails app to replace the existing whatever app. On the other hand, the client may be coming to you to reimplement their site because it is getting slow and they want you to create the new one so you can be responsible for scaling it.

This may not be the most common Rails project, but such work is definitely out there. It means that, yes, you need to think about scaling from the start. You don't have the luxury of a gradual user uptake to see where the bottlenecks are, because the moment your new site goes live you have a full user base (see below for a way around that). You need to address problems before they happen, because downtime and slowness are not just growing pains but regressions that the client will be justifiably screaming about.

I'd be interested in some thoughts toward handling the situation starting from that premise, where "just build it, damnit (sic)" doesn't apply.

As an example, one can play tricks with a frontend server to put some segment of the user base on the new system while leaving the majority on the old to simulate a gradual user uptake. Of course, that may not be feasible depending on the particular site's functionality. Consider Twitter, for example, where the users' interaction with one another is central to the site.

- Carsten

--Greg

18

No difference: just build it, damnit; scale to meet traffic demands; launch.

You're going to have more trouble with integration and compatibility, anyway.

Iteratively, jeremy

19

Bingo. People who worry too much about scaling off the bat never get their projects launched.

Make something worthwhile first, scale it when necessary.

20

Gregory Seidman wrote:

[...] In that case, the traffic is already coming to the site. If you're lucky, the traffic is light enough that you can still ignore scaling issues while you're developing the new Rails app to replace the existing whatever app. On the other hand, the client may be coming to you to reimplement their site because it is getting slow and they want you to create the new one so you can be responsible for scaling it.

This may not be the most common Rails project, but such work is definitely out there. It means that, yes, you need to think about scaling from the start. You don't have the luxury of a gradual user uptake to see where the bottlenecks are, because the moment your new site goes live you have a full user base (see below for a way around that). You need to address problems before they happen, because downtime and slowness are not just growing pains but regressions that the client will be justifiably screaming about.

I'd be interested in some thoughts toward handling the situation starting from that premise, where "just build it, damnit (sic)" doesn't apply.    If it is getting slow you can check out the whole architecture to find out where the bottlenecks are and rebuild it accordingly. As I already said, when you have performance problems you need people knowledgeable enough to find out why, the framework itself is only a tool that might need some tuning (or not).

Lionel