InfoQ

News

Rails Caching Reloaded With EHCache

Posted by Sebastien Auvray on Aug 20, 2008 03:54 AM

Community
Ruby
Topics
JRuby ,
Ruby on Rails
Tags
Caching ,
JRuby
Rails 2.1 brings new caching features which makes it very easy to cache any values including models. Apart from the basic File, Memory and DRb stores, Memcached was the only solution to do shared memory cache. (J)RoR can now count on the popular Java distributed cache EHCache as part of its new Cache stores thanks to Dylan Stamat.

In the JEE world, debates around using EHCache vs. Memcached for second level cache have long been raging. While Memcached is popular in the LAMP and RoR world (Linkedin.com will switch to it soon), EHCache was adopted by projects like Spring or Hibernate. In an effort to migrate an existing application from MRI Ruby to JRuby, Dylan Stamat ported EHCache to JRuby adding EhcacheStore as a new cache Store.
In the MRI world, we use memcached, which is a Ruby interface to the libmemcached C client. It is one of the only Ruby libraries that currently supports consistent hashing, which is a requirement for our production environment. When preparing for JRuby, we had a different set of options. One was writing our own hooks into libmemcached via JNA, JRuby FFI, etc. The other was to look for another cache solution in Java, and Ehcache was definitely on top of the list.
Would you consider using EHcache with JRuby?
Another option... by Ray Krueger Posted Aug 20, 2008 6:00 AM
Re: Another option... by Dylan Stamat Posted Aug 21, 2008 12:49 AM
+1 for EH-Cache enabled Rails page caching at the servlet filter level by Raphaël Valyi Posted Aug 20, 2008 6:04 AM
Re: +1 for EH-Cache enabled Rails page caching at the servlet filter level by Dylan Stamat Posted Aug 21, 2008 12:52 AM
Re: +1 for EH-Cache enabled Rails page caching at the servlet filter level by Sebastien Auvray Posted Aug 21, 2008 3:03 AM
  1. Back to top

    Another option...

    Aug 20, 2008 6:00 AM by Ray Krueger

    Another option for using consistent hashing with memcached and JRuby would be to use the spymemcached client. The spymemcached client is an asychronous single-threaded client that has proven to work extremely well in the hibernate-memcached project. I have also used the spymemcached client in other projects and its performance was outstanding.

  2. Hi, As you know, the 'page caching' is by far the fastest caching system in Rails (like 2 orders of magnitude faster than hitting a fragment cache). But unfortunately, standard Rails page caching tends to be harder on J2EE serveurs that sometimes behave really differently from an Apache front end for instance. Especially there is an issue with static files colliding with dynamic requests pathes (just normal for standard rails page caching) but that are redirected agressively on J2EE servers unless you hack the app a little bit specifically for a J2EE deployment. Also, file based page caching is hardly convincing, even if J2EE servers have a memory cache of the static files. Indeed, there can be latency, disk access, it's not very easy to scale in cluster or to have something close to transactional. EH Cache would be a very great fit for all that. And Ideally it would be as transparent as possible so we avoid to much J2EE specifics here. Still, as serving pages directly from J2EE server tends to be two orders of magnitude faster than entering a JRuby+Rails runtime, it would be really great to tweak the JRuby-Rack servlet filter so that EH-Cached cached pages get served from directly from that servlet filter without even hitting the JRuby on Rails runtime! It would be a bit like the current file base page caching system but I think this would be faster, easier to scale and won't be screwed up with path collision. Any thought? Raphaël Valyi.

  3. Back to top

    Re: Another option...

    Aug 21, 2008 12:49 AM by Dylan Stamat

    Thanks for the link Ray ! Haven't had a chance to work with Spymemcached, but have heard of it. It's definitely on my list, and am going to check it out soon.

  4. Hey Raphael ! That's a great idea, and would love to get a memory option for page caches into JRuby/Rack at some point. I'm following the thread you and Nick Sieger are having in jira.codehaus (2832), and will chime in when I get a chance :) Thanks !

  5. Indeed it would definitely be an interesting option!

Educational Content

Bindings, Platforms, and Innovation

This presentation focuses on the Internet and separating myth from fact, history from the future, and the mundane from the imaginative. Bob Frankston presents a vision of what could and should be.

Orchestrating Long Running Activities with JBoss / JBPM

This article explores the use of JBoss and jBPM to implement design solutions that effectively address the issue of orchestrating long running activities.

Neo4j - The Benefits of Graph Databases

This presentation covers the use of graph databases as an optimal solution for data that is difficult to fit in static tables, rapidly evolving data or data that has a lot of optional attributes.

Realistic about Risk: Software development with Real Options

This session introduces Real Options and shows how it can help in running your project. Real Options is a decision-making process that can be used to manage risk.

Communication Flexibility Using Bindings

This article discusses the use of bindings on services and references (including the instance of non-configured bindings) as the means to implement SCA communications in a Web and SOA environment.

Writing DSLs in Groovy

After a short introduction to DSLs, Scott Davis plays with the keyboard showing how to approach the creation of a DSL by typing working snippets of Groovy code that get executed.

Scaling Agile with C/ALM (Collaborative Application Lifecycle Management)

IBM Rational and InfoQ present, Scaling Agile with C/ALM, an eBook showing organizations how to become “finely tuned software delivery machines” by enabling team integration and scaling.

Concurrent Programming with Microsoft F#

Amanda Laucher presents a real life enterprise application written in F#. She shows actual code snippets, explaining design decisions and suggesting how to use some of the F# constructs.