Your SlideShare is downloading. ×
0
Cloud Performance: Guide to Tackling Cloud Latency [Cloud Connect - Chicago 2012]
Cloud Performance: Guide to Tackling Cloud Latency [Cloud Connect - Chicago 2012]
Cloud Performance: Guide to Tackling Cloud Latency [Cloud Connect - Chicago 2012]
Cloud Performance: Guide to Tackling Cloud Latency [Cloud Connect - Chicago 2012]
Cloud Performance: Guide to Tackling Cloud Latency [Cloud Connect - Chicago 2012]
Cloud Performance: Guide to Tackling Cloud Latency [Cloud Connect - Chicago 2012]
Cloud Performance: Guide to Tackling Cloud Latency [Cloud Connect - Chicago 2012]
Cloud Performance: Guide to Tackling Cloud Latency [Cloud Connect - Chicago 2012]
Cloud Performance: Guide to Tackling Cloud Latency [Cloud Connect - Chicago 2012]
Cloud Performance: Guide to Tackling Cloud Latency [Cloud Connect - Chicago 2012]
Cloud Performance: Guide to Tackling Cloud Latency [Cloud Connect - Chicago 2012]
Cloud Performance: Guide to Tackling Cloud Latency [Cloud Connect - Chicago 2012]
Cloud Performance: Guide to Tackling Cloud Latency [Cloud Connect - Chicago 2012]
Cloud Performance: Guide to Tackling Cloud Latency [Cloud Connect - Chicago 2012]
Cloud Performance: Guide to Tackling Cloud Latency [Cloud Connect - Chicago 2012]
Cloud Performance: Guide to Tackling Cloud Latency [Cloud Connect - Chicago 2012]
Cloud Performance: Guide to Tackling Cloud Latency [Cloud Connect - Chicago 2012]
Cloud Performance: Guide to Tackling Cloud Latency [Cloud Connect - Chicago 2012]
Cloud Performance: Guide to Tackling Cloud Latency [Cloud Connect - Chicago 2012]
Cloud Performance: Guide to Tackling Cloud Latency [Cloud Connect - Chicago 2012]
Cloud Performance: Guide to Tackling Cloud Latency [Cloud Connect - Chicago 2012]
Cloud Performance: Guide to Tackling Cloud Latency [Cloud Connect - Chicago 2012]
Cloud Performance: Guide to Tackling Cloud Latency [Cloud Connect - Chicago 2012]
Cloud Performance: Guide to Tackling Cloud Latency [Cloud Connect - Chicago 2012]
Cloud Performance: Guide to Tackling Cloud Latency [Cloud Connect - Chicago 2012]
Cloud Performance: Guide to Tackling Cloud Latency [Cloud Connect - Chicago 2012]
Cloud Performance: Guide to Tackling Cloud Latency [Cloud Connect - Chicago 2012]
Cloud Performance: Guide to Tackling Cloud Latency [Cloud Connect - Chicago 2012]
Cloud Performance: Guide to Tackling Cloud Latency [Cloud Connect - Chicago 2012]
Cloud Performance: Guide to Tackling Cloud Latency [Cloud Connect - Chicago 2012]
Cloud Performance: Guide to Tackling Cloud Latency [Cloud Connect - Chicago 2012]
Cloud Performance: Guide to Tackling Cloud Latency [Cloud Connect - Chicago 2012]
Cloud Performance: Guide to Tackling Cloud Latency [Cloud Connect - Chicago 2012]
Cloud Performance: Guide to Tackling Cloud Latency [Cloud Connect - Chicago 2012]
Cloud Performance: Guide to Tackling Cloud Latency [Cloud Connect - Chicago 2012]
Cloud Performance: Guide to Tackling Cloud Latency [Cloud Connect - Chicago 2012]
Cloud Performance: Guide to Tackling Cloud Latency [Cloud Connect - Chicago 2012]
Cloud Performance: Guide to Tackling Cloud Latency [Cloud Connect - Chicago 2012]
Cloud Performance: Guide to Tackling Cloud Latency [Cloud Connect - Chicago 2012]
Cloud Performance: Guide to Tackling Cloud Latency [Cloud Connect - Chicago 2012]
Cloud Performance: Guide to Tackling Cloud Latency [Cloud Connect - Chicago 2012]
Cloud Performance: Guide to Tackling Cloud Latency [Cloud Connect - Chicago 2012]
Cloud Performance: Guide to Tackling Cloud Latency [Cloud Connect - Chicago 2012]
Cloud Performance: Guide to Tackling Cloud Latency [Cloud Connect - Chicago 2012]
Cloud Performance: Guide to Tackling Cloud Latency [Cloud Connect - Chicago 2012]
Cloud Performance: Guide to Tackling Cloud Latency [Cloud Connect - Chicago 2012]
Cloud Performance: Guide to Tackling Cloud Latency [Cloud Connect - Chicago 2012]
Cloud Performance: Guide to Tackling Cloud Latency [Cloud Connect - Chicago 2012]
Cloud Performance: Guide to Tackling Cloud Latency [Cloud Connect - Chicago 2012]
Cloud Performance: Guide to Tackling Cloud Latency [Cloud Connect - Chicago 2012]
Cloud Performance: Guide to Tackling Cloud Latency [Cloud Connect - Chicago 2012]
Cloud Performance: Guide to Tackling Cloud Latency [Cloud Connect - Chicago 2012]
Cloud Performance: Guide to Tackling Cloud Latency [Cloud Connect - Chicago 2012]
Cloud Performance: Guide to Tackling Cloud Latency [Cloud Connect - Chicago 2012]
Cloud Performance: Guide to Tackling Cloud Latency [Cloud Connect - Chicago 2012]
Cloud Performance: Guide to Tackling Cloud Latency [Cloud Connect - Chicago 2012]
Cloud Performance: Guide to Tackling Cloud Latency [Cloud Connect - Chicago 2012]
Cloud Performance: Guide to Tackling Cloud Latency [Cloud Connect - Chicago 2012]
Cloud Performance: Guide to Tackling Cloud Latency [Cloud Connect - Chicago 2012]
Cloud Performance: Guide to Tackling Cloud Latency [Cloud Connect - Chicago 2012]
Cloud Performance: Guide to Tackling Cloud Latency [Cloud Connect - Chicago 2012]
Cloud Performance: Guide to Tackling Cloud Latency [Cloud Connect - Chicago 2012]
Cloud Performance: Guide to Tackling Cloud Latency [Cloud Connect - Chicago 2012]
Cloud Performance: Guide to Tackling Cloud Latency [Cloud Connect - Chicago 2012]
Cloud Performance: Guide to Tackling Cloud Latency [Cloud Connect - Chicago 2012]
Cloud Performance: Guide to Tackling Cloud Latency [Cloud Connect - Chicago 2012]
Cloud Performance: Guide to Tackling Cloud Latency [Cloud Connect - Chicago 2012]
Cloud Performance: Guide to Tackling Cloud Latency [Cloud Connect - Chicago 2012]
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Cloud Performance: Guide to Tackling Cloud Latency [Cloud Connect - Chicago 2012]

2,853

Published on

Performance matters. And in the cloud, performance matters more than ever—layers of complexity and third-party, shared environments separate users from applications. Services are elastic, which means …

Performance matters. And in the cloud, performance matters more than ever—layers of complexity and third-party, shared environments separate users from applications. Services are elastic, which means you can have any SLA you want, as long as you're willing to design it yourself. And you can have a fast application, too—if you're willing to deal with the bill at the end of the month.

So how should you think about cloud performance? In this in-depth workshop on the performance of cloud computing, three cloud computing and Internet performance experts—Steve Riley (Riverbed, Amazon), Hooman Beheshti (Strangeloop, Radware) and Alistair Croll (Coradiant, CloudOps)—take you on a tour of the challenges on-demand computing poses to reliable, fast user experiences.

What you'll learn:

- The new models of delay, capacity, and uptime that on-demand computing requires
- What and how to measure when it comes to performance, and how to think about metrics
- Where delay happens across the cloud environment
- How shared computing and back-end contention affect user experience
- What the WAN and the Application Delivery Network mean in a cloudy compute model
- How to spread load and optimize application front-ends to speed up applications

Published in: Technology, Design
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,853
On Slideshare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
58
Comments
0
Likes
2
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Web Acceleration and Front End Optimization Cloud Connect 2012 Chicago Hooman Beheshti VP Technology, Strangeloop hooman@strangeloopnetworks.com
  • 2. Web Application Acceleration •  Means lots of things to lots of people –  TCP optimization –  Caching –  HTTP protocol optimization –  Compression –  Etc •  We’ll focus on “front-end” issues –  Front-end Optimization (FEO) –  Sometimes called WCO or WPO © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 2
  • 3. Better Performance = Better Business © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 3
  • 4. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 4
  • 5. Impact of page load time on average dailysearches per user 0.00%-0.10%-0.20%-0.30%-0.40%-0.50%-0.60%-0.70% 50ms pre- 100ms pre- 200ms post- 200ms post- 400ms post- header header header ads header© 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 5
  • 6. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 6
  • 7. Impact of additional delay on business metrics 0.00% -0.50% Percent change -1.00% -1.50% -2.00% -2.50% -3.00% -3.50% -4.00% -4.50% -5.00% 50 200 500 1000 2000 Added delay Queries per visitor Query refinement Revenue per visitor Any clicks Satisfaction© 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 7
  • 8. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 8
  • 9. Shopzilla had another angle —  Big, high-traffic site —  16 month re- ◦  100M impressions a day engineering ◦  Page load from 6 seconds ◦  8,000 searches a to 1.2 second ◦  Uptime from 99.65% to ◦  20-29M unique visitors 99.97% a month ◦  10% of previous hardware ◦  100M products needs© 2010 Strangeloop Networks http://en.oreilly.com/velocity2009/public/schedule/detail/7709 Strangeloop. Faster Websites. Automatically. 9
  • 10. 5-12% increase in revenue © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 10
  • 11. Mobile Case Study © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 11
  • 12. Customer Pro"le •  Top 200 Internet retailer, US based •  Target geography: US and Europe •  $3B in revenue •  30,000 employees © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 12
  • 13. Page Views by Mobile Device © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 13
  • 14. Experiment •  Induce delay on HTML –  200msec, 500msec, 1000msec •  Apply to small percentage of tra#c •  12 weeks •  Monitor impact on key business metrics © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 14
  • 15. Results © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 15
  • 16. Impact on Bounce Rate © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 16
  • 17. Impact on Returning Visitors © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 17
  • 18. More Details •  http://www.webperformancetoday.com/ 2011/11/23/case-study-slow-page-load-mobile- business-metrics/ •  http://velocityconf.com/velocityeu/public/ schedule/detail/21632 © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 18
  • 19. What Is FEO? © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 19
  • 20. What Is FEO? 0 6 12 © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 20
  • 21. What Is FEO? DNS TTFB TCP Download Connection 0 6 12 © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 21
  • 22. What Is FEO? Back End: The time from when the request is made by the browser to last byte of the HTML response Front End: Everything after the HTML arrives Important Timers: Start Render onload (Document Complete) 0 6 12 © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 22
  • 23. Google’s Waterfall Chart © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 23
  • 24. Measurement/Tools © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 24
  • 25. Waterfall Analysis •  Best way to address front-end problems is to diagnose your site/application through waterfall analysis © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 25
  • 26. Waterfall Tools: webpagetest.org © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 26
  • 27. Waterfall Tools: HTTPWatch © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 27
  • 28. Waterfall Tools: Firebug © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 28
  • 29. Waterfall Tools: WebKit Dev Tools © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 29
  • 30. Waterfall Tools: PCAP2HAR © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 30
  • 31. Measurement •  Performance measurement is still a challenge •  Synthetic performance “proxies” –  Backbone testing services –  Desktop tools and browser plugins –  Browser-based tests •  Real User Monitoring (RUM) –  Using real user beacons –  Services available –  Can build your own –  Now a part of Google Analytics –  Caveat: need lots of data! © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 31
  • 32. Front End Problems © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 32
  • 33. Front End Performance Problems © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 33
  • 34. Front End Performance Problems •  Latency: –  every round trip incurs a latency penalty © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 34
  • 35. Front End Performance Problems •  Latency: –  every round trip incurs a latency penalty •  Payload: –  last mile bandwidth isn’t in"nite © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 35
  • 36. Front End Performance Problems •  Latency: –  every round trip incurs a latency penalty •  Payload: –  last mile bandwidth isn’t in"nite •  Caching: –  coming back to the page must be much faster © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 36
  • 37. Front End Performance Problems •  Latency: –  every round trip incurs a latency penalty •  Payload: –  last mile bandwidth isn’t in"nite •  Caching: –  coming back to the page must be much faster •  Rendering: –  browser work takes time © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 37
  • 38. Client Platforms •  Desktop vs Mobile –  Desktop browsers have more access to compute resources –  Larger screens –  Faster networks (lower latency) •  The problems are often similar –  Addressing them is often di$erent © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 38
  • 39. Addressing Front End Problems © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 39
  • 40. Latency •  TTFB (Time To First Byte) •  Every fetch incurs the latency penalty •  Two ways to address the problem: –  Reduce latency –  Get rid of round trips © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 40
  • 41. CDN •  Global network of caching proxies that gets content closer to all your users •  The closer the asset, the lower the latency •  Lots of vendors to choose from © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 41
  • 42. CDN Per object TTFB savings of ~50% © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 42
  • 43. CDN: because physics!! •  Well understood way to leverage science •  Mitigates the latency problem by reducing it for the majority of your users •  Less e$ective when it comes to mobile users © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 43
  • 44. Mobile Networks (3G example) © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 44
  • 45. Resource Consolidation •  Eliminating round trips altogether also "ghts the latency problem, often more e$ectively Combine images into fewer "packages" © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 45
  • 46. Resource Consolidation •  A number of consolidation techniques –  Images (sprites) –  JavaScript/CSS consolidation/concatenation –  Inlining (DataURI for images) –  MHTML (IE only) •  Browser makes one request for the “package” •  HTML is marked up so the browser can get individual resources from inside the package © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 46
  • 47. Payload Reduction •  Bytes still need to get from server (cloud or otherwise) to client •  Ways to reduce bytes: –  HTTP compression –  JS/CSS mini"cation –  Image compression (lossless or lossy) © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 47
  • 48. Payload Reduction •  Any reduction in bytes will make pages load faster •  This is particularly important with mobile clients © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 48
  • 49. Browser Caching •  The browser cache is a resource seldom used optimally •  Reasons why we generally don’t do good browser caching –  Caching rules are often complicated –  We never want to server stale content © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 49
  • 50. Browser Caching •  Use long expiry on static objects –  Served from origin –  Served from CDN •  Invalidation framework is a must –  Protect against serving stale content –  Example: versioning /images/image.jpg à /images/image.jpg?v=00001 © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 50
  • 51. Browser Caching on Mobile Platforms •  Di$erent than desktop •  The cache available to the browsers is relatively small •  Use localStorage instead of browser cache –  A programmable cache, unlike HTTP object caches –  Limited size (~2.5MB per domain) –  Good for caching CSS/JS, and small images © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 51
  • 52. Rendering Issues •  More complicated •  The order of events in the browser make a di$erence to how fast a page looks –  Put things in the optimal order for rendering •  Deferral –  CSS and JS (sometimes images) –  Asynchronous JavaScript •  Above the fold vs below the fold © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 52
  • 53. Some Examples © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 53
  • 54. Before and After Waterfalls Before FEO After FEO First Time Visitor 58 roundtrips à 5 roundtrips 4.2 seconds à 1.1 seconds Repeat Visitor 57 roundtrips à 4 roundtrips 3.2 seconds à 0.7 seconds © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 54
  • 55. Mobile Example •  Velocity Conference 2012 •  Step-wise acceleration of O’reilly’s site (for a mobile phone on 3G) –  Start with the original site (purposely made worse) –  Add CDN –  Add resource consolidation and payload reduction –  Add deferrals •  Examine impact of each © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 55
  • 56. What Does it Look Like? http://youtu.be/iPtbU1KvLjM © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 56
  • 57. Original Site + CDN 15.29 sec 13.7 sec © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 57
  • 58. Add Consolidation and Payload Reduction 9.47 sec To onload Before After 13.7 sec # of resources 92 28 KBytes 727 417 © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 58
  • 59. Add Deferral © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 59
  • 60. Add Deferral © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 60
  • 61. Add Deferral 2.2 sec 3.6 sec 9.47 sec 5.56 sec© 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 61
  • 62. What Does It Look Like? http://youtu.be/zTTxdAtbhsg MobileFEO = +Consolidation and payload reduction MobileFEO2 = +Deferrals © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 62
  • 63. Summing up… © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 63
  • 64. Sounds Really Easy! •  It’s not! •  Some techniques are just di#cult to implement •  Optimizing for performance sometimes requires signi"cant dev resources –  Mortal companies can’t a$ord to sacri"ce new feature cycles •  Maintenance and upkeep is a constant problem –  Every version to roll out will need optimization © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 64
  • 65. FEO Automation Industry •  Solutions available to automatically do this stu$ •  Multiple deployment options –  Software/Hardware/Service –  Cloud apps will use either service or software •  The goal is to “"x the code” for performance, automatically © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 65
  • 66. It Gets Complicated •  Rewriting HTML can break pages •  You have to do this stu$ based on browser –  Play to the strength of each browser (supported techniques, etc) –  Stay away from their weaknesses (bugs, undocumented issues, etc) –  Mobile is its own beast •  Optimizing once per page isn’t enough –  First view (cold cache) –  Repeat view (warm cache) –  User "ow © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 66
  • 67. When Looking For FEO Automation •  Do your research, and understand your needs •  Understand the deployment model and how disruptive it will be to you, if at all •  Are there provisions in place for breaking pages •  Granularity in functionality: –  Browser-based optimization –  mobile –  "rst/repeat views –  transaction %ows •  Choose what’s right for you, based on your needs © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 67
  • 68. Thank You hooman@strangeloopnetworks.com 68

×