# Scaling Ruby on Rails (and related Slashdot article today) **URL:** \ **Category:** Rails\ **Created:** [September 23, 2007, 9:17pm UTC](https://www.ruby-forum.com/t/scaling-ruby-on-rails-and-related-slashdot-article-today/115322 "2007-09-23T21:17:08Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![forrie](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/f/dc4da7/32.png) [@forrie](https://www.ruby-forum.com/u/forrie)\ **Post date:** [September 23, 2007, 9:17pm UTC](https://www.ruby-forum.com/t/scaling-ruby-on-rails-and-related-slashdot-article-today/115322/1 "2007-09-23T21:17:08Z")
I presume most people here read today’s article on Slashdot which had some critique about Ruby and scaling to a large architecture. Though the article didn’t seem to elaborate into specifics, I’m interested in other people’s feedback and perspective on this. I’m currently learning Ruby. One of the first questions I had (and Googled for) had to do with scalability, for large enterprise-class applications. I found a couple of articles, but haven’t yet tested this in a lab setting. Then there is Parrot, which I’ve not used yet. Due to the growing popularity of Ruby and Rails, I would imagine this would be of importance. Pardon if I’ve missed something (I have searched, and am searching) - that being the case, URLs to articles would be appreciated. Also how would such any approaches differ from that of how JAVA scales with VM. Thanks! ---
**Author:** ![forrie](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/f/dc4da7/32.png) [@forrie](https://www.ruby-forum.com/u/forrie)\ **Post date:** [September 23, 2007, 10:17pm UTC](https://www.ruby-forum.com/t/scaling-ruby-on-rails-and-related-slashdot-article-today/115322/2 "2007-09-23T22:17:26Z")
On Sep 23, 12:16 pm, forrie [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > Due to the growing popularity of Ruby and Rails, I would imagine this > would be of importance. Pardon if I’ve missed something (I have > searched, and am searching) - that being the case, URLs to articles > would be appreciated. > > Also how would such any approaches differ from that of how JAVA scales > with VM. > > Thanks! I haven’t read the Slashdot article yet – I _seriously_ doubt that there’s any new information in it, however. Here’s _my_ view of the subject. 1. The Ruby 1.8 interpreter, aka MRI, does have some bottlenecks in it that could be alleviated. Most notable in the context of Rails are the garbage collector and method dispatch. 2. ActiveRecord also has some bottlenecks in it that could be alleviated. I’m not at all familiar with them, but there are folks on this list actively working on them and I trust that they will pipe up and respond, assuming that their work is open source. 3. There are several alternative implementations of Ruby 1.8, pretty much all of which have improved Rails performance as a goal. The farthest along is jRuby, an implementation of Ruby on the Java Virtual Machine. The next farthest along is IronRuby on the Microsoft Dynamic Language Runtime, followed very closely by Rubinius. Parrot appears to have fallen behind, although I would hope a pleasant surprise will emerge from that camp. 4. Finally, Ruby 1.9 is due out the end of this year. I haven’t seen any _Rails_ benchmarks for it yet, but for other benchmarks, Ruby 1.9 kicks serious butt. So … watch this space … I’ll go read the Slashdot article. ---
**Author:** ![forrie](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/f/dc4da7/32.png) [@forrie](https://www.ruby-forum.com/u/forrie)\ **Post date:** [September 23, 2007, 10:56pm UTC](https://www.ruby-forum.com/t/scaling-ruby-on-rails-and-related-slashdot-article-today/115322/3 "2007-09-23T22:56:31Z")
On Sep 23, 1:16 pm, znmeb [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > On Sep 23, 12:16 pm, forrie [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > > > I presume most people here read today’s article on Slashdot which had > > some critique about Ruby and scaling to a large architecture. Though > > the article didn’t seem to elaborate into specifics, I’m interested in > > other people’s feedback and perspective on this. > > So … watch this space … I’ll go read the Slashdot article. OK … I went to Slashdot and all I found was a pointer to a blog post where the proprietor of CD Baby described how and why he moved from PHP to Rails and back again. > **[O'Reilly Media - Technology and Business Training](https://www.oreilly.com)** > > Gain technology and business knowledge and hone your skills with learning resources created and curated by O'Reilly's experts: live online training, video, books, our platform has content from 200+ of the world's best publishers. But I didn’t see anything about scaling. ---
**Author:** ![forrie](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/f/dc4da7/32.png) [@forrie](https://www.ruby-forum.com/u/forrie)\ **Post date:** [September 23, 2007, 11:46pm UTC](https://www.ruby-forum.com/t/scaling-ruby-on-rails-and-related-slashdot-article-today/115322/4 "2007-09-23T23:46:48Z")
Rails is just a conventional architecture with a web front end and a database backend. As with all such systems, the biggest challenge is the database layer. As usual, the key is to make the app read-heavy and build multiple readonly slaves. Brutally cut out all unecessary writes. For example, if you’re using the db to log impressinos, clickstream, etc., that’s gotta go - either to a different db or using lazy logging (e.g. syslog, udp fire and forget). [I posted earlier, haven’t heard back yet: Which is better: acts\_as\_readonlyable or mysql-proxy or other?] In practice, the AJAX part of a Rails application (or any other web-app) is what can make or break scalability: If every click, drag, etc. leads to db updates and inserts (for example: resequencing a list by dragging and dropping an element -\> update for each element of the list), then clearly the app will not scale. On the other hand the AJAX layer could actually help scalability by making such updates less frequently than a non-ajax app. m ---
**Author:** ![forrie](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/f/dc4da7/32.png) [@forrie](https://www.ruby-forum.com/u/forrie)\ **Post date:** [September 24, 2007, 12:27am UTC](https://www.ruby-forum.com/t/scaling-ruby-on-rails-and-related-slashdot-article-today/115322/5 "2007-09-24T00:27:51Z")
On Sep 23, 2:46 pm, “Marc B.” [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > In practice, the AJAX part of a Rails application (or any other web-app) is > what can make or break scalability: If every click, drag, etc. leads to db > updates and inserts (for example: resequencing a list by dragging and > dropping an element → update for each element of the list), then clearly > the app will not scale. On the other hand the AJAX layer could actually > help scalability by making such updates less frequently than a non-ajax > app. It isn’t just the database interactions you have to watch out for with Ajax. You also need to pay attention to a. Network traffic, number and size of network interactions with the server, and how these interplay with WAN bandwidth from the client to the server. Now of course, _everybody_ has at least 10 mbits download and 768 kbits upload speed that uses _your_ app. 🙂 b. Client-side processor and RAM resources. Now of course, _everybody_ has a 2 GB dual-core 2 GHz PC that uses _your_ app. 🙂 In short, test driven development _must_ include load and scalability testing using _realistic_ network bandwidth and full client user interface testing. ---
**Author:** ![forrie](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/f/dc4da7/32.png) [@forrie](https://www.ruby-forum.com/u/forrie)\ **Post date:** [September 23, 2007, 11:03pm UTC](https://www.ruby-forum.com/t/scaling-ruby-on-rails-and-related-slashdot-article-today/115322/6 "2007-09-23T23:03:34Z")
On Sun, 23 Sep 2007 19:16:26 -0000, forrie wrote: > I presume most people here read today’s article on Slashdot which had > some critique about Ruby and scaling to a large architecture. I didn’t see any critiques about scaling Rails to a large architecture… it was an article by Derek of CDBaby, saying how he finally gave up trying to port his existing PHP application to Rails, and went back to PHP. Nothing about scaling at all - just that (a) Rails can’t do anything PHP can’t do (which is true for any two languages, really), and (b) he had to reinvent large parts of Rails to get it to do what he wanted, and (c) migrating an existing application to a new framework is a pain, and doubly so with Rails which likes to make a lot of assumptions about how data is laid out. All true. Back to scaling: The honest truth is that very few Rails sites have grown to the point where they have to worry about scaling in an enterprise-y sense. Some of the larger sites have dealt with multiple front-end web servers. Some of the very large sites have dealt with read-only database replication to multiple back-end servers. Twittr, probably the largest, has faced their own unique issues. But there aren’t a lot of AOL/Google/eBay/Amazons in the Rails world. Part of it is that Rails sites tend to be database-y, not message-y. There’s not a lot of shared state and concurrency, which is always the fun part of scaling. Part of it is that Rails is (a) relatively new and (b) not good for porting existing sites; therefore, very little written in Rails has had the time to go from zero to Amazon. The 1.8 ruby interpreter, as znmeb said, is fairly slow. JRuby is catching up to it, and in some cases exceeding it, and you can run JRuby-on-Rails today. And over the next year, there will be even more options. Only you can know if the interpreter speed of the front-end web server is going to be a bottleneck in your site. Here are some helpful Google terms to research Rails scaling: evented mongrel nginx pound twittr joyeur engineyard multiple-databases – Jay L. | Boston, MA | My character doesn’t like it when they Faster: jay at jay dot fm | cry or shout or hit. [http://www.jay.fm](http://www.jay.fm) | - Kristoffer ---
**Author:** ![forrie](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/f/dc4da7/32.png) [@forrie](https://www.ruby-forum.com/u/forrie)\ **Post date:** [September 24, 2007, 6:04am UTC](https://www.ruby-forum.com/t/scaling-ruby-on-rails-and-related-slashdot-article-today/115322/7 "2007-09-24T06:04:04Z")
Is there a good place to go to learn more about designing scalable apps in general and rails apps in particular? ---
**Author:** ![forrie](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/f/dc4da7/32.png) [@forrie](https://www.ruby-forum.com/u/forrie)\ **Post date:** [September 24, 2007, 7:12am UTC](https://www.ruby-forum.com/t/scaling-ruby-on-rails-and-related-slashdot-article-today/115322/8 "2007-09-24T07:12:44Z")
On Sep 23, 9:04 pm, Dave S. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > Is there a good place to go to learn more about designing scalable apps > in general and rails apps in particular? Well … I would start with this book: _Performance Solutions: A Practical Guide to Creating Responsive, Scalable Software_, Dr. Connie U. Smith and Dr. Lloyd G. Williams ---
**Author:** ![forrie](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/f/dc4da7/32.png) [@forrie](https://www.ruby-forum.com/u/forrie)\ **Post date:** [September 24, 2007, 10:01am UTC](https://www.ruby-forum.com/t/scaling-ruby-on-rails-and-related-slashdot-article-today/115322/9 "2007-09-24T10:01:16Z")
Dave S. wrote: > Is there a good place to go to learn more about designing scalable apps > in general and rails apps in particular? Joyent’s slides by Jason Hoffman on “Scaling Rails Applications from the Bottom Up” provide a nice peek into the matter too. As for the Slashdot article: I’ve read it with interest, but have found it to be mostly lacking in detail. There’s definite proof out there that Rails has excellent scalability properties due to its statelessness, process-based orientation and distributed session stores. That he found that rewriting an application into another language gives diminishing returns is of course nothing new. That “cold turkey” approach seldom has good payback rates. For one thing, the investment into building the same thing over again is a steep one. Then secondly, the maturity of the rewritten application is by definition lower than that of the existing application that has stood the test of time and got most bugs ironed out. Again, I think it’s good to not lose ourselves in our Rails evangelism and actively play the devil’s advocate, but that particular posting didn’t particularly sway me. – Roderick van Domburg [http://www.nedforce.com](http://www.nedforce.com)