Ruby's easy but Java is quicker
Connecting state and local government leaders
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.
NEXT STORY: New network processors aid computing centers