Your SlideShare is downloading. ×
GDD Japan 2009 - Designing OpenSocial Apps For Speed and Scale
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.


Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

GDD Japan 2009 - Designing OpenSocial Apps For Speed and Scale


Published on

Google Developer Days Japan 2009 - Designing OpenSocial Apps For Speed and Scale …

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

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1. Designing OpenSocial Apps For Speed and Scale Patrick Chanezon with slides from Arne Roomann-Kurrik & Chris Chabot June 9 2009
  • 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. quot;Improving our latency is really, really importantquot; +0.5 seconds costs Google 20% search traffic Marissa Mayer, Google ~12:50
  • 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. 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. 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. 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. Introducing Quartermile Photo by Phil McElhinney
  • 9. Quartermile UI
  • 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. 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. 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. Quartermile 'Naive' Implementation Costs
  • 14. Web Development Best Practices* * Gadgets are web pages too! Photo by rudolf_schuba
  • 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. 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. Web Development Best Practices Determining application size
  • 18. Quartermile Improvement After JavaScript + CSS Minification (YUI Compressor)
  • 19. Web Development Best Practices Measuring Latency
  • 20. Web Development Best Practices Measuring latency
  • 21. Web Development Best Practices Latency is not a static number
  • 22. Web Development Best Practices Decreasing latency increases user happiness and engagement • Measure from different locations • Measure often
  • 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. 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. Web Development Best Practices Determining Request Count With YSlow!
  • 26. Quartermile Improvement After Image Spriting
  • 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. Server Assisted Optimizations Photo by zappowbang
  • 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. 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. 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. OpenSocial Best Image by Paul Downey Practices
  • 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. 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. Quartermile Improvement After Request Batching
  • 36. OpenSocial Best Practices Data Pipelining + Proxied Content • The Naive implementation makes a lot of requests • How can we improve on that?
  • 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. 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. 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. Quartermile Improvement After Data Pipelining
  • 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. 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. Optimizing Your Data Store Image by euthman
  • 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. 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. 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. 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. 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. Where To Put It? • Database • Memcache • OpenSocial App Data
  • 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. 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. Container-Mandated Optimizations Photo by redjar
  • 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. iGoogle's Latency • Directory will soon be taking latency into account • Implicit latency penalty, too:
  • 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. 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. Summary Photo by peagreengirl
  • 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. Quartermile 'Most Optmized' Implementation
  • 60. All you ever wanted to know about web apps performance tuning 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. Page Speed Firefox Extension • Released June 4 2009 • 63
  • 63. Google Developer Relations Japan • Google – Google Developer Day – 64
  • 64. • Google – – 65
  • 65. • Google Developer Day • 2 – – • – Google Developer Relations Japan 66
  • 66. Q&A