«     »

Faster pages

I am happy to report that caching rules I put in place on many pages last week are effective. I did not want to announce that pages were faster until I could see read a week of oops reports to verify that the slow pages owned by the Launchpad registry team were no longer listed as problems. I am honestly surprised that all the slow pages I changes are not listed. I expected to make a reduction in timeouts between 50% and 80%. This looks like a 100% success. I know it is not 100%, but I think this means that milestone, series, and project pages load quicker and you are seeing fewer timeouts.

Launchpad pages now have access to memcached to store fragments of pages. Parts of pages that are costly to generate are cached for minutes or hours depending on how often the data can change. In the case of distro series pages, architecture data changes every few months so the cache rules are 6 hours. Milestone pages were a challenge to cache. Active milestones cache bugs for 10 minutes, Inactive milestones cache for 3 hours. The milestone summary of statuses and assignments cache for 1 hour. If you do not know this, you may suspect there is a bug in launchpad, or wonder if you did not update a bug as you thought. We need a mechanism to expire change when data is changed.

We are now adding cache rules to other pages to improve page load times.

Tags:

This entry was posted by Curtis Hovey on Friday, June 11th, 2010 at 3:15 pm and is filed under General. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

4 Responses to “Faster pages”

  1. Daniel Hahler Says:
    June 13th, 2010 at 3:04 pm

    Great to see memcached (or something similar) finally being used by Launchpad.

    However, you really should use a scheme of keys, which can easily get expired: if something needs refreshing every few months, expiring it every 6 hours is a waste, and in case it gets refreshed, there might be obsolete data for up to 6 hours (and somebody has likely to jump in and expire it manually).

  2. Curtis Hovey Says:
    June 14th, 2010 at 1:10 pm

    Yes. I reported a bug that I hope the foundations team can address. I do not think the TALES-based cache rule will get much use until I can have a sibscriber to modification/creation events that will purge the correct caches.

  3. Michael Rooney Says:
    July 12th, 2010 at 4:42 am

    Glad to hear about faster pages, but I will also be very much looking forward to proper cache expiration.

    I use milestones as my main workflow, so I will fix a bug or two, mark them as fixed, and then I love refreshing the milestone and watching them move to Fixed, and then pick off the next thing.

    With the caching I don’t get the same immediate reward, and it makes it harder to discern what to work on next when fixed bugs are still floating about in their previous state, so overall it’s a net loss for me.

    You mentioned you filed a bug for that, could you link it? Thanks!

  4. Curtis Hovey Says:
    July 12th, 2010 at 6:44 am

    The bug is Need to flush caches with modified object
    https://bugs.launchpad.net/launchpad-foundations/+bug/593054

    The foundations team are experimenting with an automated invalidation mechanism.

Leave a Reply