= DRAFT System Performance =

This page is home for the Foundations Team's work towards improving the performance of Launchpad.net.

One of the Foundations team's initiatives is to improve systemic performance.  This section of the wiki has documentation of the associated experiments and projects.

Note also we have focused work on webservice performance.  This is [[Foundations/Webservice/Performance|discussed and tracked separately]].

The following is research collected describing the methodology we are using to look at page performance, and the low-level analysis of the approaches we have considered and how they relate to the results we have gathered.

 * /MeasuringPagePerformance: Tools and techniques for measuring page load performance
 * /ImprovingPageLoadPerformance: Ideas and numbers for faster page load times

A very high-level summary is the following.

 * We think of Launchpad's systemic performance in terms of '''Time to Interact''', or TTI.
 * TTI has three components: network traffic, including SSL handshaking; page generation on the server; and browser rendering, including JS processing.  For Launchpad, a rough guideline is that these three each account for 60%, 40%, and 0% (negligible) respectively.
 * We have special users we care about: authenticated users are particularly important to us, and users on FF, WebKit (Safari and Chrome), and IE are all important to us.  IE represents a small fraction of our user base, but OEM makers and other important corporate users sometimes are forced to use only IE.

On the basis of that analysis, we have identified the following bigger projects to tackle to improve performance.

 * We are providing [[/Metrics|easily available metrics]] for DIY performance improvements across the Launchpad team.

 * We want to provide well-documented and easy-to-use tools for DIY performance improvements across the Launchpad team.  We offer [[Foundations/Memcached|memcache page snippets]] right now.  While, at the moment, these only are purged from the cache over time, we are investigating active invalidation with the webservice, and we may be able to move lessons learned from that effort to the page snippet caches. (XXX Are there client-side tools I should mention here, like the sprite code?)

 * We want to '''improve cacheing and network performance on the browser''', with special focus on IE.
 
 * We want to '''switch to a faster template implementation''' (named "Chameleon").

 * We want to [[/SSL|reduce the cost of SSL]].

 * We want to consider larger architectural changes.

   * For some data, faster read access in exchange for being "eventually consistent."

   * Multiple data centers around the globe.

   * XXX More brainstorming goes here XXX

We are not considering Loggerhead for these changes, though our code browsing story generally could really use some significant improvements.