Seatwave Web Peformance Optimisation Case Study
Upcoming SlideShare
Loading in...5
×
 

Seatwave Web Peformance Optimisation Case Study

on

  • 3,111 views

A web performance optimisation case study presented by Seatwave at the London Web Performance Meetup, Jan 2011. ...

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.

Statistics

Views

Total Views
3,111
Views on SlideShare
2,455
Embed Views
656

Actions

Likes
2
Downloads
33
Comments
0

5 Embeds 656

http://www.seriticonsulting.com 648
http://www.linkedin.com 3
https://www.linkedin.com 3
http://www.slideshare.net 1
http://www.onlydoo.com 1

Accessibility

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Seatwave Web Peformance Optimisation Case Study Seatwave Web Peformance Optimisation Case Study Presentation Transcript

    • Optimisation Case Study January 2011 Ged Waring & Perry Dyball
    • 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
    • Presentation Outline • Origins of Problem • Why Optimise? • Project Constraints and Approach • Measurement Techniques & Tools • Project Steps • Wrap Up / ChallengesCONFIDENTIAL DRAFT
    • 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
    • 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 spikesCONFIDENTIAL DRAFT
    • Constraints • No additional hardware spend • Continual product / feature developmentCONFIDENTIAL DRAFT
    • 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 / CachingCONFIDENTIAL DRAFT
    • Project Approach Business buy-in Baseline performance Make a single change Adapt your plan Measure it Analyse resultsCONFIDENTIAL DRAFT
    • 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
    • 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-SlowCONFIDENTIAL DRAFT
    • 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
    • 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 3500 3000 2500 2000 1500 Empty Load time (ms) 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 PhaseCONFIDENTIAL DRAFT
    • 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
    • Client Side / Page Optimisation ResultsCONFIDENTIAL DRAFT
    • Client Side / Page Optimisation Results Page load performance both improved and became more consistentCONFIDENTIAL DRAFT
    • 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 developmentCONFIDENTIAL DRAFT
    • CDN Evaluation Overview Load time drop Monday to Wednesday when test speed increased from 512kbps to 2mbpsCONFIDENTIAL DRAFT
    • 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 CDNCONFIDENTIAL DRAFT
    • 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 systemCONFIDENTIAL DRAFT
    • Effect on DB Resource UsageCONFIDENTIAL DRAFT
    • 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 developmentCONFIDENTIAL DRAFT
    • Normal Traffic PatternCONFIDENTIAL DRAFT
    • Major On-Sale Traffic Pattern Traffic spike sustained for long period. Gradual inflow of traffic from queuing system until queue expiredCONFIDENTIAL DRAFT
    • TV Advertising Traffic Pattern Note 3rd / 4th ad break spikes when we didn’t run adsCONFIDENTIAL DRAFT
    • 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 benefitsCONFIDENTIAL DRAFT