David Wei And Changhao Jiang Presentation

2,491 views
2,423 views

Published on

Published in: Spiritual, Business
0 Comments
6 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,491
On SlideShare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
41
Comments
0
Likes
6
Embeds 0
No embeds

No notes for slide
  • Deep integration: Each facebook home page is customized for a particular user, with features developed by many teams– some of them are applications by 3rd party developers, some of them are internal facebook feature – depending on the users’ adoption on the features and applications.Viral Adoption: we don’t know what will be the most popular Facebook feature tomorrowAgile development: our codebase change by hours, released weekly
  • Deep Integration: each page has many features;Viral adoption: usage pattern changes quicklyAgile development: feature changes fast
  • Current Assumptions: bandwidth = 1Mbps and latency = 40ms
  • First thing first: site speed matters.
  • The # of JS files are increased by 60%, the byte sites are increased by 30%. The # of pkg sent is halved, the byte size is 10% less.find | grep -v .svn | grep -v intern | grep .css$ -cfind | grep -v .svn | grep -v intern | grep .css$ | xargs cat > /tmp/dwei_2008
  • Developers think that timeeditor.js is a library file – in fact, it is only used in a single production page (career)On the other hand, it turns out that “resume“ function is almost always used in career page, too.
  • CSS is a similar story
  • The same trace-base analysis techniques can be use in image spriting too:
  • The answer is…In retrospection, this is pretty straight forward.
  • [devrs007] images > find | grep -vsvn -c3407
  • David Wei And Changhao Jiang Presentation

    1. 1.
    2. 2. Adaptive Static Resource Optimization<br />AJAXian Conference 2009<br />Sep 15, 2009 Boston, MA<br />David Wei and ChanghaoJiang<br />
    3. 3. Agenda<br />
    4. 4. Optimization has to be adaptive!<br />
    5. 5. Facebook: a site powered by AJAX<br />Challenges day-to-day<br /><ul><li>Deep Integration
    6. 6. Viral Adoption
    7. 7. Agile Development</li></li></ul><li>Why we need adaptive packaging?<br />Day 1: Some smart engineers start a project!<br />&lt;Print css tag for feature A&gt;<br />&lt;Print css tag for feature B&gt;<br />&lt;Print css tag for feature C&gt;<br />&lt;print HTML of feature A&gt;<br />&lt;print HTML of feature B&gt;<br />&lt;print HTML of feature C&gt;<br />…<br />“Let’s write a new page with features A, B and C!”<br />
    8. 8. Why we need adaptive packaging?<br />Day 2: Some smart engineers run YSlow and thinks…<br />&lt;Print css tag for feature A&gt;<br />&lt;Print css tag for feature B&gt;<br />&lt;Print css tag for feature C&gt;<br />&lt;print HTML of feature A&gt;<br />&lt;print HTML of feature B&gt;<br />&lt;print HTML of feature C&gt;<br />…<br />“A & B & C are always used; let’s package them together!”<br />
    9. 9. Why we need adaptive packaging?<br />Day 2: Awesome! <br />&lt;Print css tag for feature A&B&C&gt;<br />&lt;print HTML of feature A&gt;<br />&lt;print HTML of feature B&gt;<br />&lt;print HTML of feature C&gt;<br />…<br />
    10. 10. Why we need adaptive packaging?<br />Day 3: feature C evolves…<br />&lt;Print css tag for feature A & B & C&gt;<br />&lt;print HTML of feature A&gt;<br />&lt;print HTML of feature B&gt;<br />If (users_signup_for_C()) { &lt;print HTML of feature C&gt;}<br />…<br />
    11. 11. Why we need adaptive packaging?<br />Day 3:<br />&lt;Print css tag for feature A & B & C&gt;<br />&lt;print HTML of feature A&gt;<br />&lt;print HTML of feature B&gt;<br />If (users_signup_for_C()) { &lt;print HTML of feature C&gt;}<br />…<br />A&B are always used, while C is not. ..<br />
    12. 12. Why we need adaptive packaging?<br />Day 4: feature C is deprecated<br />&lt;Print css tag for feature A & B & C&gt;<br />&lt;print HTML of feature A&gt;<br />&lt;print HTML of feature B&gt;<br />// no one uses C { &lt;print HTML of feature C&gt;}<br />…<br />
    13. 13. Why we need adaptive packaging?<br />Day 4: we start to send unused bits<br />&lt;Print css tag for feature A & B & C&gt;<br />&lt;print HTML of feature A&gt;<br />&lt;print HTML of feature B&gt;<br />// no one uses C { &lt;print HTML of feature C&gt;}<br />…<br />It is hard to remember we should remove C here.<br />
    14. 14. Why we need adaptive packaging?<br />One months later…<br />&lt;Print css tag for feature A & B & C & D & E & F & G…&gt;<br />if (F is used) &lt;print HTML of feature F&gt;<br />&lt;print HTML of feature G&gt;<br />if (F is not used) { &lt;print HTML of feature E&gt;}<br />…<br />Thousands of dead CSS rules in the package.<br />
    15. 15. Static Resource Management @ Facebook<br />Challenges:<br /><ul><li>Deep Integration
    16. 16. Viral Adoption
    17. 17. Agile Development </li></ul>Responses:<br /><ul><li>Separate requirement declaration and delivery of static resources
    18. 18. Requirement declaration: lives with HTML generation
    19. 19. Delivery: Globally optimized based on trace analysis</li></li></ul><li>Adaptive Packager: Internals<br />
    20. 20. Static Resource Management <br />Separate Declaration from actual Delivery<br /> Back to Day 1: <br />require_static(A_css); &lt;render HTML of feature A&gt;<br />require_static(B_css); &lt;render HTML of feature B&gt;<br />require_static(C_css);&lt;render HTML of feature C&gt;<br />&lt;deliver all required CSS&gt;<br />&lt;print all rendered HTML&gt;<br />Requirement Declaration lives with HTML <br />Global Optimization on Delivery<br />
    21. 21. Offline analysis<br />Packager: Global JS/CSS Optimization<br />Online process<br />require_static(A_css); &lt;render HTML of feature A&gt;<br />require_static(B_css); &lt;render HTML of feature B&gt;<br />require_static(C_css); &lt;render HTML of feature C&gt;<br />&lt;deliver all required CSS&gt;<br />&lt;print all rendered HTML&gt;<br />Usage Pattern logs<br />Packaging algorithm<br />“Optimal” packages<br />
    22. 22. Packager: models<br />Cost/Benefit tradeoff model:<br />To package two CSS/JS files A & B:<br />Cost: for page requests that only uses A, we waste the bytes of B (bandwidth)<br />Benefit: for page requests that uses both A and B: we save one round trip (latency )<br />Maximize “Profit” (Benefit – Cost)<br />Future: Users with different network connections have different packaging solutions<br />Usage Pattern logs<br />Packaging algorithm<br />“Optimal” packages<br />
    23. 23. Packager: models<br />Potential extensions (and trade-offs):<br />Consider all resources used in user browsing sessions, instead of user page loads<br />first page slower, subsequent pages faster<br />Consider cache probability: new files change more<br />New user slower, old users faster<br />Consider other costs:<br />CSS rules<br />JS executions<br />HTTP header overheads<br />Usage Pattern logs<br />Packaging algorithm<br />“Optimal” packages<br />
    24. 24. Packager: algorithm<br />A classic optimization problem:<br />Algorithms:<br />Greedy algorithm<br />Simulated Annealing<br />Clustering algorithms<br />Trade-off between offline computation cost and accuracy:<br />Greedy is good enough for us<br />Usage Pattern logs<br />Packaging algorithm<br />“Optimal” packages<br />
    25. 25. Adaptive Performance Optimization: more<br />Trace-based analysis for:<br /><ul><li>JS / CSS package optimization, image spriting
    26. 26. Progressive rendering for common JS/CSS/Images
    27. 27. Prioritization of resource delivery</li></li></ul><li>Adaptive Packager: Operations<br />
    28. 28. Packager: Deployment<br />Fully deployed since Nov 2008<br /><ul><li>Weekly based on previous week’s usage pattern (>100K unique usage patterns)
    29. 29. Javascript and CSS packaging only (image soon)
    30. 30. Efficiency monitors: size of wasted JS/CSS bytes; JS/CSS pkg numbers</li></li></ul><li>Packager: scalable with development<br />Nov 2008 =&gt; May 2009<br />
    31. 31. Packager: scalable with development<br />Nov 2008 =&gt; May 2009<br /><ul><li> 'js/careers/jobs.js’,
    32. 32. 'js/lib/ui/timeeditor.js’,
    33. 33. 'resume/js/resumepro.js’,
    34. 34. 'resume/js/resumesection.js’</li></li></ul><li>Packager: scalable with development<br />Nov 2008 =&gt; May 2009<br />
    35. 35. Packager: Experimental Image Spriting<br />The puzzle of image spriting:<br /><ul><li>Thousands of virtual gifts with static images, which to sprite?</li></li></ul><li>Packager: Experimental Image Spriting<br />The puzzle of image spriting:<br /><ul><li>The answer is…</li></li></ul><li>Packager: Experimental Image Spriting<br />Data set: ~3500 images in the code base at this time<br /><ul><li>comparing to <1500 js/css files </li></li></ul><li>Lesson learnt<br />
    36. 36. Human errors are unavoidable<br />Automatic analysis is preferable:<br />require_static(A_css); //forgot to remove the require_static<br />require_static(B_css); &lt;render HTML of feature B&gt;<br />require_static(C_css); &lt;render HTML of feature C&gt;<br />&lt;deliver all required CSS&gt;<br />&lt;print all rendered HTML&gt;<br />
    37. 37. Regression detection can be trickier<br />A measurement framework is necessary:<br />“The page has 10KB more Javascripts!”<br /><ul><li>Regression introduced by Packager? Or by developers? Or by feature adoption with new usage patterns?
    38. 38. Which feature introduces it?</li></li></ul><li>Summary<br />Performance optimization has to be adaptive<br />Good interfaces help a lot<br />This is an emerging area -- long way to go<br />
    39. 39. Thank you!<br />

    ×