Building Web Applications For The Cloud Godmar Back 9/14/2012Dept of CS Colloquium1.
-
Upload
cori-octavia-robinson -
Category
Documents
-
view
216 -
download
0
Transcript of Building Web Applications For The Cloud Godmar Back 9/14/2012Dept of CS Colloquium1.
Dept of CS Colloquium 1
Building Web Applications For The Cloud
Godmar Back
9/14/2012
Dept of CS Colloquium 2
Do You Doodle?
9/14/2012
Dept of CS Colloquium 3
Today’s Web Technology Landscape
9/14/2012
Dept of CS Colloquium 4
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. – Yes, professional developers do that.
• Use AngularJS to create a descriptive Controller and wire the model to the view.
9/14/2012
Trygve M. H. Reenskaug(in 1979)
5
Presenting: The Meeting Scheduler
• The brand-new Meeting Scheduler Application
9/14/2012 Dept of CS Colloquium
Dept of CS Colloquium 6
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 7
Reality Sets In
Client Server
9/14/2012
Dept of CS Colloquium 8
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 9
Introducing CloudBrowser
Client Server
9/14/2012
cloudbrowser.cs.vt.edu
Dept of CS Colloquium 10
CloudBrowser Architecture
9/14/2012
Web Browser Server-side JS Environment (node.js)
JSDOM, Contextify
Virtual Browser
AppliesUpdates
Listens for Events
Forwards Events
Sends Updates
DOM
Web SocketConnection
Server Engine
JS Web Application
HTMLCSS, Images
JavaScriptApp-
lication Code
JSLibraries (jQuery,
AngularJS)
node.jsLibraries
Data Bindings
Other Tiers
Parses
DOM
Client Engine
DispatchesEvents
DeliversEvents
Modifies DOM
ObservesChanges
11
Implementation
• Implementation Platform• Processing Client Events• Synchronization Protocol• Detecting Virtual Browser Changes• JavaScript Execution
12
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
13
Processing Client Events
• Block normal client-side event processing– Register capturing event listeners on those events• Call event.stopPropagation()• Call event.preventDefault()
14
Synchronization Protocol
• We establish RPC endpoints on the client and server.
Client MethodsPageLoaded(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 MethodsprocessEvent(event)setAttribute(target, attribute,value)
15
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;};
16
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
17
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?
18
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
19
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
20
Latency
21
Latency (Human User)
22
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)
23
Virtual Browser Memory Usage
• Effect of JavaScript:– jQuery: 1.05 MB– Knockout.js: 0.33 MB– Moment.js: 103 KB
• Effect of CSS:– Bootstrap: 820 KB
Application Memory UsageHello World 164 KBChat Room 2.58 MBMeeting Scheduler 4.45 MB
24
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
25
DOM Conformance
• jQuery TestSuiteResults
Test Suite Pass Total % PassedCore 1306 1309 99.77%
Callbacks 418 418 100.00%Deferred 155 155 100.00%Support 28 38 73.68%
Data 290 290 100.00%Queue 32 32 100.00%
Attributes 453 473 95.77%Events 476 482 98.76%
Selector 310 314 98.73%Traversing 297 298 99.66%
Manipulation 530 547 96.89%CSS 58 93 62.37%
AJAX 329 349 94.27%Effects 367 452 81.19%
Dimensions 61 83 73.49%Exports 1 1 100.00%Offset N/A N/A
Selector (jQuery) N/A N/A
26
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.
27
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
28
Scaling to Multiple Processes
app2 Server(single-process)
ClientBrowser
Fron
t-end
Ser
ver
app1 Server
(multi-process)
Virtual Browser
Virtual Browser
Virtual Browser
pipe
Virtual Browser
Virtual Browserpipe
pipe
29
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.
30
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
31
Future Work
• CloudBrowser as a PaaS offering• Multi-process scaling improvements• Improved CloudBrowser API• Improved DOM conformance• Virtual browser management:– Persistence– Garbage collection
32
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
Dept of CS Colloquium 33
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