Difference between revisions of "SitePerformanceMonitoringTools"
Line 1: | Line 1: | ||
− | <noinclude><big>[[OurWork]] < [[DevelopmentTeam]] < [[DevelopmentTeamPriorities|Priorities]] < </noinclude>('''10''') [[SitePerformanceMonitoringTools]] ('''[[ | + | <noinclude><big>[[OurWork]] < [[DevelopmentTeam]] < [[DevelopmentTeamPriorities|Priorities]] < </noinclude>('''10''') [[SitePerformanceMonitoringTools]] ('''[[Ethan]]''') {{JustTinyEditIcon|SitePerformanceMonitoringTools}}<noinclude></big> |
__NOTOC__ | __NOTOC__ | ||
== What (summary) == | == What (summary) == |
Revision as of 03:42, 1 September 2007
What (summary)
Instrumentation that provides a history of performance statistics for each part of the page load pipeline.
Why this is important
The responsiveness and performance of the site makes a big difference in how many pages visitors will view, and how often they will come back. A poorly performing site will also wear out our active members causing some of them to leave.
DoneDone
Define good and acceptable times for pieces of the Performance pipe
- Max cold-request to fully rendered time for normal pages (including especially front page)
- 3 seconds is unacceptable
- Max Load Time for special goodness (Batch Patrol ... etc)
Record a history of how long to
- lookup DNS for www.aboutus.org, images.aboutus.org, ... from different parts of the world
- Setup a port 80 TCP connection with each of the squal boxes from different parts of the world
- Load the frontpage without any client caching
- Retrieve a memcache item from each combination of two squal boxes (one client, one memcached server)
- Load the core css files
- Load the core js files
...
Performance Priorities
- View normal page
- View random page
- Edit click until available
- Save click until rendered
- Render invalidated frontpage
Instrumentation Steps
- End to end on each
- Deploy instrumentation boxes in various locations
- Determine and instrument the pieces
- MediaWiki profiling
- Raw database queries