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...
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
One bottleneck we have is in the Conductor calls to Image Warehouse. It
is unclear to me if the proposed Image Factory API changes will help to
alleviate it or if it is one of their goals.
Finding specific attributes in the template is currently one of the
costlier operations we make. Since the template is immutable once it is
uploaded by Conductor, I wonder if we should consider caching some of
the more frequently used attributes like operating system, version, and
architecture (used in /conductor/pool_families). Adding the attributes
into a Conductor model is an alternative.
- Richard