launchpad-dev team mailing list archive

[Robert Collins <robertc@xxxxxxxxxxxxxxxxx>]

Hi there, a branch of mine is just landing now that removes the cache
instruction from TAL. This is the interface we had used to glue
Memcache support into Launchpad.

https://code.launchpad.net/~lifeless/launchpad/memcache/+merge/109551

I went through and audited our usage. They fell into three categories:
band-aids for poor underlying model/code, pessimisations, where we
have disabled it via a feature flag already to fix timeouts (yes,
using memcache gave us timeouts), and finally we had a single use -
the front page blog entry - where it 'made sense', but we have an
inline pure HTTP cache for that already, so the net impact of the
audit was that we don't actually use memcache at all for the web UI.

We have a couple of uses in garbo migrators, and unless we change them
to have a different system, we'll need to keep the memcache install
and clients around for now.

I think memcache is a great tool for scaling a site, but its a
terrible tool for improving performance - cache misses are the
underlying driver for getting the data to the user on first-load, and
memcache by definition doesn't help with that.... but users *notice*
first-load. It also doesn't help with ensuring that something you want
cached is available, unless you engineer specifically to deliver that:
pre-loading the cache, and sizing the cache to avoid any size-related
evictions. Neither of those things had been done for us: so misses
were satisfied in-line and we achieved a 50% hit-rate.

The TALES code can be brought back easily, if in future we do want to
use memcache from templates. I think a much better use for it is with
memoised data that is hard or complex to create, and which we are
refreshing asynchronously. For that, we have no need for in-template
usage though: we can make a regular python callout. That said, we're
still, on much of our schema, several orders of magnitude less
efficient than we can be, and bringing memcache in early just adds
complexity to the analysis of problem spots.

-Rob