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

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

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