[PATCH conductor 0/1] #794759 - Fix absurdly-inefficient pool family page

Matt Wagner matt.wagner at redhat.com
Fri Feb 17 18:34:11 UTC 2012


On Sat, Feb 18, 2012 at 04:14:48AM +1100, Justin Clift wrote:
> On 18/02/2012, at 3:47 AM, Matt Wagner wrote:
> <snip>
> > Because Rails caches SQL queries, this wasn't as disastrous as it could be, but it was still bad.
> > 
> > This patch greatly improves the situation, though it's not perfect. We do hit the query cache a few times in a few harder-to-avoid cases, but hitting the query cache "a few times" doesn't seem problematic. (That's what it's there for.) It also doesn't quite feel right to be calling this from a view at all, but it's not trivial to avoid with the way the code is written and I was reluctant to make major changes there.
> > 
> > A quick comparison with and without this change, in development mode (where nothing is fast) shows that the average page load time drops from around 1900ms to about 950ms. That's hardly a scientific benchmark, but I'll take a 100% speedup any day...
> 
> Would a materialised view make sense for this?  i.e. updated every XYZ amount of time (whatever is appropriate)

The concept is interesting, though I actually had another idea in mind.
I introduced the "statistics" method a while back as a way to make it
easier to drop the whole thing into a cache later. We can use
"Rails.cache" to wrap memcache pretty trivially. (Or other cache layers,
but I'd caution against a local store since it would cause problems if
you ever tried to set up a cluster of Conductor nodes.)

However, I didn't want to introduce a new dependency at the time, and I
realized that cache invalidation was going to take a little bit of time
to get right. (For example -- if an instance changes state, we would
have to invalidate the cache keys for the pool and pool family.)

This got me curious about the actual performance of each method, so I
threw something quick together: https://gist.github.com/1854736

Of course the other part of the gain was that we don't call these
methods repeatedly from the UI any longer; the above Gist just shows the
speedup in the methods themselves.

-- Matt



More information about the aeolus-devel mailing list