Improving performance by changing the rules   from fast to SPDY
Upcoming SlideShare
Loading in...5
×
 

Improving performance by changing the rules from fast to SPDY

on

  • 1,088 views

SPDY was proposed by Google back in November 2009 to reduce the latency and load time of web pages. It was provided as part of the Chromium open-source project and is enabled in Chrome by default.

SPDY was proposed by Google back in November 2009 to reduce the latency and load time of web pages. It was provided as part of the Chromium open-source project and is enabled in Chrome by default.

We at Cotendo took on the challenge, implemented the server side, and extended our proxies to support SPDY, providing SPDY to HTTP “translation”. Guess what? It really speeds things up. But like all new good things, there is still work to do. We will share insights from our implementation, optimization of SSL-based traffic and present performance data both from Google’s and our customers’ deployment.
What’s next?

We believe the introduction of SPDY as a new application layer presents a unique opportunity to rethink web design concepts and front-end-optimization (FEO) techniques. We will discuss some optimizations we developed and suggest some guidelines on how you can approach these new types of optimizations.

Statistics

Views

Total Views
1,088
Views on SlideShare
1,081
Embed Views
7

Actions

Likes
0
Downloads
27
Comments
0

2 Embeds 7

http://a0.twimg.com 6
https://twitter.com 1

Accessibility

Categories

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

    Improving performance by changing the rules   from fast to SPDY Improving performance by changing the rules from fast to SPDY Presentation Transcript

    • From Fast to SPDY Ido Safruti, Mike Belshe,
    • SPDY
    • SPDY ee
    • Agenda Challenges of HTTP/1.1 SPDY Some data, and results How we tune today What’s next
    • rfc2616: HTTP/1.1 drafted:1998 released June 1999
    • What else was there in 1998
    • What else was there in 1998
    • What else was there in 1998
    • What else was there in 1998
    • What else was there in 1998
    • What else was there in 1998
    • What else was there in 1998 http://web.archive.org/web/19980425182703/http://geocities.com/
    • What else was there in 1998 4/25/1998 no external scripts or css files 20 images, ~65KB entire page http://web.archive.org/web/19980425182703/http://geocities.com/
    • Did They Plan for That!?
    • HTTP/1.1 Compression Headers Poor connection management  Only one request can be done at a time (Half duplex)  Particularly important on high latency links (mobile)  short lived connections security - optional
    • Compression * http://code.google.com/speed/articles/web-metrics.html + Cotendo measurements
    • CompressionOptionalOnly for response body ~99% of browsers support * http://code.google.com/speed/articles/web-metrics.html + Cotendo measurements
    • CompressionOptionalOnly for response body ~99% of browsers support Particularly important on small pipes (mobile) * http://code.google.com/speed/articles/web-metrics.html + Cotendo measurements
    • CompressionOptionalOnly for response body ~99% of browsers support Particularly important on small pipes (mobile)15%-30% of responses not compressed for no good reason!* for SSL even worse * http://code.google.com/speed/articles/web-metrics.html + Cotendo measurements
    • CompressionOptionalOnly for response body ~99% of browsers support Particularly important on small pipes (mobile)15%-30% of responses not compressed for no good reason!* for SSL even worseno request compression * http://code.google.com/speed/articles/web-metrics.html + Cotendo measurements
    • CompressionOptionalOnly for response body ~99% of browsers support Particularly important on small pipes (mobile)15%-30% of responses not compressed for no good reason!* for SSL even worseno request compressionno header compression * http://code.google.com/speed/articles/web-metrics.html + Cotendo measurements
    • Headers Redundant Repeat on EVERY request/response Can’t compress User-agent Cookies
    • HTTP Connection - under the hood Client Server
    • HTTP Connection - under the hood TCP Connect + Request = 1.5 RTT TCP Connect + SSL Connect + Request = 3.5 RTT Client Server
    • HTTP Connection - under the hood TCP Connect + Request = 1.5 RTT TCP Connect + SSL Connect + Request = 3.5 RTT Client Server
    • HTTP Connection - under the hood TCP Connect + Request = 1.5 RTT TCP Connect + SSL Connect + Request = 3.5 RTT Request/Response = 0.5 RTT Client Server
    • HTTP Connection - under the hood TCP Connect + Request = 1.5 RTT TCP Connect + SSL Connect + Request = 3.5 RTT Request/Response = 0.5 RTT } Client Server
    • HTTP Connection - under the hood TCP Connect + Request = 1.5 RTT TCP Connect + SSL Connect + Request = 3.5 RTT Request/Response = 0.5 RTT } } Client Server
    • HTTP Connection - under the hood TCP Connect + Request = 1.5 RTT TCP Connect + SSL Connect + Request = 3.5 RTT Request/Response = 0.5 RTT } Spun additional connections } Client Server
    • HTTP Connection - under the hood TCP Connect + Request = 1.5 RTT TCP Connect + SSL Connect + Request = 3.5 RTT Request/Response = 0.5 RTT Slow Start - 30KB ~ 4 RTT (vs. 1 RTT warm) Spun additional connections Client Server
    • “Lost” Capacity on each RTTUser Data: User Data:average bandwidth average RTT BW Mbps RTT ms Global 1.9 Broadband 30 US 5.1 Coast-to-Coast 100 Mobile - US 1.1 3G device-GW 80-200 Mobile - EU ~2Source: State of the Internet, Q4 2010http://www.akamai.com/stateoftheinternet/ US Broadband: 63.7KB US Mobile: 27.5KB Average obj size 8.1KB Source: HTTP Archive, 6/1/2011 data for Top 1,000 http://httparchive.org
    • Security is optionalhttp://desktopsecuritysoftwareguide.com/wp-content/uploads/2010/04/Padlock.jpg
    • Enters SPDY!
    • Requirements Avoid requiring the website author to change content Allow for incremental changes Performing "better" with content changes is okay Performing "worse" without content changes is unacceptable Perform always better, never worse than HTTP Drop-in replacement from webapps point of view  Changing the web server/application server is inevitable and therefore acceptable
    • What is SPDY? Goal: Reduce Web Page Load time. Multiplexing  Better utilize client connections Compression  HTTP headers are excessive  Uplink bandwidth is limited Prioritization  Today the browser holds back  Priorities enable multiplexing Encrypted & Authenticated  Eavesdropping at the Cafe must be stopped Server Push  Websites do some of this today with data URLs
    • Deployment Status
    • Deployment Status Google  Enabled for all Google SSL traffic  On by default since Chrome 6
    • Deployment Status Google  Enabled for all Google SSL traffic  On by default since Chrome 6 CDNs/Service providers:  Cotendo
    • Deployment Status Google  Enabled for all Google SSL traffic  On by default since Chrome 6 CDNs/Service providers:  Cotendo Server implementations:  Strangeloop  SPDY Proxy available  Others: C++, Python, Ruby, Go
    • Deployment Status Google  Enabled for all Google SSL traffic  On by default since Chrome 6 CDNs/Service providers:  Cotendo Server implementations:  Strangeloop  SPDY Proxy available  Others: C++, Python, Ruby, Go Client implementation  Chrome  Android coming...
    • Results
    • Yahoo! Homepage, over broadband network
    • Yahoo! homepage HTTP Broadband RTT = 20msPage Load: 1.23sec
    • Yahoo! homepage SPDY (via Cotendo) Broadband RTT = 20msPage Load: 1.21sec -2%
    • Amazon.com Homepage, over 3G network
    • Amazon.com Homepage HTTP 3G, AT&T RTT = 200+msPage Load: 12.50sec
    • Amazon.com Homepage SPDY (via Cotendo) 3G AT&T RTT = 200+msPage Load: 6.26sec -49%
    • HTTPS vs SPDY (Production)
    • Increasing Parallelism
    • Less is More - Conns, Bytes, Packets
    • Not Too Shabby WebSockets docs.google.com has a "hanging get" for every doc open how to scale beyond 6 connections per domain?  docs[1-N].google.com gets expensive, complicated, and is horribly inefficient SPDY is easy, works great, efficient Header compression mitigates the inefficiency of a hanging GET
    • Cant We Address Latency & Security Separately?
    • Cant We Address Latency & Security Separately? No.
    • Cant We Address Latency & Security Separately?  If eavesdropping in the cafe is still possible in 2020 with trivial tools, we have failed our users.  Security is not just for banks!  Social/Mail/Content is a major target  example: Comodo attack  Firesheep tools make sniffing easy  Major content providers want privacy  Facebook opt-in  Twitter opt-in  Google working toward 100%
    • How we tune today
    • High Performance Web Sites 1.Make fewer HTTP requests 2.Use CDN 3.Add expires header 4.Gzip Components 5.Put stylesheets at the top 6.Put scripts at the bottom 7.Avoid CSS expressions 8.Make JS and CSS external 9.Reduce DNS lookups 10.Minify JS 11.Avoid redirects 12.Remove duplicate scripts 13.Configure Etags 14.Make Ajax cacheable 15.Sharding domains
    • High Performance Web Sites 1.Make fewer HTTP requests 2.Use CDN 3.Add expires header 4.Gzip Components Du 5.Put stylesheets at the top 6.Put scripts at the bottom e 7.Avoid CSS expressions To 8.Make JS and CSS external HT 9.Reduce DNS lookups TP 10.Minify JS Li 11.Avoid redirects m 12.Remove duplicate scripts ita 13.Configure Etags tio 14.Make Ajax cacheable ns 15.Sharding domains !
    • Firetruck
    • Domain Sharding
    • Domain Sharding Pros:  Parallelism in HTTP  Cookieless domains for static content
    • Domain Sharding Pros:  Parallelism in HTTP  Cookieless domains for static content
    • Domain Sharding Pros:  Parallelism in HTTP  Cookieless domains for static content Cons:  DNS time  Connection establishment overhead  TCP slowstart / warmup  SSL  maintaining many connections  user cache  Prevents browser optimizations
    • Reduce number of requests Inlining Spriting Data URLs Combining javascripts and CSS files Cons:  reduced cache efficiency  Complicated
    • New Class of FEO
    • Rethink your optimizations As rules change, your need to re-evaluate your best practices  13 years is a long time! start at the beginning... But also presents many new opportunities  Delivery priorities  Smart Push  Simple web code  Automate!
    • Image Compression Number of Requests Transfer Size in KB Other HTML Other HTML 7.0 6.5 99 32 Scripts Scripts 119 13.0 Stylesheets Stylesheets 25 3.5 Images Images 55.0 415 Source: http://httparchive.org/trends.php?s=Top1000
    • In mobile even stronger! Number of Requests Transfer Size in KB Other HTML 2 Other 4 HTML 6 42 Scripts 7 Scripts Stilesheets 80 2 Images Images 228 31 Stilesheets 20 Source: http://mobile.httparchive.org/trends.php?s=Top1000
    • Lossy compression is the way to go! Billy Hoffman / Zoompf AP Photo/John Bazemore
    • Lossy-Compression is Not for Everythinghttp://www.flickr.com/photos/tracy_olson/61056391/
    • Progressive image compression http://images.sixrevisions.com/2010/12/01-02_baseline_vs_progressive.jpg
    • Client Server
    • Client Server Get HTML
    • Client Server
    • Client Server Get all objects
    • Client Server 20% 20% 20% 20% 20%
    • Client Server 80% 80% 80% 80% 80%
    • Summary
    •  SPDY actually delivers!
    •  SPDY actually delivers!  but we are still in the early phases
    •  SPDY actually delivers!  but we are still in the early phases  participate and be part of the solution
    •  SPDY actually delivers!  but we are still in the early phases  participate and be part of the solution
    •  SPDY actually delivers!  but we are still in the early phases  participate and be part of the solution Rules CAN be broken. Changes are possible!
    •  SPDY actually delivers!  but we are still in the early phases  participate and be part of the solution Rules CAN be broken. Changes are possible!  HTTP is built into the internet architecture, it can’t be changed.
    •  SPDY actually delivers!  but we are still in the early phases  participate and be part of the solution Rules CAN be broken. Changes are possible!  HTTP is built into the internet architecture, it can’t be changed.  What’s next?
    •  SPDY actually delivers!  but we are still in the early phases  participate and be part of the solution Rules CAN be broken. Changes are possible!  HTTP is built into the internet architecture, it can’t be changed.  What’s next?
    •  SPDY actually delivers!  but we are still in the early phases  participate and be part of the solution Rules CAN be broken. Changes are possible!  HTTP is built into the internet architecture, it can’t be changed.  What’s next? Opens the door to implement new class of optimizations
    •  SPDY actually delivers!  but we are still in the early phases  participate and be part of the solution Rules CAN be broken. Changes are possible!  HTTP is built into the internet architecture, it can’t be changed.  What’s next? Opens the door to implement new class of optimizations
    •  SPDY actually delivers!  but we are still in the early phases  participate and be part of the solution Rules CAN be broken. Changes are possible!  HTTP is built into the internet architecture, it can’t be changed.  What’s next? Opens the door to implement new class of optimizations Get engaged NOW!
    • Measurement - Proving us Right No 3rd party tools (yet)! Chrome developer tools  not good for large scale data... w3c Web Performance tools - Navigation Timing  Supported on IE9, and Chrome 11+  http://w3c-test.org/webperf/specs/NavigationTiming/ Site metrics:  Google Analytics
    • Ido Safruti, ido@cotendo.comMike Belshe, mbelshe@google.com