launchpad development|
Size: 0
Comment: Merged with Foundations/SystemPerformance
|
Size: 2309
Comment: snapshot
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| [[TableOfContents(1)]] = Overview = Performance can mean many different things and as such is very hard to measure - but generally we know if something 'performs well' - it feels responsive (we can measure this), it lets us achieve what we want quickly (we can measure this), it handles lots of users (and we can measure this), and make efficient use of resources (we can measure this). This page focuses on the purely technical aspects of performance: responsiveness, capacity, throughput and efficiency. It aims to provide a common language for talking about challenges and improvements in these areas, and the style of tools available for dealing with them. There are other technology and challenge specific pages in this wiki, which can and should be consulted for the specifics about what a team is working on or the chosen technology for some part of the system. == Responsiveness == Responsiveness is simply how fast-or-slow you get feedback on actions in the system. Depending on the layer you are working at this may be web requests, ui changes, packages building - etc. We want Launchpad to be very responsive to interactive operations, so that users are not waiting for Launchpad. For batch operations we care less about responsiveness, but where we can be its nice to still be responsive. Note that work queues to complete tasks asynchronously '''does not''' imply that these tasks are batch operations: if they are on behalf of an interactive user, they should still be considered an interactive task. We have a (internal only - sorry, it includes confidential URLs at the moment) [[https://devpad.canonical.com/~stub/ppr/lpnet/latest-daily-combined.html|report]] which reports how long server side requests take to complete. To find out how long 99% of requests take to complete, add 3* the stddev and the mean. Some of our requests are very fast - many are extremely fast - but many are also very slow. Things that help responsiveness: * Separating out work-for-the-user and work-for-our-housekeeping. * Efficient queries / formatting * Memoised data we can query more easily (indices in the database are an extremely common case of this, but we can also memoise things in other data structures) == Capacity = Web = = API = = Database = = Test = |
Overview
Performance can mean many different things and as such is very hard to measure - but generally we know if something 'performs well' - it feels responsive (we can measure this), it lets us achieve what we want quickly (we can measure this), it handles lots of users (and we can measure this), and make efficient use of resources (we can measure this).
This page focuses on the purely technical aspects of performance: responsiveness, capacity, throughput and efficiency. It aims to provide a common language for talking about challenges and improvements in these areas, and the style of tools available for dealing with them. There are other technology and challenge specific pages in this wiki, which can and should be consulted for the specifics about what a team is working on or the chosen technology for some part of the system.
Responsiveness
Responsiveness is simply how fast-or-slow you get feedback on actions in the system. Depending on the layer you are working at this may be web requests, ui changes, packages building - etc.
We want Launchpad to be very responsive to interactive operations, so that users are not waiting for Launchpad. For batch operations we care less about responsiveness, but where we can be its nice to still be responsive. Note that work queues to complete tasks asynchronously does not imply that these tasks are batch operations: if they are on behalf of an interactive user, they should still be considered an interactive task.
We have a (internal only - sorry, it includes confidential URLs at the moment) report which reports how long server side requests take to complete. To find out how long 99% of requests take to complete, add 3* the stddev and the mean. Some of our requests are very fast - many are extremely fast - but many are also very slow.
Things that help responsiveness:
- Separating out work-for-the-user and work-for-our-housekeeping.
- Efficient queries / formatting
- Memoised data we can query more easily (indices in the database are an extremely common case of this, but we can also memoise things in other data structures)
== Capacity
Web
API
Database
