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.

Исполнение JS на сервере при масштабировании - что может пойти не так, Brian Geffon (LinkedIn)

1,293 views

Published on

Доклад Брайана Геффона на HighLoad++ 2014.

Published in: Internet
  • Be the first to comment

Исполнение JS на сервере при масштабировании - что может пойти не так, Brian Geffon (LinkedIn)

  1. 1. JS Execution on the Server, What Could Go Wrong? Brian Geffon Software Engineer, LinkedIn
  2. 2. Hello! 2
  3. 3. Outline  Introductions  Brief History  The paradigm shift  Problems!  Where we are today  Closing thoughts and Questions 3
  4. 4. LinkedIn in 2003 4 JAVA JSP Data Center HTML Browser A single monolithic web application
  5. 5. LinkedIn in 2010 5 Grails GSP JAVA JSP Data Center HTML Browser Ruby ERB New frameworks: productivity boost.
  6. 6. New Frameworks: Added productivity Added complexity  Difficult to maintain numerous versions of the same template  Make it difficult to share content between apps 6
  7. 7. Solution: a single templating language  Do these web app frameworks share anything?  How can we ensure that we remain D.R.Y.  What language can be supported across each architecture? 7
  8. 8. Solution: client side templating  Web applications return JSON data  Templates are compiled to JavaScript  JSON Data is consumed by JavaScript templates which will execute on the client side. 8
  9. 9. Solution: client side templating, contd.  Webapps can share UI!  Ability to cache templates on the client – Better performance? 9
  10. 10. So many options! 10
  11. 11. The winner: Dust.js  Dust is a logicless JavaScript templating language  Dust is extensible  Dust is inherently D.R.Y. https://github.com/linkedin/dustjs 11
  12. 12. Dust.js example gets compiled into a JavaScript function + =
  13. 13. Outline  Introductions  Brief History  The paradigm shift  Problems!  Where we are today  Closing thoughts and Questions 13
  14. 14. The paradigm shift  Reusable UI gives rise to component sharing across apps  Components are now separated from data models  Ability to avoid RTT for components embedded in page. 14
  15. 15. The paradigm shift: Fizzy 15
  16. 16. What’s going on here? 16 Web fz.js 1 2 Fizzy Server Profile 3 4 Contacts Profile
  17. 17. What’s does the application return? 17 HTTP/1.1 200 OK Content-Type: text/html X-FS-Page-Parse: 1 X-FS-Page-Id: profile-view-fs X-FS-Host-Id: ela4-appxxxx.prod Web fz.js 1 2 Fizzy Server Profile 3 4 Contacts Profile
  18. 18. What do these embedded components return? HTTP/1.1 200 OK Content-Type: application/json X-FS-Page-Id: profile-activity X-FS-Web Host-Id: ela4-appxxxx.prod X-FS-TL: http://cdn-host/hash-of-template1.js X-FS-fz.Template-js Keys: __default__=hash-of-template1 1 2 Fizzy Server Profile 3 4 Contacts Profile
  19. 19. What does the browser see?
  20. 20. Yay! A fancy new web architecture  Components are now stand alone  Nice UI separation  Reusability 20
  21. 21. What could possibly go wrong?  Large JSON payloads caused many problems with IE7 – IE7 doesn’t have a native JSON parser! 21
  22. 22. What could possibly go wrong?  Some older browsers would take a very long time executing JS – Many browsers didn’t have optimized JS engines 22
  23. 23. What could possibly go wrong?  Search Engine Optimization – JS in GoogleBot Yes, many others: No 23
  24. 24. Server Side Rendering (SSR)  Unfortunately we need a way to execute JavaScript on the server  Could potential performance improvements been seen across the board? 24
  25. 25. The Pieces of SSR  High performance caching HTTP proxy  High performance embeddable JavaScript Engine 25 Google V8 JS Engine
  26. 26. Server Side Rendering: What’s going on here? 26 Web fz.js SSR 1 2 Fizzy Server Profile 3 4 Contacts Profile
  27. 27. What’s does the application return? 27 Web fz.js 1 2 Fizzy Server 3 4 Contacts Profile Profile SSR HTTP/1.1 200 OK Content-Type: text/html X-FS-Page-Parse: 1 X-FS-Page-Id: profile-view-fs X-FS-Host-Id: ela4-appxxxx.prod
  28. 28. What does the browser see?
  29. 29. Yay! A fancy new web architecture  We can now support old web browsers  We can now gracefully handle SEO  It turns out that even for modern browsers sometimes we can execute JavaScript faster! 29
  30. 30. Outline  Introductions  Brief History  The paradigm shift  Problems  Where we are today  Closing thoughts and Questions 30
  31. 31. What could possibly go wrong?  A shared JS engine gives rise to issues and vulnerabilities that don’t affect browsers that execute JS. 31
  32. 32. What could possibly go wrong?  Context Pollution – One malicious request can poison the context of another – This issue exists with any dynamic language 32
  33. 33. Context Pollution Silly example but illustrates the need for isolation. 33 What if we leave off var in JavaScript?
  34. 34. Context Pollution: The solution  Each request requires it’s own context – Completely reload the environment and bootstrap code  Performance Hits? 34
  35. 35. What could possibly go wrong?  Poorly written JavaScript can take forever to execute! 35
  36. 36. Poorly Written JavaScript: Infinite Loops, Recursion, etc. Although this is tail recursion and a silly example, It illustrates the need for stack protection and time limitations. 36
  37. 37. Long Running JavaScript: The solution  Enforce stack size limits that allow you to gracefully kill a VM  Sandbox: accept that apps will misbehave and allow them to only hurt themselves. 37
  38. 38. Long Running JavaScript: The solution  Execution limits (we use 1000ms)  Exponentially decay the execution limit to prevent taking down the entire site! 38
  39. 39. What could possibly go wrong?  Garbage Collection! 39
  40. 40. Garbage Collection! 40 Queue times going through the roof!
  41. 41. The culprit: Garbage Collection! 41
  42. 42. GC tuning: it takes practice. Avg Queue times < 0.3ms, P99.99 < 2ms. 42
  43. 43. GC Tuning  Adjust old generation to be several order of magnitudes less than new generation  New generation is critical because of the short lived jobs and contexts.  More Threads! 43
  44. 44. Ideas for the future  User load times are actually improved with SSR: do it 100% of the time.  A generic JS engine: allow apps to return any JavaScript, not just Dust.js 44
  45. 45. Questions?

×