RFC: Adding caching to Conductor

Matt Wagner matt.wagner at redhat.com
Mon Apr 9 20:35:33 UTC 2012


Howdy,

The final feature description I have left to request feedback on is
adding caching support to Conductor, a la memcache:
https://www.aeolusproject.org/redmine/projects/aeolus/wiki/Adding_Caching_to_Conductor

The idea is pretty simple -- enabled the built-in support for memcached
in Rails, cache stuff there, and benefit from a massive speedup. I ran
into two problems as I began to tinker with this, though:

- memcached is in Fedora, but rubygem-memcache-client is not. I think
  there's benefit in getting there, but it means that we're taking on
another packaging obligation.

- All the things I think could benefit from a cache are tricky to cache.
  I was going to look at caching permissions, but Scott's actively
working on that, so instead I looked at the pool statistics method,
which I know from past experience is fairly slow. But it's fairly
difficult to know when to invalidate, since an instance changing state
could change the state, and it's optionally scoped per-user. I started
playing around with the :touch attribute on associations, but I came to
decide that the pool statistics method was probably a terrible place to
start, since it got the point that changing nearly anything would update
the pool.

So I'm left thinking that using memcache, in the abstract, is a good
idea, but I'm struggling to articulate any specific use cases where
using it is a no-brainer right now. I do think that we can speed things
up by using memcached, but it brings the requirement of getting
rubygem-memcache-client into Fedora and RHEL, and also requires a fair
bit of work for the specific uses cases I had in mind, since it's not
trivial to cache. Does anyone have any specific methods come to mind
that are escaping me? I'm coming to the opinion that this should not be
at the top of our priority list.

-- Matt



More information about the aeolus-devel mailing list