Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

GDD Japan 2009 - Designing OpenSocial Apps For Speed and Scale


Published on

Google Developer Days Japan 2009 - Designing OpenSocial Apps For Speed and Scale
Original slides from Arne Roomann-Kurrik & Chris Chabot with a few Zen quotes and references added by me:-)

Published in: Technology
  • Be the first to comment

GDD Japan 2009 - Designing OpenSocial Apps For Speed and Scale

  1. 1. Designing OpenSocial Apps For Speed and Scale Patrick Chanezon with slides from Arne Roomann-Kurrik & Chris Chabot June 9 2009
  2. 2. Success In A Social Market • Social application eCPM is lower than average • Direct access to millions of signed in users o Growth functionality built into social platforms • Small margins x Lots of users = Small Tweaks Matter Chart from Pubmatic AdPrice Index 2008:
  3. 3. quot;Improving our latency is really, really importantquot; +0.5 seconds costs Google 20% search traffic Marissa Mayer, Google ~12:50
  4. 4. quot;Even very small delays would result in substantial and costly drops in revenuequot; +0.1 seconds costs Amazon 1% of sales Greg Linden, Amazon
  5. 5. quot;If you make a product faster, you get that back in terms of increased usagequot; -30KB gave Google Maps 30% growth in 3 weeks Marissa Mayer, Google ~18:10
  6. 6. A monk asked Joshu: “Will my web application have Buddha-nature if I optimize for speed or number of features?” Joshu answered: “Mu” Liberally adapted from “Zen Flesh, Zen Bones” Jōshū Jūshin (778–897) Image Source public domain
  7. 7. This Presentation • Measure impact of changes on large scale apps • Sample OpenSocial application o Different strategies o Real performance numbers • Goals o Deliver a fast user experience o Minimize costs of running a large social app o Highlight new OpenSocial features
  8. 8. Introducing Quartermile Photo by Phil McElhinney
  9. 9. Quartermile UI
  10. 10. Building Quartermile • Backend: o Built on Google App Engine o Remote Procedure Calls o JSON • Frontend: o Gadgets on many containers o JavaScript library for RPC calls • View the source: • XML spec:
  11. 11. Measuring Quartermile • Request types o Quartermile API o OpenSocial API o Assets (images, JS, CSS) • Metrics o Bandwidth / PV (KB) o Requests / PV (#) o Latency / PV (ms) o CPU time (megacycles) • Measuring each individually is important • Have more control over some than others
  12. 12. Quartermile 'Naive' Implementation Metrics Bandwidth / Requests / PV Latency CPU time PV(kb) (ms) (megacycles) Quartermile API calls 4.21 4 6490 2078 Social requests 1.45 2 804 0 Assets 135.6 22 3152 0
  13. 13. Quartermile 'Naive' Implementation Costs
  14. 14. Web Development Best Practices* * Gadgets are web pages too! Photo by rudolf_schuba
  15. 15. Web Development Best Practices Gadgets are web pages too! • We're interested in the following metrics: o Application size o Request count o Latency of initial load • Measuring o Safari: Web Inspector o Firefox: Firebug & YSlow o IE: HttpWatch
  16. 16. Web Development Best Practices Minify JavaScript & CSS • Concatenate JavaScript & CSS files o Reduces latency o Reduces HTTP Requests • Compress JavaScript and CSS o Reduces download size var foo = ['1','2','3','4']; for (var i = 0 ; i < 4 ; i++) { alert(foo[i]); } var foo=[quot;1quot;,quot;2quot;,quot;3quot;,quot;4quot;];for(var i=0;i<4;i++){alert(foo[i])}
  17. 17. Web Development Best Practices Determining application size
  18. 18. Quartermile Improvement After JavaScript + CSS Minification (YUI Compressor)
  19. 19. Web Development Best Practices Measuring Latency
  20. 20. Web Development Best Practices Measuring latency
  21. 21. Web Development Best Practices Latency is not a static number
  22. 22. Web Development Best Practices Decreasing latency increases user happiness and engagement • Measure from different locations • Measure often
  23. 23. Web Development Best Practices Automatically collecting latency measurements • JavaScript code for recording gadget latency: var startTime = new Date(); var imgElement = new Image() imgElement.onload = function() { var endTime = new Date(); var latency = endTime. getTime() - startTime.getTime(); // report latency back to your server } imgElement.src = quot;;;
  24. 24. Web Development Best Practices Spriting Images • Concatenate images into a single file (sprite) and use CSS to selectively display portions of the sprite o Reduce # of requests o Reduce latency
  25. 25. Web Development Best Practices Determining Request Count With YSlow!
  26. 26. Quartermile Improvement After Image Spriting
  27. 27. Web Development Best Practices Adjusting Cache Headers • Use the browser's cache for static data o Reduces total bandwidth & requests o Reduces latency • Apache configuration example: <FilesMatch quot;.(css|js|gif|jpe?g|png)$quot;> Header set Cache-Control quot;max-age=290304000, publicquot; </FilesMatch> • Use Cache-busting to force refresh
  28. 28. Server Assisted Optimizations Photo by zappowbang
  29. 29. Server Assisted Optimizations • Social gadget: o Small tweak == big gain • Social network o Many small tweaks == very big gain • Social network advantages: o Control over the HTML they output o Better network infrastructure
  30. 30. Static Content Proxies • Social network willing to absorb some traffic for you o Could use content delivery networks (CDNs) o Distributed network, great for serving static content all over the world • Important for clients further away from your servers! var div = $(quot;#flashcontainerquot;); var url = quot;;); gadgets.flash.embedFlash(url, div, 10);
  31. 31. Content Rewriting • Social network has control over its own output o CSS first, JS last o Concatenate, Minify o Rewrite URLs for static proxy • Caching controls in your gadget spec: <Module> <ModulePrefs> <Optional feature=quot;content-rewritequot;> <Param name=quot;include-urlsquot;></Param> <Param name=quot;exclude-urlsquot;>.*</ Param> <Param name=quot;include-tagsquot;></Param> </Optional> ...
  32. 32. OpenSocial Best Image by Paul Downey Practices
  33. 33. OpenSocial: Designed For Social Apps • Some optimizations only make sense in a social application context • OpenSocial offers conveniences to social app developers • Learn from the OpenSocial API when designing your own application interfaces
  34. 34. Batching One API call == 1 HTTP request: osapi.people.getViewer().execute(onVwr); osapi.people.getOwner().execute(onOwnr); osapi.people.getViewerFriends().execute(onFr nd); osapi.people.getOwnerFriends().execute(onOFr nd); varas much as osapi.newBatch() Do batch = you can in a single trip: .add(quot;vwrquot;, osapi.people.getViewer()) .add(quot;vfdquot;, osapi.people.getViewerFriends()) .add(quot;owrquot;, osapi.people.getOwner()) .add(quot;ofdquot;, osapi.people.getOwnerFriends()) .execute(onData); 2 -> 1 OpenSocial requests 4 -> 1 Quartermile API requests
  35. 35. Quartermile Improvement After Request Batching
  36. 36. OpenSocial Best Practices Data Pipelining + Proxied Content • The Naive implementation makes a lot of requests • How can we improve on that?
  37. 37. OpenSocial Best Practices Data Pipelining + Proxied Content • Using OpenSocial 0.9's Data-Pipelining, we can declare which social data to POST to your server • Your server operates on the data and returns the HTML to display • Available in iGoogle & orkut sandboxes, coming to a container near you soon(tm)
  38. 38. OpenSocial Best Practices Data Pipelining + Proxied Content <Module> <ModulePrefs ... etc .../> <Content type=quot;htmlquot; view=quot;profilequot; href=quot;; authz=quot;signedquot;> <os:ViewerRequest key=quot;vwrDataquot; fields=quot;id,displayNamequot;/> <os:OwnerRequest key=quot;ownDataquot;/> <os:PeopleRequest key=quot;ownFriendsquot; userId=quot;@ownerquot; groupId=quot;@selfquot;/> </Content> </Module>
  39. 39. OpenSocial Best Practices Data Pipelining + Proxied Content <?php $postData = json_decode(file_get_contents(quot;php://inputquot;)); echo quot;<h1>Hello {$postData['vwrData']['name']}</h1>quot;; echo quot;These are {$postData['ownData']['name']}'s friends:quot;; echo quot;<br/>quot;; foreach ($postData['ownFriends'] as $friend) { echo quot;{$friend['name']}<br/>quot;; }
  40. 40. Quartermile Improvement After Data Pipelining
  41. 41. OpenSocial Best Practices Invalidation Pattern • New application design pattern available with the features introduced in 0.9 • When your internal state changes on the application server, use REST/RPC calls to invalidate data: o Per user or url o Application ID is determined by 2 Legged OAuth call
  42. 42. OpenSocial Best Practices Invalidation Pattern • Calling the invalidation API: POST /api/rest/cache/invalidate HOST Content-Type: application/json { invalidationKeys : [ quot;;, quot;; quot;user:123quot;] }
  43. 43. Optimizing Your Data Store Image by euthman
  44. 44. OpenSocial Best Practices Data Store Structuring • Database joins against friend lists are generally very expensive • Plan ahead if you're not using App Engine o Master / Slave architecture o Database partitioning • Use Memcache to cache data (in App Engine too!) o Filter results in software, make the most of cache • Consider storing frequently used data in JSON Blobs instead traditional relational storage
  45. 45. OpenSocial Best Practices Data Store Structuring • Consider using background processing o Updates are slightly delayed o Doesn't block user interaction o Great for quot;What are your friends doingquot; result sets • Use a off-the-shelf / open source Queue system or • App Engine, use cron.yaml: cron: - description: process activities entries url: /tasks/processActivities schedule: every 1 minutes
  46. 46. Designing Quartermile's Data Model • How to plan a scalable social application? • Prefer to enforce hard limits up front, than deliver a poor user experience • Decided friend queries were too expensive: o orkut lets you have 1000 friends o MySpace lets you have 100,000s+ of friends • Do all 100,000 friends need to see your exercises? o Created artificial idea of quot;teamsquot; o Choose a subset of friends to invite to your team o Side effect: Drive adoption!
  47. 47. Dreaming Up Reasonable Limits • Goal: Fetch all of a team's data for any given week in one database query • How many users can we put on a team? • App Engine returns 1000 entries max for any query • 1 entry / workout • 3 / day ~ 20 / week • 1000 / 20 = 50 users
  48. 48. Limits: Made To Be Broken Not every app will be able to enforce such restrictions • Goal: Implement quot;updates from your friendsquot; inside of the Quartermile app • Slow! o Fetch all friends o See which updated recently o Sort • Friend updates are lower priority than team updates o Process in the background o Fetch friends using 2-legged OAuth o Do quot;updates from friendsquot; calculation o Store result of calculation (can be stale)
  49. 49. Where To Put It? • Database • Memcache • OpenSocial App Data
  50. 50. quot;App Data is one of the most misunderstood and misused portions of the OpenSocial specificationquot; App Data is often used incorrectly Arne Roomann-Kurrik, Google May 2009 at Google I/O
  51. 51. App Data • Data store of keys and values o Essentially public, so you can't put secrets here o User writable via JS, so you can't trust it o But it's fast! • Perfect place to cache slow data • Background process does slow calculation • Pushes result to AppData • When rendered, injected directly into the gadget o No server hit!
  52. 52. Container-Mandated Optimizations Photo by redjar
  53. 53. Container-Mandated Optimizations • 'Naive' implementation: o Easy to make mistakes • Container: o Keep gadgets fast == keep container fast o Userbase affects acceptable latency values o Constraints to keep gadget developers honest
  54. 54. iGoogle's Latency • Directory will soon be taking latency into account • Implicit latency penalty, too:
  55. 55. orkut's Template-Only Profiles • Profiles: o The most traffic on orkut o Users love gadgets! • OpenSocial 0.9 templates o Can display social data o Can display App Data o No external fetches or dynamic data • Produces an extremely fast profile render • Great use case for AppData cache
  56. 56. orkut's Template-Only Profiles <Module> <ModulePrefs title=quot;Templatequot;> <Require feature=quot;opensocial-dataquot; /> <Require feature=quot;opensocial-templatesquot;> <Param name=quot;process-on-serverquot;>true</Param> </Require> </ModulePrefs> <Content type=quot;htmlquot; view=quot;profilequot;><![CDATA[ <script type=quot;text/os-dataquot;> <os:PeopleRequest key=quot;friendsquot; userId=quot;@viewerquot; groupId=quot;@friendsquot;/> </script> <script type=quot;text/os-templatequot;> <div repeat=quot;${friends}quot;>${}</div> </script> ]]></Content> </Module>
  57. 57. Summary Photo by peagreengirl
  58. 58. Summary Comparison of each technique App Size: Latency: • JS Minification • JS Minification • Content Rewriting • Spriting • Content Proxy • Content Rewriting • Pipelining • Content Proxy • Invalidation • Batching • Cache Headers • Data Store Optimization • Background • App Data Cache Requests: • Pipelining • JS Minification • Invalidation • Spriting • Limited Profiles • Content Rewriting • Cache Headers • Cache Headers
  59. 59. Quartermile 'Most Optmized' Implementation
  60. 60. All you ever wanted to know about web apps performance tuning 61
  61. 61. Performance ?) A monk asked Zhaozhou to teach him. Zhaozhou asked, quot;Have you eaten your meal?quot; The monk replied, quot;Yes, I have.quot; quot;Then go wash your bowlquot;, said Zhaozhou. At that moment, the monk was enlightened. , Mumonkan Image Source public domain
  62. 62. Page Speed Firefox Extension • Released June 4 2009 • 63
  63. 63. Google Developer Relations Japan • Google – Google Developer Day – 64
  64. 64. • Google – – 65
  65. 65. • Google Developer Day • 2 – – • – Google Developer Relations Japan 66
  66. 66. Q&A