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

JS Execution on the
Server, What Could
Go Wrong?
Brian Geffon
Software Engineer, LinkedIn

Outline
 Introductions
 Brief History
 The paradigm shift
 Problems!
 Where we are today
 Closing thoughts and Questions
3

LinkedIn in 2003
4
JAVA
JSP
Data Center
HTML
Browser
A single monolithic web application

LinkedIn in 2010
5
Grails
GSP
JAVA
JSP
Data Center
HTML
Browser
Ruby
ERB
New frameworks: productivity boost.

New Frameworks: Added productivity
Added complexity
 Difficult to maintain numerous versions of the same
template
 Make it difficult to share content between apps
6

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

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

Solution: client side templating, contd.
 Webapps can share UI!
 Ability to cache templates on the client
– Better performance?
9

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

Dust.js example
gets compiled into a JavaScript function
+ =

Outline
 Introductions
 Brief History
 The paradigm shift
 Problems!
13

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

What’s going on here?
16
Web
fz.js
1 2
Fizzy Server Profile
3
4
Contacts Profile

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
3
4
Contacts Profile

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
3
4
Contacts Profile

Yay! A fancy new web architecture
 Components are now stand alone
 Nice UI separation
 Reusability
20

What could possibly go wrong?
 Large JSON payloads caused many problems with
IE7
– IE7 doesn’t have a native JSON parser!
21

 Some older browsers would take a very long time
executing JS
– Many browsers didn’t have optimized JS engines
22

 Search Engine Optimization
– JS in GoogleBot Yes, many others: No
23

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

The Pieces of SSR
 High performance caching HTTP proxy
 High performance embeddable JavaScript Engine
25
Google V8 JS Engine

Server Side Rendering: What’s going on here?
26
Web
fz.js
SSR
1 2
3
4
Contacts Profile

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

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

Outline
 Introductions
 Brief History
 The paradigm shift
 Problems
30

 A shared JS engine gives rise to issues and
vulnerabilities that don’t affect browsers that
execute JS.
31

 Context Pollution
– One malicious request can poison the context of another
– This issue exists with any dynamic language
32

Context Pollution
Silly example but illustrates the need for isolation.
33
What if we leave off var in JavaScript?

Context Pollution: The solution
 Each request requires it’s own context
– Completely reload the environment and bootstrap
code
 Performance Hits?
34

 Poorly written JavaScript can take forever to
execute!
35

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

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

Long Running JavaScript: The solution
 Execution limits (we use 1000ms)
 Exponentially decay the execution limit to prevent taking
down the entire site!
38

 Garbage Collection!
39

Garbage Collection!
40
Queue times going through the roof!

The culprit: Garbage Collection!
41

GC tuning: it takes practice.
Avg Queue times < 0.3ms, P99.99 < 2ms.
42

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

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

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

More Related Content

What's hot

Viewers also liked

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

More from Ontico

Recently uploaded

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

Editor's Notes