loggerhead should be able to cache in memcached

[Martin Pool]

It might be useful if loggerhead could cache things into memcached as an alternative to its on-disk cache: the ancestry/revno cache, any other caches that it has, and perhaps also the rendered html representation for some things.

[Michael Hudson-Doyle (mwhudson)]

Well, um, yes, it /might/ be nice :)

I'm not sure what actual concrete benefits it would bring to replace the on-disk cache with memcached -- loading the data we currently store there from the sqlite is fast enough that you don't notice it amongst all the other stuff we do.

It would certainly be nice to not cache so much in memory, and funnily enough I've just submitted a branch for review that does this -- storing it in another sqlite database for now.

[Martin Pool (mbp)]

2009/4/24 Michael Hudson <email address hidden>:
> Well, um, yes, it /might/ be nice :)

I don't know if it would be a priority for you, it just came up at the
sprint here.

Launchpad is planning to use memcached for several things; if
Loggerhead can use it too it may have some advantages in having
everything in the same framework, and it might be easier to garden
than sqlite is. On the other hand sqlite is possibly easier for other
people to deploy.

--
Martin <http://launchpad.net/~mbp/>

[Martin Albisetti (beuno)]

I have no idea what this would look like.

[Michael Hudson-Doyle (mwhudson)]

Being able to use memcache for what we currently use sqlite for -- caching the revision graph and the files-changed information -- would allow us to more easily scale codebrowse horizontally as it would be trivial to access the cache from a variety of machines.

I also expect memcache's concurrency story is rather better than sqlite's!

OTOH we want to cache a lot of data, and don't care /that/ much about performance, so memcache may not be a perfect fit.

[Michael Hudson-Doyle (mwhudson)]

sharedance looks like something that might be a good fit for codebrowse -- no idea how battle-hardened it is, though.