GCN Tech Blog

By GCN Staff

Blog archive

Ruby's easy but Java is quicker

For this week's print issue, we did a big story on the Java-based scripting languages. Over the past few years, Web application developers have been gravitating towards scripting languages such as Ruby on Rails and PHP, which allow them to quickly ramp-up applications.

The received wisdom around these languages, and the frameworks they operate under, is that they can not match the performance of an application running off of Java Enterprise Edition, which, after, was built expressly for multi-thread environments. (And this is why the scripting languages like Groovy that can run on the Java Virtual Machine are such good news: They combine the speed of the Java platform with the ease of the scripting languages).

In any case, it turns out that this perception about scripting-based applications running slower is correct'at least according to tests carried out by Sun engineers.

Sun Microsystems senior performance engineer Tom Daly and Sun engineer Damien Cooke recently compared the performance of Ruby on Rails and Grails (a rapid development environment for Groovy) against a typical Java Enterprise Edition-based deployment. They discussed their findings at the recent JavaOne conference, held in San Francisco last month.

They found that Ruby on Rails could not match the performance of JEE 5, nor could Grails, though it fared slightly better. They did concede that both Ruby and Grails were easier to work with though.

For the tests, the duo built three identical applications, a software support registration system called RegPerf. One version was written in Ruby on Rails, one in Grails and one using Java EE 5. This Web application, tied to a PostGres database, allowed users to create, update and delete data. They two engineers installed their software on a Sun Solaris server with four Advanced Micro Devices Opteron CPU's and 8GB of memory. To simulate a whole bunch of users interacting with the software, they used Faban, a Sun open source load-testing generation tool.

Here's how the platforms fared: The Ruby on Rails deployment was able to execute about 2,000 operations per second (such as reading a database entry, or refreshing the Web page), whilst serving 100 users simultaneously. Grails executed just over 3,250 operations per second for 100 users. And JEE 5 trumped both of the others, executing almost 11,000 operations per second with 100 users.

As the load grew to 500 users, the performance of all three slipped, as expected. When 500 simulated users hit the Ruby on Rails system, the server was only able to execute a little over 1,250 operations per second. Grails shrank to something over 2,500 users and JEE5 slipped to about 5,500 operations per second. (Note: the numbers are wrong in the presentation materials on the JavaOne site).

The Java EE deployment also seemed to utilize the processors less than either Ruby on Rails or Grails.

While these tests showed JEE 5 seems to be the fastest performer, Daly did show that setting up an application in JEE 5 takes considerably more work than in does with either Ruby on Rails or Grails. It still may make sense to use Ruby on Rails or Grails to set something up quickly, though if you expect your Web application to be used heavily, it might be better to spend the additional time to deploy the application in Java EE, he said.

"Frameworks are great for doing quick integration stuff, for getting going very quickly. But will they scale up? What is the maintainability like? Those are the questions to ask," Daly said.

Daly stressed that the tests were not proper benchmarks, because each of the configurations ran without tuning. Rather the team did this exercise in order to show how users could set up their own tests when thinking about which framework to deploy.

Posted by Joab Jackson on Jun 20, 2007 at 9:39 AM

inside gcn

  • When cybersecurity capabilities are paid for, but untapped

Reader Comments

Fri, May 7, 2010 JB Philadelphia, PA

I'm only posting this because for some reason this article comes up first for a google search on "ruby on rails in government". This article seems highly biased. The people who make Java are obviously going to say Java is better. Also, the benchmark utility used to generate the numbers is also made by the people who make Java. Ruby on rails is used on several extremely high traffic sites and fares just fine with hundreds of millions of page hits. Also "operations per second" doesn't mean anything. The numbers represented don't seem to represent any kind of real world usage of the webapps. Also, "tuning" is the least of your worries with a benchmark like this. You haven't taken into account the overall architecture of each platform -- they're vastly different and there are way more variables at play than simple "tuning". Finally, you seem to think that ruby is a "scripting" language and that java is not. The line is very blurry. There are various implementations of ruby -- including one that is compiled into bytecode and run on a vm (parrot). This is exactly like how java is compiled into bytecode and run on the jvm.

Please post your comments here. Comments are moderated, so they may not appear immediately after submitting. We will not post comments that we consider abusive or off-topic.

Please type the letters/numbers you see above


HTML - No Current Item Deck
  • Transforming Constituent Services with Business Process Management
  • Improving Performance in Hybrid Clouds
  • Data Center Consolidation & Energy Efficiency in Federal Facilities

More from 1105 Public Sector Media Group