In my part 1, I laid out my initial approach on caching in Cullect.
It had some obvious deficiencies;
- This approach really only sped up the latest 20 (or so items). Fine if those items don’t change frequently (i.e. /important vs /latest) or you only want the first 20 items (not the second 20),
- The hardest, most expensive database queries weren’t being cached effectively. (um, yes that’s kinda the purpose).
I just launched a second approach. It dramatically simplified, cache key (6 attributes down from 10) and rather than caching entire the items in that key, I just stored the pointer object to them.
Unfortunately, even the collection of pointer objects was too big to store in the cache, so I tried a combination of putting a LIMIT on the database query and trying to store 20 items a time in a different cache object.
This second approach had the additional problem of continually presenting hidden/removed items ( there’s 2 layers of caching that need to be updated).
Neither was a satisfactory performance improvement.
I’ve just launched a solution I’m pretty happy with and seems to be working (the cache store is updating as I write this).
Each Cullect.com reading list has 4 primary caches – important, latest, recommended, hidden – with a variants for filters in keyword searches. Each of these primary caches is a string containing the IDs of all the items in that view. Not the items themselves, or any derivative objects – both of those take up too much space.
When items are hidden, they’re removed from the appropriate cache strings as well.
Murphy willing, there won’t be a part 3. 😉
1. Storing the items in the cache as objects