Seatwave Web Peformance Optimisation Case Study
2 likes1,152 views
A web performance optimisation case study presented by Seatwave at the London Web Performance Meetup, Jan 2011. The PDF is in Landscape so you might be better to download it and then shift-ctrl-+ to rotate it clockwise in Adobe Acrobat Reader.
Ad
More Related Content
What's hot (20)
Similar to Seatwave Web Peformance Optimisation Case Study (20)
Ad
More from Stephen Thair (15)
Ad
Recently uploaded (20)
Seatwave Web Peformance Optimisation Case Study
- 1. Optimisation Case Study January 2011 Ged Waring & Perry Dyball
- 2. Headline Results of Project • Reduced HTTP Requests by 30% • Reduced Page Load time by between 50% and 70% • Reduced Page Size by between 22% and 33% • Reduced Hard Bandwidth requirements by 43% • Reduced DB CPU requirements by 75% • Increased Concurrent Users ceiling by 300% CONFIDENTIAL DRAFT
- 3. Presentation Outline • Origins of Problem • Why Optimise? • Project Constraints and Approach • Measurement Techniques & Tools • Project Steps • Wrap Up / Challenges CONFIDENTIAL DRAFT
- 4. Origins of Problem • Frequent releases with poor measurement and testing • Speed to market versus slower engineering process • Problem compounds & worsens over time • No single culprit – all tiers of the platform • Did the problem harm our business? • In the short-to-medium term – almost certainly not. • In the medium-to-longer term – yes. CONFIDENTIAL DRAFT
- 5. Why Optimise? • User Experience / Conversion / Retention • Increased capacity to serve customers • Google/SEO • Return on investment • Hard bandwidth ceiling and DB Server capacity • Handle large traffic spikes CONFIDENTIAL DRAFT
- 6. Constraints • No additional hardware spend • Continual product / feature development CONFIDENTIAL DRAFT
- 7. Project Approach • Path of least resistance • Iterative – Change / Measure / Report / Repeat • Phase 1 – Fairly Easy • Infrastructure Configuration / Leverage Existing Resources • Client Side Optimization • CDN • Phase 2 - Harder • Database Optimisation • Middle Tier Refactoring / Caching CONFIDENTIAL DRAFT
- 8. Project Approach Business buy-in Baseline performance Make a single change Adapt your plan Measure it Analyse results CONFIDENTIAL DRAFT
- 9. Project Approach • Release Discreet Changes • Script & run tests • Record metrics • Collate results • Report & analyse • Repeat • Minimise Other Environment Variables / Changes • Time of day • Hardware / Network changes • Skewed traffic (Ad. campaigns / Extraordinary spikes) CONFIDENTIAL DRAFT
- 10. Tools we used • HttpWatch Professional (Object Library) • WebPageTest.org • Y-Slow / Firebug / Fiddler • Site Confidence Monitoring Portal • IDERA (DB Monitoring) • SQL Profiling (Server Side) • SQL Reporting Services • F5 Load Balancing Consultants – Quadrant Networks Note : In our case the new Site Confidence Performance Analyser tool has replaced HTTP Watch / WebPageTest / Y-Slow CONFIDENTIAL DRAFT
- 11. Phase 1 : Client Side / Page Optimisation • Areas yielding highest benefit • Compression (check your configuration) • Compression moved from IIS to F5 Load Balancer • Object caching at F5 Load Balancer • Reduction in HTTP Requests / Spriting / File Consolidation • Image size consistency • Removal of third party killers (Images/JS) • Parallelism (CDN) CONFIDENTIAL DRAFT
- 12. Client Side / Page Optimization Results Home Page Load Time (ms) (2mbps download speed) Empty Cache Primed Cache Baseline 4,435 3,279 P10 F5 Optimisation 4,145 3,123 P20 10 March (Ptix, Concat) 4,608 2,781 P30 24 March (Spriting and Verisign) 1,804 1,177 P40 24 March (Parallelism) 1,839 1,084 R50 21st April Release 1,393 824 Home Page Load Times (ms) (source: HttpWatch) 5000 4500 4000 Load time (ms) 3500 3000 2500 2000 1500 Empty 1000 500 Primed 0 P01 Baseline P10 F5 P20 10 P30 24 P40 24 R50 21st Optimisation March (Ptix, March March April Release Concat) (Spriting and (Parallelism) Verisign) Optimisation Phase CONFIDENTIAL DRAFT
- 13. Client Side / Page Optimization Results Grand Http Requests by Mime * css flash html image javascript redirect Total 01 Baseline 1 4 1 1 37 13 3 60 02 Post F5 Optimisation 1 4 1 1 37 13 3 60 03 Page Optimisation 10 March (Ptix, Concat) 1 4 1 1 37 12 3 59 04 Page Optimisation 25 March (Spriting and Verisign) 1 4 1 1 23 12 3 45 04 Parallelism 25th March - 4 1 1 21 11 38 05 Release 21st April 4 1 22 10 37 Season Page HttpRequests by Phase/Mime 70 60 50 redirect 40 javascript image 30 html 20 flash 10 css * 0 01 Baseline 02 Post F5 03 Page 04 Page 04 Parallelism 25th 05 Release 21st Optimisation Optimisation 10 Optimisation 25 March April March (Ptix, March (Spriting and Concat) Verisign) CONFIDENTIAL DRAFT
- 14. Client Side / Page Optimisation Results CONFIDENTIAL DRAFT
- 15. Client Side / Page Optimisation Results Page load performance both improved and became more consistent CONFIDENTIAL DRAFT
- 16. Phase 1 : Results • Page load performance • Page load times reduced by between 38% and 60% • Bandwidth requirements reduced by 18% • How long did it take? • 4 months elapsed. • Work completed alongside normal product development CONFIDENTIAL DRAFT
- 17. CDN Evaluation Overview Load time drop Monday to Wednesday when test speed increased from 512kbps to 2mbps CONFIDENTIAL DRAFT
- 18. Phase 2 : What did we do? • Database • Analyse web page db interaction • Repeated tracing of all db calls • Reports on worst performing aspects of the db • Computing DB CPU per user session • F5 Load Balancing • Upgrade internal network layer configuration to 1Gbps • Upgrade F5 O/S to V10.2 • F5 traffic management rules / log • CDN • Non image assets – JS / CSS serve from CDN CONFIDENTIAL DRAFT
- 19. Phase 2 – Why did we do it? • Identify and remove redundant db calls from web code • Identify data that was a candidate for caching • Identify which site features were resource hungry • Save more bandwidth • Control traffic at the F5 in real time Overflow traffic redirected and managed in a cloud based queuing system CONFIDENTIAL DRAFT
- 20. Effect on DB Resource Usage CONFIDENTIAL DRAFT
- 21. Phase 2 Achievements • Benefits • Capacity increased from 2,100 to 6,300 concurrent users • 8.3m sessions in October 2010 on 8 web servers • Queuing capability for another 4,000 concurrent users • DB resource use reduced by 75% • Reduce bandwidth demands by further 25% • Reduce internal network traffic • Financial Benefit • Single biggest return this year • How long did it take? • 3 months elapsed • Work completed alongside normal product development CONFIDENTIAL DRAFT
- 22. Normal Traffic Pattern CONFIDENTIAL DRAFT
- 23. Major On-Sale Traffic Pattern Traffic spike sustained for long period. Gradual inflow of traffic from queuing system until queue expired CONFIDENTIAL DRAFT
- 24. TV Advertising Traffic Pattern Note 3rd / 4th ad break spikes when we didn’t run ads CONFIDENTIAL DRAFT
- 25. Wrap Up • It’s hard work • You need to do it repeatedly • You need to be consistent • It will generate large amounts of data • Use automation wherever possible • Expect unanticipated bottlenecks / pinch points • Bake optimisation into the release process • It will yield material benefits CONFIDENTIAL DRAFT