Rails Caching Reloaded With EHCache
- Share
-
- |
Read later
My Reading List
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
+1 for EH-Cache enabled Rails page caching at the servlet filter level
by
Raphaël Valyi
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.
Re: Another option...
by
Dylan Stamat
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.
Re: +1 for EH-Cache enabled Rails page caching at the servlet filter level
by
Dylan Stamat
Educational Content
Writing Usable APIs in Practice
Giovanni Asproni May 19, 2013
Concurrency in Clojure
Stuart Halloway May 17, 2013
Confessions of an Agile Addict
Ole Friis Østergaard May 16, 2013
Hello stranger!
You need to Register an InfoQ account or Login to post comments. But there's so much more behind being registered.Get the most out of the InfoQ experience.
Tell us what you think