launchpad development|
Size: 5374
Comment:
|
Size: 6019
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 7: | Line 7: |
| Numbers for Firefox, OEM/IE in China (what versions of IE?), Europe vs. USA, new vs. repeat visitors, authenticated vs. unauthenticated, length of typical usage session, public vs private project usage | == Launchpad Commercial Users == Over the coming months we will be focusing on performance issues for commercial users who work for OEMs, ODMs, and our own field engineers. What follows is a rough outline of who these people are: * Most of this user group is in Asia. Their network times are quite slow. * Many do not use Launchpad because their company has standardized on internal bug tracking software. * They overwhelmingly browse Launchpad with Windows XP and IE7. * When they do check Launchpad they do so as an anonymous user. * They hold independent accounts, not part of a private company account. * They use Launchpad bugs to find and occasionally file issues in Ubuntu core packages. * They use search extensively. |
| Line 11: | Line 21: |
| - OEM TTI adds extra weight - Frequent, authenticated users are especially important |
* Reducing network time is particularly important for OEM users. They suffer 10x the network latency of our European users. If Europe takes 150ms to load 1 kilobyte, Asia takes 1500ms. |
| Line 14: | Line 23: |
| Therefore | How do we reduce TTI for these users? |
| Line 16: | Line 25: |
| * OEM/China: TTI of IE is more important than it might be if OEM were not a factor * Around the globe: Latency is a very important factor * Frequent users: Cacheing can be very effective * Authenticated users: Cacheing of pages in Squid doesn't help our clients all that much * Private users: SSL is still needed; need to determine how often, and whom it affects |
* IE-specific improvements to script loading and caching will help, such as the `deferred` script attribute. * IE7 has a limit of two connections per-domain for parallel downloading of resources. This makes the site much slower to load. Domain sharding and reducing the number of requests on a page become very important. * Proper caching is very important to reduce round-trips, because they are so expensive. * Reducing payloads will help. * Removing SSL would help. * Generation time may be important, depending on how many cache hits and/or misses they generate. |
| Line 23: | Line 34: |
For each idea below, we do the following. * We identify the types of users and situations it will help. * We estimate the improvement for those users, based on the data collected for Launchpad. We focus on the 10 pages described XXX. * When appropriate, we highlight important users and situations that will not be helped. * When available, we sometimes link to documents describing the idea, as used or researched internally or externally to Canonical. |
|
| Line 79: | Line 83: |
| XXX discuss typical percentage of request spent in render time. | Assuming that render time is everything spent outside Network and Generation time, Render time would account for ~30% of the page load time. Render time usually spent after the initial HTML is loaded waiting for fetching and rendering of on-page resources, JavaScript execution, and so forth. |
This page is a collection of ideas for improving the Time To Interact of pages on Launchpad.net.
Contents
Which Users Should We Target?
Launchpad Commercial Users
Over the coming months we will be focusing on performance issues for commercial users who work for OEMs, ODMs, and our own field engineers. What follows is a rough outline of who these people are:
- Most of this user group is in Asia. Their network times are quite slow.
- Many do not use Launchpad because their company has standardized on internal bug tracking software.
- They overwhelmingly browse Launchpad with Windows XP and IE7.
- When they do check Launchpad they do so as an anonymous user.
- They hold independent accounts, not part of a private company account.
- They use Launchpad bugs to find and occasionally file issues in Ubuntu core packages.
- They use search extensively.
How do these factors affect TTI?
- Reducing network time is particularly important for OEM users. They suffer 10x the network latency of our European users. If Europe takes 150ms to load 1 kilobyte, Asia takes 1500ms.
How do we reduce TTI for these users?
IE-specific improvements to script loading and caching will help, such as the deferred script attribute.
- IE7 has a limit of two connections per-domain for parallel downloading of resources. This makes the site much slower to load. Domain sharding and reducing the number of requests on a page become very important.
- Proper caching is very important to reduce round-trips, because they are so expensive.
- Reducing payloads will help.
- Removing SSL would help.
- Generation time may be important, depending on how many cache hits and/or misses they generate.
What Can We Improve?
Network Time
Network time is roughly 33% of time to interact. It can vary from as little as 20% to as much as 45% of the time spent on a page.
Make Librarian downloads reuse connections. Not doing so now. Reason unclear.
A big win on the site homepage, the profile pages, and possibly on the project pages. --mars
Remove requests for the same static file from both the application and root domain within the same page (e.g. fetching an image from bugs.launchpad.net and launchpad.net in the same page)
Easy to fix. --mars
Send real Cache-Control headers for /@@/spinner and friends (the headers are missing entirely). Without these the resource falls back to Etags to determine freshness, and the Etags are always changing, making the resource impossible to cache.
An easy win. --mars
- Remove SSL.
- Private projects and teams would remain under HTTPS; everything else would be under HTTP. This would also probably suggest drastically reducing the amount of time that authentication cookies are kept, from a year to more like half an hour. This would reduce the risk of stealing session cookies in HTTP, and the openid server (HTTPS) could remain with long timeouts, perhaps, so that the user experience can still not require frequent logins. Switching back and forth from HTTP to HTTPS may be tricky, but we can probably find low-hanging fruit for initial implementations (e.g., force redirect to HTTPS if something private wants to be rendered over HTTP; offer redirect to HTTP if nothing private is rendered over HTTPS).
- Cut payloads
- Remove Mochikit
- Determine benefit for IE7. Probably of minimal benefit for other browsers because of parallel download.
- Remove Mochikit
- Domain sharding for librarian lookups (need numbers to back this up)
Try fixing librarian connection reuse first. --mars
- CDN or poor man's CDN to help US, Southwest Pacific, and South American users (What are options for poor man's CDN? Identify items we could and could not put on CDN; skeptical it would be a lot)
- Uglification: Remove newlines, spaces, and comments from returned HTML.
Here is a study of a complete HTML minifier. It only leads to an average 3-5% reduction in payload. Not worth the effort. --mars
Generation Time
Generation time may account for 35% of TTI for anonymous requests, and 40% of TTI for authorized requests. (Here are the calculations for viewing http://launchpad.net/bzr.)
Generation time is drastically reduced when you hit the squid caching server instead of the Zope application servers. Squid will typically returns results in less than 200ms, one tenth of the time it takes to get data from the application server in the example above. This effect is most visible to authenticated users, who always hit the application server. (What percentage of page requests are authenticated? --mars)
- Chameleon (saves about 10-15% faster during generation, according to tests done by Gary Poster Q4 2009; specific results not available.)
- Memcached, MongoDB, or other similar technology
- cache page elements, such as bug comments and tag clouds
- cache ETags (can be used for launchpadlib)
- session data
- Detailed profiling numbers
- Time spent in session authentication?
- Time spent in the database?
- Time spent rendering the response?
Render Time
Assuming that render time is everything spent outside Network and Generation time, Render time would account for ~30% of the page load time. Render time usually spent after the initial HTML is loaded waiting for fetching and rendering of on-page resources, JavaScript execution, and so forth.
- Workaround IE cacheing problem
Load JavaScript using the deferred attribute
Lazy-loading JavaScript for key pages
- Change inline script node ordering to maximize parallel downloads
- Load less-important page elements later (already started in 3.0 UI)
