Исполнение JS на сервере при масштабировании - что может пойти не так, Brian Geffon (LinkedIn)
Download as PPTX, PDF2 likes1,492 views
Brian Geffon discusses the evolution of JavaScript execution on servers from early frameworks like JSP to modern approaches using client-side templating and server-side rendering. He outlines key problems that arose like long loading times and SEO issues. Server-side rendering helped address these by allowing JavaScript execution on servers. However, this introduced new challenges around context pollution from shared JavaScript engines and garbage collection tuning. Overall techniques like request isolation, execution timeouts, and optimized garbage collection are needed to safely support server-side JavaScript rendering at scale.
Исполнение JS на сервере при масштабировании - что может пойти не так, Brian Geffon (LinkedIn)
- 1. JS Execution on the Server, What Could Go Wrong? Brian Geffon Software Engineer, LinkedIn
- 2. Hello! 2
- 3. Outline Introductions Brief History The paradigm shift Problems! Where we are today Closing thoughts and Questions 3
- 4. LinkedIn in 2003 4 JAVA JSP Data Center HTML Browser A single monolithic web application
- 5. LinkedIn in 2010 5 Grails GSP JAVA JSP Data Center HTML Browser Ruby ERB New frameworks: productivity boost.
- 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. 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. 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. Solution: client side templating, contd. Webapps can share UI! Ability to cache templates on the client – Better performance? 9
- 10. So many options! 10
- 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. Dust.js example gets compiled into a JavaScript function + =
- 13. Outline Introductions Brief History The paradigm shift Problems! Where we are today Closing thoughts and Questions 13
- 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. The paradigm shift: Fizzy 15
- 16. What’s going on here? 16 Web fz.js 1 2 Fizzy Server Profile 3 4 Contacts Profile
- 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. 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. What does the browser see?
- 20. Yay! A fancy new web architecture Components are now stand alone Nice UI separation Reusability 20
- 21. What could possibly go wrong? Large JSON payloads caused many problems with IE7 – IE7 doesn’t have a native JSON parser! 21
- 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. What could possibly go wrong? Search Engine Optimization – JS in GoogleBot Yes, many others: No 23
- 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. The Pieces of SSR High performance caching HTTP proxy High performance embeddable JavaScript Engine 25 Google V8 JS Engine
- 26. Server Side Rendering: What’s going on here? 26 Web fz.js SSR 1 2 Fizzy Server Profile 3 4 Contacts Profile
- 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. What does the browser see?
- 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. Outline Introductions Brief History The paradigm shift Problems Where we are today Closing thoughts and Questions 30
- 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. 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. Context Pollution Silly example but illustrates the need for isolation. 33 What if we leave off var in JavaScript?
- 34. Context Pollution: The solution Each request requires it’s own context – Completely reload the environment and bootstrap code Performance Hits? 34
- 35. What could possibly go wrong? Poorly written JavaScript can take forever to execute! 35
- 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. 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. Long Running JavaScript: The solution Execution limits (we use 1000ms) Exponentially decay the execution limit to prevent taking down the entire site! 38
- 39. What could possibly go wrong? Garbage Collection! 39
- 40. Garbage Collection! 40 Queue times going through the roof!
- 41. The culprit: Garbage Collection! 41
- 42. GC tuning: it takes practice. Avg Queue times < 0.3ms, P99.99 < 2ms. 42
- 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. 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. Questions?
Editor's Notes
- #5: This simple monolithic architecture should look familiar to most people
- #6: New frameworks provide a productivity boost, but at what cost? UI needs to remain consistent between pageviews Suppose you want to change your layout, your header and footer, because of the duplication of templates it requires a very coordinated rollout : many points of failure.\ Explain that this talk is where we are in 2014.
- #8: What possible options do you really have? C? C is exposable for almost any language via bindings, but is this really the approach you should take?
- #15: You start to approach an MVC architecture in that your views are now independent of your application logic.
- #16: Many applications can be divided into very small pieces. This creates a nice abstraction.
- #17: Obviously, now that you’re breaking your app up into smaller pieces you need to have an aggregation proxy sitting in front of each app. We called it Fizzy Server, Fizzy has no real significance we just picked that name while having a beer.
- #18: Explain the decision to use a script tag as the marker, it allows us to potentially do tricks on the client side if the proxy in the middle wasn’t present. Because this doesn’t have a body or a src attribute the browser basically ignores it; however, with special bootstrap client code you could even do client assembly -> This is a big deal
- #19: Remember these components may exist on the same webapp or another webapp, but since we’ve abstracted away the underlying webapp language we just return JSON. Note
- #20: Explain each of the pieces of assembly.
- #21: We have just taken our web application stack from a homogenous architecture to a heterogeneous, we now don’t care what technology application developers want to use. We were able to solve problem such as internationalization and localization (i18n) using client side templates and a separate translation component.
- #23: Internet Explorer 6 and 7 are possibly the biggest pieces of junk ever created.
- #30: DEMO?
- #34: While this example is silly, but let’s consider the case with a helper, dust allows helpers, so if your helper snippet contains a global.
- #37: If you do this you should be SHOT!
- #41: Explain this graph
- #42: Explain this graph
- #43: --max-old-space-size=256 --max-new-space-size=4096 Explain p99.99
- #44: --max-old-space-size=256 --max-new-space-size=4096
- #45: --max-old-space-size=256 --max-new-space-size=4096