JRuby on Rails in Production: Lessons Learned From Operating a Live, Real-World Site

Nick Sieger, a former Java developer who is now JRuby team member and Kenai.com lead developer at Sun, gave a presentation titled JRuby on Rails in Production: Lessons Learned From Operating a Live, Real-World Site (TS-5413). The team used Project Kenai (pronounced KEEN-eye) as a case study for constructing and operating a live site built with the Ruby-on-Rails web framework, and running on JRuby, the GlassFish application server, while using the JVM* for deployment.

The Project Kenai web site calls Kenai "Sun's new foundation for its connected developer experience of tomorrow" and invites developers to "freely host [their] open source projects and code as well as find and collaborate with developers of like mind and passion." Kenai.com offers a broad and continually growing feature set that includes a variety of projects, wikis, forums, mailing lists, issue trackers, source code repositories, and APIs.

The TIOBE Index, which uses major search engines to calculate and rate the popularity of programming languages, shows Ruby at #10 in popularity as of May 2009, unchanged in the past year -- in fact, largely unchanged since early 2007.

JRuby is part of a larger effort to deploy the flexibility, interoperability, and sheer power of the Java platform to enhance the power of the Web by opening the JVM to new languages. Users can create rich interactive web sites more rapidly and maintain them more easily by using JRuby to leverage the strengths of Java technology and Ruby. Sun's Da Vinci Machine project, also called the Multi Language Virtual Machine Project, is extending the JVM with architectural support for languages other than the Java language, with a focus on dynamic languages.

Sieger began with a description of the initial Kenai.com strategy. "Early on in building Kenai.com, we decided to put each piece in a box and let everyone go off and work on their box and then come together and share our creations," said Sieger.

It sounded great, but it didn't work.

"If you send people off without team communication about what you're building, then the pieces may not fit together. We were building RESTful interfaces around each box, but they were not of the granularity that users needed. And we were trying to build the web UI (user interface) on top of RESTful web services, so the UI did not talk to the database directly. It was an interesting concept, but it was not practical."

In its earliest phase, Kenai.com confronted several challenges:

• Too much data was being pulled over the wire.
• The bottom-up service design didn't bear fruit.
• UI usage patterns did not match APIs.
• There were speed-up problems from collapsing white space in XML, and the data itself on the wire was too verbose.

As a consequence, Kenai.com needed a more traditional model, so the team settled on an HTML web application talking to a database. Team members wrote the UI in Ruby on Rails, but they wrote the service control tools and mailing lists on different stacks.

"Once we scaled back and settled into building a web application leveraging Rails strength, we saw the benefit," said Sieger. "You will not find a lot of web frameworks that allow for the ease of integration that Rails offered for such diverse features."

Ruby on Rails offered:

• A built-in caching framework
• Multiple layers: page, action, fragment, and object
• Pluggable stores: memory, file, and memcached

Sieger summed up the basic Ruby-on-Rails message:

• Impactful features can be added quickly.
• It offers a healthy gem and plug-in ecosystem.
• It offers rapid innovation and a creative community.

"Rails is fully integrated and the barriers are low for each feature implemented," explained Sieger. "The learning curve is short and small, so the system can be built out relatively quickly -- even if you have little experience developing with Rails."

"You can leverage community plug-ins and go to blog posts to see how people are solving similar problems. The innovation in the community is rapid, providing great benefit to all."

The Kenai.com code base has:

• 12,000 lines of application code
• 10,000 lines of views (HTML + template code)
• 1000 lines of JavaScript
• 8000 lines of test code
• 73.7 percent test coverage

For hardware, the Kenai.com team relied on the Sun Fire T2000 server, which has these features:

• A 1.2 GHz UltraSPARC T1 processor with 8 cores
• 32 hardware threads
• 32 GB RAM

The server can be slow, but it can handle a big load. In addition, many 32-bit JVMs can run in the 32 GB RAM space offered by the Sun Fire T2000 server.

The software stack consists of the following:

• OpenSolaris Nevada
• Apache
• GlassFish
• Subversion
• Python, Mercurial, Django
• Perl, SYMPA
• Postfix
• Memcached
• MySQL
• Solr
• Git
• Kestrel
• Puppet

Because the use of OpenSolaris Nevada and SPARC resulted in no Image Packaging System (IPS), Sieger initially relied on CoolStack, Web Stack, and Blastwave for package maintenance. But "it became a nightmare trying to manage different versions. As a result, we started building things from scratch."

In working on Kenai, Sieger himself made significant contributions to the Rails community. "I had a chance to write a tool called Warbler, which takes a Rails application and builds a web archive (WAR) file out of it with little intervention required," he explained. "A configuration file can be used to tell Warbler what parts of your Rails application you need to have available. It's intuitive, straightforward, easy to extend, and has been well received."

A piece of software inside Warbler is JRuby-Rack, which provides integration glue for converting servlet requests into Ruby web application requests. JRuby Rack is a servlet filter that takes control of booting up the Rails application, keeping the apps warm and ready to serve requests.

It then intercepts requests at the outer edge of your application and passes them through in case they need to be handled. Failing that, JRuby-Rack passes them through to Rails.

Initial results from load testing in late 2007 and early 2008 were poor: They received the java.lang.OutOfMemoryError: PermGen space error, along with crashing VMs and low CPU utilization. Sieger's team capped the amount of code generation from JRuby down to reasonable thresholds, thus fixing the PermGen error. The team improved CPU utilization by running more VMs.

Sieger closed with some general conclusions. He reminded attendees of the strengths of Java technology as a stable platform for servers, but said that not everything can or needs to be built using the Java platform. He pointed out that although Rails may appear to be flashy and overhyped, it is in fact highly productive and has the support of a rich, innovative, and fun community.

He characterized JRuby as an excellent community that bridges technologies: It marries the best of both worlds and provides greater choice between Java and Ruby libraries. He encouraged developers to broaden their horizons and try out alternative languages.

Sieger concluded that, with the constant improvements in tooling, Java developers have every reason to branch out and enhance their skills.

_______
^* As used on this web site, the terms "Java Virtual Machine" and "JVM" mean a virtual machine for the Java platform.

» Nick Sieger's Blog
» Project Kenai
» JRuby
» Ruby on Rails

Do you have comments about this article? We welcome your participation in our community. Please keep your comments civil and on point. You may optionally provide your email address to be notified of replies - your information is not used for any other purpose. By submitting a comment, you agree to these Terms of Use.