Transcript Web Applications For The Cloud - CloudBrowser

Building Web Applications
For The Cloud
Godmar Back
9/14/2012
Dept of CS Colloquium
1
Do You Doodle?
9/14/2012
Dept of CS Colloquium
2
Today’s Web Technology Landscape
9/14/2012
Dept of CS Colloquium
3
Ok, Let’s Build That
•
•
•
•
•
•
Model View Controller - MVC
Mock up a View (in Jade) and test it.
Write your Model (in CoffeeScript)
Two supporting classes
A model singleton.
and unit test it.
Trygve M. H.
Reenskaug
(in 1979)
– Yes, professional developers do that.
• Use AngularJS to create a descriptive Controller
and wire the model to the view.
9/14/2012
Dept of CS Colloquium
4
Presenting: The Meeting Scheduler
• The brand-new Meeting Scheduler Application
9/14/2012
Dept of CS Colloquium
5
Are We Done Yet?
•
•
•
•
Wait…
Are we really running in the cloud?
No!
We’re running downloaded code in a
JavaScript sandbox on the machine in front of
us.
9/14/2012
Dept of CS Colloquium
6
Reality Sets In
Client
9/14/2012
Server
Dept of CS Colloquium
7
The Web Is A Distributed System
• Ok. Rethink.
• Data must be kept on the server. Somehow.
• Another technology pile:
– AJAX, CometD, JSON-P, REST, RPC
• Model
–
–
–
–
–
Another model? Model View View-Model?
Which parts should be kept on client? All? Some?
When to synchronize the client and server models?
Do I need a submit button?
What if the user refreshes or revisits the page?
• Looking for inspiration…
9/14/2012
Dept of CS Colloquium
8
Introducing CloudBrowser
Client
Server
cloudbrowser.cs.vt.edu
9/14/2012
Dept of CS Colloquium
9
CloudBrowser Architecture
Server-side JS
Environment (node.js)
Web Browser
Virtual Browser
Forwards Events
Client Engine
Web Socket
Connection
Listens
for
Events
Applies
Updates
Sends Updates
JS Web Application
CSS, Images
Server Engine
Dispatches
Events
Parses
HTML
Observes
Changes
Data
Bindings
DOM
DOM
Delivers
Events
JavaScript
Application
Code
JS
Libraries
(jQuery,
AngularJS)
node.js
Libraries
Other Tiers
Modifies DOM
JSDOM, Contextify
9/14/2012
Dept of CS Colloquium
10
Implementation
•
•
•
•
•
Implementation Platform
Processing Client Events
Synchronization Protocol
Detecting Virtual Browser Changes
JavaScript Execution
11
Implementation Platform
• Node.js
–
–
–
–
Built on Google ‘s V8 JavaScript Engine
One language client- and server-side
Automatic integration with virtual browser
Large library ecosystem, e.g. email Controller
• JSDOM
– Node.js W3C DOM implementation
• Socket.io
– 2-way socket connection between browser and server
12
Processing Client Events
• Block normal client-side event processing
– Register capturing event listeners on those events
• Call event.stopPropagation()
• Call event.preventDefault()
13
Synchronization Protocol
• We establish RPC endpoints on the client and
server.
Client Methods
PageLoaded(records)
DOMNodeInsertedIntoDocument(records)
DOMNodeRemovedFromDocument(records)
DOMAttrModified(target, name, value)
DOMPropertyModified(target, property, value)
DOMCharacterDataModified(target, value)
DOMStyleChanged(target, attribute, value)
AddEventListener(target, type)
PauseRendering()
ResumeRendering()
Server Methods
processEvent(event)
setAttribute(target, attribute,value)
14
Detecting Server-side DOM Updates
• Changes detected using aspect-oriented method
– Add wrapper methods (advice) around DOM
manipulation methods.
• Example:
var oldMethod = DOM.Node.appendChild;
DOM.Node.appendChild = function () {
var rv = oldMethod.apply(this, arguments);
browser.emit('DOMNodeInsertedIntoDocument', {
target: arguments[0],
parent: this
});
return rv;
};
15
JavaScript Execution
• Each virtual browser needs a faithful JavaScript
environment
– Must match existing browser environments
– Required to run existing client-side libraries
• Node.js didn’t expose an API to provide isolated
execution environments with the right semantics
– window === this?
• We wrote Contextify, a C++ addon for Node
– Adopted upstream by JSDOM
16
Evaluation Goals
• What is the latency cost of processing events
on the server?
• What’s the memory cost of instantiating
virtual browsers on the server?
• What’s the memory cost of adding additional
clients to a virtual browser (co-browsing)?
• How good is our DOM implementation?
17
Evaluation Setup
• Hardware:
– Server: 2- 2.5 GHz quad-core processors, 16 GB RAM
– Client: 3.00 GHz quad-core processor, 8 GB RAM
– Connected by gigabit LAN
• Can’t use traditional benchmarking means
– CloudBrowser isn’t stateless
– We want to simulate user interactions with a virtual
browser
18
Latency
• Response times (Nielson, Usability
Engineering)
– < 100ms: feels instantaneous
– < 1 second: noticeable, but doesn’t interrupt
workflow
• Keynote Internet Health report considers
latency < 90ms between backbones as “good”
• Ping from Blacksburg to Austin, TX:
– ~60 ms
19
Latency
20
Latency (Human User)
21
Virtual Browser Memory Usage
• Question: what’s the memory cost of a virtual
browser?
• Experimental procedure:
– Connect a client to a new virtual browser (cause
allocation)
– Force a garbage collection
– Collect V8 heap memory usage (Node.js API)
22
Virtual Browser Memory Usage
Application
Hello World
Chat Room
Meeting Scheduler
Memory Usage
164 KB
2.58 MB
4.45 MB
• Effect of JavaScript:
– jQuery: 1.05 MB
– Knockout.js: 0.33 MB
– Moment.js: 103 KB
• Effect of CSS:
– Bootstrap: 820 KB
23
Additional Client Memory Usage
• Question: what’s the memory cost of adding
clients to a single virtual browser?
• Experimental procedure:
– Connect a scripted client to the virtual browser
– Force a garbage collection
– Collect memory usage
• Result: ~16 KB per connected client
24
DOM Conformance
• jQuery Test
Suite
Results
Test Suite
Core
Callbacks
Deferred
Support
Data
Queue
Attributes
Events
Selector
Traversing
Manipulation
CSS
AJAX
Effects
Dimensions
Exports
Offset
Selector (jQuery)
Pass
1306
418
155
28
290
32
453
476
310
297
530
58
329
367
61
1
N/A
N/A
Total
1309
418
155
38
290
32
473
482
314
298
547
93
349
452
83
1
N/A
N/A
% Passed
99.77%
100.00%
100.00%
73.68%
100.00%
100.00%
95.77%
98.76%
98.73%
99.66%
96.89%
62.37%
94.27%
81.19%
73.49%
100.00%
25
Limitations (1)
• No access to computed layout
– Can’t support libraries that rely on client-side layout
information.
• element.offsetWidth, element.offsetTop, etc.
– CSS3 can eliminate this need for many use cases
– Can encapsulate client-side components
• Highly latency-sensitive applications (e.g. games)
– Not every application should be a CloudBrowser
application.
26
Limitations (2)
• DOM conformance
– Lacking support for browsing pages in the wild
(though remarkably good…)
– As JSDOM implementation improves, so does
CloudBrowser
• Multi-core scaling
– Node.js is event-based & single-threaded
– Need to distribute framework to multiple processes
– Initial implementation done, but requires
improvement
27
Scaling to Multiple Processes
pipe
Virtual
Browser
pipe
Virtual
Browser
pipe
Virtual
Browser
Client
Browser
Front-end Server
app1
Server
(multiprocess)
app2 Server
(single-process)
Virtual
Browser
Virtual
Browser
28
Related Work:
Contemporary AJAX Web Applications
• E.g., insert (client-library) + (server-framework) here
• Changing programs requires both client and server
programming.
• Model-View-Controller pattern is distributed.
– Distributed controller logic.
• Client-side state is transient
– Lost on page refresh and navigation
– Reconstructing client-side state is difficult
• No unique mapping of URLs to particular views
• Network programming manually handled by developer.
29
Related Work:
Existing Server-centric Frameworks
• ZK, ItsNat, Echo2, Vadiin, IceFaces
• Client-side state is still transient
– Components instantiated on each request
– Client state must be manually reconstructed
• Difficult to debug due to component
translation process
• Designers and developers must learn new
markup and programming languages
30
Future Work
•
•
•
•
•
CloudBrowser as a PaaS offering
Multi-process scaling improvements
Improved CloudBrowser API
Improved DOM conformance
Virtual browser management:
– Persistence
– Garbage collection
31
Conclusion
• CloudBrowser is a server centric web application
framework where applications run in virtual
browsers on the server
– Actual rendering takes place on the client
• User interface state is automatically preserved
across navigation, refresh, and disconnect
• CloudBrowser introduces acceptable latency and
memory overhead for many use cases
• The distributed nature of web applications is
hidden from developers
32
Acknowledgements
• Brian McDaniel, Virginia Tech, MS 2012
– Main implementer of CloudBrowser
• Open GRA Position Now
• Supported by CAREER: CCF-SHF Advanced
Execution Environments for Next-generation Cloud
Applications
• Brian McDaniel & Godmar Back, The
CloudBrowser Web Application Framework, to
appear at Systems, Programming, Languages and
Applications: Software for Humanity (SPLASH’12)
Wavefront, Oct 2012, Tucson AZ
9/14/2012
Dept of CS Colloquium
33