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

Matt Wagner matt.wagner at redhat.com
Fri Feb 17 16:47:46 UTC 2012



Hi all,

This fixes a long-standing pet peeve... I've known for a while that the Pool Families page (/pool_families) runs a bunch of SQL queries, but I never gave it much attention.

Today mfojtik sent a neat link out talking about how 37signals made Basecamp so fast: http://37signals.com/svn/posts/3112-how-basecamp-next-got-to-be-so-damn-fast-without-using-much-client-side-ui

Reading it, I felt somehow irritated. "This is all well and good," I thought, "except it won't do any good if your app is unbearably slow to begin with."

So I filed a BZ for the excessive SQL queries, and looked a bit at what was going on. It was crazier than I had expected:
a.) It wasn't dozens of queries we were running, it was *thousands* of them.
b.) The pool.statistics method was being called every time it was displayed, generating about 10 queries every time.
c.) pool_family.statistics was (ab)used the same way.
d.) pool_family.statistics _called_ pool.statistics for every pool (!) for every statistic (!!)

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...

-- Matt



More information about the aeolus-devel mailing list