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

2,155
views

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

0 Comments
7 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,155
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
35
Comments
0
Likes
7
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. 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: http://pubmatic.com/adpriceindex/index.html
  • 3. quot;Improving our latency is really, really importantquot; +0.5 seconds costs Google 20% search traffic Marissa Mayer, Google http://bit.ly/idItc ~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 http://glinden.blogspot.com/2006/11/marissa-mayer-at-web-20.html http://home.blarg.net/~glinden/StanfordDataMining.2006-11-29.ppt
  • 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 http://www.youtube.com/watch?v=6x0cAzQ7PVs ~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 http://en.wikipedia.org/wiki/Image:BodhidharmaYoshitoshi1887.jpg 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 http://www.flickr.com/photos/philmcelhinney/1000986005/
  • 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: http://bit.ly/quartermile-src • XML spec: http://bit.ly/quartermile-app
  • 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 http://www.flickr.com/photos/rudolf_schuba/153225000/
  • 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;http://your.server.com/ping.gifquot;;
  • 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 http://example.org/css/style.css?v=3
  • 28. Server Assisted Optimizations Photo by zappowbang http://www.flickr.com/photos/zappowbang/3202362752/
  • 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 = gadgets.io.getProxyUrl( quot;http://me.com/flash.swfquot;); 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 http://www.flickr.com/photos/psd/2841928867/in/datetaken 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;http://yoursite.com/proxied.phpquot; 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 opensocial.example.org Content-Type: application/json { invalidationKeys : [ quot;http://www.myapp.com/gadgetspec.xmlquot;, quot;http://yoursite.com/proxied.phpquot; quot;user:123quot;] }
  • 43. Optimizing Your Data Store Image by euthman http://www.flickr.com/photos/euthman/1846038389/
  • 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 http://www.flickr.com/photos/redjar/704710355/
  • 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;>${Cur.name.givenName}</div> </script> ]]></Content> </Module>
  • 57. Summary Photo by peagreengirl http://www.flickr.com/photos/peagreenchick/384744358/in/photostream/
  • 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 http://stevesouders.com/ 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 http://commons.wikimedia.org/wiki/File:Satori.svg public domain
  • 62. Page Speed Firefox Extension • Released June 4 2009 • http://code.google.com/speed/page-speed/ 63
  • 63. Google Developer Relations Japan • Google – Google Developer Day – http://sites.google.com/site/devreljp/ 64
  • 64. code.google.com • Google – – http://code.google.com/intl/ja/ 65
  • 65. • Google Developer Day • 2 – – • – Google Developer Relations Japan http://sites.google.com/site/devreljp/ 66
  • 66. Q&A