eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
What’s the matter with Ruby and Ruby on Rails for building large, scalable applications? According to the folks at Engine Yard, absolutely nothing.
San Francisco-based Engine Yard, which provides a hosting environment for Rails applications, is actively working to prove that Ruby is a viable language for and Ruby on Rails is a totally viable Web development framework for building high-volume applications. Ruby on Rails is a Web development framework written in the Ruby language.
Most recently, the team at San Francisco-based Engine Yard has been able to run Rails applications on the Rubinius virtual machine, a small feat.
“Rubinius is able to run some simple Rails apps and we’re scaling our capabilities to run all Rails apps,” said Evan Phoenix, a software architect at Engine Yard and founder of the Rubinius project, in an interview with eWEEK on May 20. Phoenix started the project in 2006 as a new Ruby interpreter.
In a blog post from May 17, Phoenix wrote: “We hit a major milestone tonight. As most people know, we’ve been working to run Rails on Rubinius by RailsConf to have something to show off, even if it’s pretty slow. Well, I’m super proud to say that tonight, rails served up both static and dynamic pages under Rubinius.” RailsConf is set for May 29-June 1 in Portland, Ore.
Ruby Is Not a Toy
The ability to run Rails applications on Rubinius “marks that Rubinius is evolving and is going to be a major player,” Phoenix said. “It’s not a toy.”
Meanwhile, in a May 20 blog post, Antonio Cangiano, a software engineer and technical evangelist at IBM, said: “Once long ago, at the time of my first shootout when Rubinius was a very young project and performed poorly, I had an email exchange with Evan Phoenix and I told him, ‘I secretly think that your project may become the most interesting implementation of Ruby.’ I stick to that conviction. As long as they manage to improve performance to the point of being as fast as Ruby 1.9, they have a shot at becoming the most popular Ruby VM.”
Ezra Zygmuntowicz, another Engine Yard software architect and an expert at scaling Rails applications, said, “Rails is the largest, most complex piece of Ruby code; it’s like the benchmark.”
David Heinemeier Hansson, the creator of Ruby on Rails, told eWEEK: “Rubinius running Rails is a great milestone for the former. Rails takes full advantage of most all features in the Ruby language and thus if you can run Rails successfully, you can probably run most Ruby applications successfully. Running a Rails application (like ‘Hello World’) and running all Rails applications is not the same thing, though. I believe it took JRuby almost a year to go from one state to another. For the community at large, it’s great to see another implementation of Ruby grow. Soon we’ll have three good options to run Ruby programs-the original C-implementation by Matz [Yukihiro Matsumoto], Koichi [Sasada] and the rest of the Japanese crew; JRuby by the Sun folks; and now Rubinius. Good stuff.”
Deploying Rails Applications
The goal of Rubinius, said Phoenix, is to write an environment that is much more open and to build a better Ruby environment in terms of performance, execution speed and such features as garbage collection.
“As we see more adoption of the language it’s time for us to start to grow up the environment a little,” Zygmuntowicz said.
Engine Yard has “solved a lot of these problems over and over again,” including issues of scaling Ruby and Ruby on Rails applications, said Ezra Zygmuntowicz. He recently co-authored the book “Deploying Rails Applications,” which provides tips on scaling Rails applications.
According to a description of the book by its publisher, O’Reilly Media, “Until now, the information you needed to deploy a Ruby on Rails application in a production environment has been fragmented and contradictory. This book changes all of that by providing a consistent, level-headed book containing advice you can trust. You’ll get the inside angle from those that have built, deployed, and maintained some of the largest Rails apps in production, anywhere.”
Zygmuntowicz said of the book: “It helps with starting off with Rails all the way up to scaling to clusters and multiple MySQL instances.”
Regarding claims that Rails doesn’t scale and that the popular Twitter social networking and messaging application is suffering outages and problems because of Rails scalability issues, Zygmuntowicz said: “Mostly that’s kind of BS. You just have to architect properly for it. In most Rails applications the database becomes the bottleneck before anything else.”
Moreover, “There’s no language that scales; languages don’t scale, architectures do,” he said.
“Twitter’s problems have nothing to do with Rails,” Zygmuntowicz said. Twitter is “right down the block” from Engine Yard in San Francisco’s South Park neighborhood, and he said he has worked closely with Twitter engineers and has seen the issue firsthand.
Scaling Rails
To initially scale Rails applications, Zygmuntowicz said, “You have a number of Rails application processes behind a load balancer, so to scale you add more servers and application processors.” Yet, the problem with Rails is “with the database becoming a central point of contention.”
However, the first way to get around that is to “get a bigger database box, which is scaling vertically,” Zygmuntowicz said. “Next is to add a couple of slave databases that replicate all the data written to the master,” but that doesn’t cure all ills, he said.
“Twitter scaled their database to as big a box as they could get, but they have so much data being written all the time that they have a hard time keeping up,” Zygmuntowicz said. They also have a “sharded database” to scale horizontally to many databases, which helps alleviate some of the strain on the system.
“In general, I host many large applications with 4 million to 5 million transactions a day, and Rails scales just fine,” Zygmuntowicz said.