launchpad-dev team mailing list archive

[Gary Poster <gary.poster@xxxxxxxxxxxxx>]

On Mar 2, 2010, at 9:37 AM, Bjorn Tillenius wrote:

> Hi,
> 
> I took a look at the current Memcached work, and saw the merge proposal
> for the TAL API. I took a look at the current API, and while it looks
> nice and easy to use, I can't really tell whether it's a good or bad
> API. I can't tell, since I don't really know what we want to use
> Memcached for.

Hi Björn.

The API is part of Foundations trying to answer a couple of questions.  Both questions fall generally under our efforts to address general performance.

The main question is whether memcached can make a significant positive difference for rendering page elements.  Bug comments, tag clouds, and featured projects on the front page are examples of places in which we will see if the integration is a win.

A secondary question is whether memcached is the right tool for achieving this kind of performance improvement.  While memcached is arguably the standard open-source tool for cacheing small bits like page elements, other tools can play this game too--and might simultaneously do a better job at some of our other "NoSQL" jobs like storing sessions or providing the persistence for the librarian.  This appeals to me because, in the big picture, I want to reduce, not increase, the number of moving parts in Launchpad.

To answer these questions, Stuart has done two things, and Maris is working on a third.

First, Stuart has created an analysis tool to look at zservertracelog results for certain pages (actually, for certain regexes).  We will use this to evaluate performance before and after memcached usage.

Second, he came up with a way to try memcached out in certain pages in a non-intrusive way.  That is the API that you have looked at.  It allows very small changes to the application code to pull memcached into the mix.  It should also work with bug comments, because of his support of tal:repeat.  The syntax itself is agnostic to memcached, so we can experiment with other back-ends more easily.  It was fairly quick for Stuart to code and integrate in the form that it is now.

Finally, Maris has looked at our performance from an end-user's perspective, so we can fit the performance improvements in our appserver into the bigger picture of "time to interact," or "TTI"--the term he has pointed out in the Facebook performance blog post.  Thus, a 20% appserver speed increase might only be a 5 or 10% speed increase for TTI because of time spent in the network traffic or on the client-side.  This will help us prioritize our efforts.  He is working on describing this data publicly, as I've mentioned before.

> I know that we want to cache parts of the page, but that's pretty vague.
> I do know that one thing that we want to cache is the rendering of bug
> comments, since that's pretty safe to cache, and they are expensive to
> render. What else are we wanting to cache?

Answered above.  If anyone else has any particularly good candidates, they could be part of the experiment as well.

> When can we consider this
> done, from a Foundations point of view?

The current effort will be done when we have determined what kind of performance improvement we will be able to expect from memcached cacheing page elements that we have identified.

Subsequent related efforts will probably include the following:

 - exploring whether memcached or another similar tool can be used for OAuth nonces to beneficial effect;

 - exploring whether memcached or another similar tool can be used for improving launchpadlib's performance (such as cacheing ETags); and

 - pursuing some arbitrary systemic performance improvement for Launchpad's TTI like "twice as fast".

If memcached or something like it will be part of the efforts, that will be the point at which we determine whether this syntax, or something related, will be included more permanently.

> Personally I'd like to at least see bug comments cached. There are a
> different ways this can be done, and I'd be interested to know how the
> current API design was decided upon. What other options were considered,
> and why were they abandoned?

This API is part of our evaluation stage.  We pursued it because it seemed to meet the goals I lay out above, including speed of integration.  The data we collect, as well as the experience we have with this API, will help guide our future decisions.

Gary