This document is downloaded from CityU Institutional Repository,

Run Run Shaw Library, City University of Hong Kong.

Title An approach to adaptive execution outsourcing in JavaScript

intensive web applications

Author(s) Li, Yick Sau Winson (李易修)

Citation

Li, Y. S. W. (2012). An approach to adaptive execution outsourcing in JavaScript intensive web applications (Outstanding Academic Papers by Students (OAPS)). Retrieved from City University of Hong Kong, CityU Institutional Repository.

Issue Date 2012

URL http://hdl.handle.net/2031/6752

Rights This work is protected by copyright. Reproduction or distribution of the work in any format is prohibited without written permission of the copyright owner. Access is unrestricted.

11CS013

An Approach to Adaptive Execution Outsourcing in JavaScript Intensive Web Applications

(Volume 1 of 1)

Student Name : LI, Yick Sau Winson

Student No. :

Programme Code : BScCS

Supervisor : Dr CHAN, Wing Kwong Ricky

1st Reader : Dr TAN, Chee Wei

2nd Reader : Dr YU, Yuen Tak

City University of Hong Kong Department of Computer Science

BSCCS Final Year Project Report 2011-2012

For Official Use Only

Student Final Year Project Declaration I have read the project guidelines and I understand the meaning of academic dishonesty, in particular plagiarism and collusion. I hereby declare that the work I submitted for my final year project, entitled:

An Approach to Adaptive Execution Outsourcing in JavaScript Intensive Web Applications does not involve academic dishonesty. I give permission for my final year project work to be electronically scanned and if found to involve academic dishonesty, I am aware of the consequences as stated in the Project Guidelines.

Student Name:

LI, Yick Sau Winson

Signature:

Student ID:

Date:

Abstract

With the advancement of HTML5 and the prevalence of internet enabled mobile devices, the

popularity of web applications is increasing. As web applications are becoming more complex,

the less powerful JavaScript engines on mobile devices have performance issues when loading

computationally intensive web applications. These mobile devices may also have power

constraints. Moreover, with the major web browsers each offering its own JavaScript engine,

where some are significantly slower than the others, the performance of JavaScript intensive web

applications may suffer even on personal computers.

As an attempt to bring the advantages of fast JavaScript engines and powerful computer

hardware to these constrained machines, this project proposes a framework for the adaptive

execution outsourcing of JavaScript web applications. This framework, named JSCloud, achieves

faster execution times on both mobile and desktop devices by migrating selected partitions of the

web application code to powerful cloud servers for execution.

In order to prepare a web application to suport JSCloud, the web developer only has to annotate

methods which are computationally expensive. JSCloud would then inject migration code into

the annotated methods. The result is a JSCloud enabled version of the given web application

code. This version of code has a cost estimation algorithm which would initiate the migration

when the algorithm deems that a reduction in execution time is gained when the execution of the

partition is performed on a high performance JavaScript engine in a cloud machine. JSCloud

aims to provide devices which have low JavaScript performances with better execution times via

execution outsourcing. Experiments have shown that the execution time could be brought down

by as much as 50% on devices with slower JavaScript engines.

Acknowledgments

I would like to express my gratitudes to Dr Ricky Chan for his guidance in completing this Final

Year Project. Dr Chan has given me useful advices since the conception of the project topic and

has provided valuable comments and suggestions on my work throughout the project.

My gratitude extends to Dr Belinda Ho for her lectures on report writing. She has taken the extra

effort of interviewing us individually to make sure we are all familiar with report writing.

Ms Dorophy Chu and Mr Bryon Ho deserve a special mention for kindly lending me their mobile

phones for testing.

Table of Contents

1. Introduction ................................................................................................................ 1

1.1. Background Information ...................................................................................... 1

1.2. Problem Definition ............................................................................................... 3

1.3. Aims and Objectives ............................................................................................ 5

1.4. Scope .................................................................................................................... 5

1.5. Deliverables .......................................................................................................... 6

1.6. Overview of the Report ........................................................................................ 6

2. Literature Review ....................................................................................................... 7

2.1. Web Application Overview .................................................................................. 7

2.2. Client-Server Communication .............................................................................. 9

2.3. Augmented Computation ...................................................................................... 10

2.4. Code Partitioning .................................................................................................. 10

2.5. Migration and Re-integration ............................................................................... 11

2.6. Migration Trigger ................................................................................................. 11

2.7. Comparing JSCloud with Existing Efforts ........................................................... 12

3. System Design ............................................................................................................ 13

3.1. System Overview ................................................................................................. 13

3.2. Use Case Modeling .............................................................................................. 15

3.3. Object Modeling ................................................................................................... 19

3.4. High-Level Object Interaction Modeling ............................................................. 20

4. Methodology and Implementation ............................................................................. 22

4.1. JavaScript Code Modifier .................................................................................... 22

4.1.1. HTTP Proxy ............................................................................................. 22

4.1.2. Code Analyzer .......................................................................................... 24

4.1.3. Code Modifier .......................................................................................... 26

4.2. Modified JavaScript File ...................................................................................... 26

4.2.1. Cost Estimator .......................................................................................... 27

4.2.2. Execution Migrator ................................................................................... 31

4.3. Cloud JavaScript Engine ...................................................................................... 32

4.3.1. Migration Endpoint ................................................................................... 33

4.3.2. Code Executor ........................................................................................... 33

5. Performance Evaluation ............................................................................................. 34

5.1. Overhead Evaluation ............................................................................................ 34

5.1.1. Preparation Overhead ............................................................................... 34

5.1.2. Execution Overhead .................................................................................. 36

5.2. Accuracy of Cost Estimator .................................................................................. 39

5.2.1. Accuracy of Estimations ........................................................................... 39

5.2.2. Accuracy of Decisions .............................................................................. 44

5.3. Performance Gain ................................................................................................. 46

6. Conclusion .................................................................................................................. 49

6.1. Achievements ....................................................................................................... 49

6.2. Critical Review ..................................................................................................... 49

6.3. Limitations ............................................................................................................ 50

6.4. Future Developments ............................................................................................ 51

References ............................................................................................................................ 52

Appendix .............................................................................................................................. 55

A. Monthly Log ........................................................................................................ 55

B. User Guide ........................................................................................................... 55

1. Introduction

1.1. Background Information

In recent years, web applications have gained popularity. Client side web applications are

applications executed on web browsers such as Internet Explorer [1] and Safari [2]. They can be

conveniently accessed over the internet, requiring no installation and are cross platform. The

only requirement is a standard compliant web browser.

Among the most prevalent web applications are social networking services and collective

intelligence services. Examples include Gmail [3], Facebook [4], Twitter [5] and Wikipedia [6].

These form one of the key characteristics of the current internet age. Another common type of

web applications are Software as a Service (SaaS) [7]. Also known as on-demand software, SaaS

is a model where software and user data are stored in a centralized location and are accessed

from web browsers. Google Documents is an example. In other words, desktop applications are

being moved onto the cloud. Web applications seem to have became increasingly powerful and

yet complex.

The availability of mobile devices have made web applications even more accessible. However,

due to the limited hardware performance and screen size, some web applications could be

impractical for use on mobile devices in terms of performance and interface usability. As such,

many mobile versions of web applications with optimized interfaces have been released (for

example the Facebook for Mobile webpage [8]). Native applications for specific mobile

platforms, which are commonly known as “apps”, are also developed to provide an optimized

functionality for mobile devices (such as Facebook for Mobile [9]). However, such optimizations

comes at the cost of reduced capabilities. Most mobile versions offer only a subset of features

provided by the standard counterpart (for example, the lab features of Gmail [10] are not

available on the Gmail mobile app).

1

Usability limitations due to small screen sizes could be mitigated by tablet devices which offer

bigger screens. Yet, the technical limitations due to processing power remains. The computation

of certain code could be taking too long on mobile devices.

Cloud servers have higher performance than mobile devices and personal computers (PC). It

would be possible to harness the computing power of cloud servers for computation tasks. This

project would explore the possibilities of offloading complex computations in the client

machines to cloud servers as an attempt to reduce processing time.

2

1.2. Problem Definition

To illustrate the problem, we use the example of a spreadsheet web application. A column of

integers modeled as array col of length col.length would be sorted. The computation time of

the following merge sort algorithm implemented in JavaScript to sort col would be measured.

The results are shown in Table 1.1.

function merge_sort(arr){

function split_array(arr){ if (arr.length <= 1) return arr;

var middle = parseInt(arr.length / 2); var left = arr.slice(0, middle); var right = arr.slice(middle, arr.length);

return merge(split_array(left), split_array(right)); }

function merge(left, right){ var result = []; while (left.length > 0 || right.length > 0){ if (left.length > 0 && right.length > 0){ if (left[0] <= right[0]){ result.push(left.shift()); } else { result.push(right.shift()); } } else if (left.length > 0){ result.push(left.shift()); } else if (right.length > 0){ result.push(right.shift()); } } return result; }

return split_array(arr);}

// timestamp t1 in millisecondsmerge_sort(col);// timestamp t2 in milliseconds

Figure 1.1 Algorithm of merge_sort

3

time taken to sort array of col.length (ms)10 100 1,000 10,000 100,000

(a)Laptop computer

MacBook Pro 2.2Ghz C2DChrome v.14

0 1 2 21 773

(b)Laptop computer

MacBook Pro 2.2Ghz C2DSafari v.5 (Default browser)

0 1 28 1531 -

(c)Laptop computer

Lenovo X200 2.26Ghz C2DIE 9 (Default browser)

0 0 5 135 6561

(d)Mobile phone

BlackBerry 9780Default browser

2 11 261 18827 -

(e)Portable Multimedia PlayeriPod Touch 1st GenerationSafari (Default browser)

7 22 420 26167 -

Table 1.1 Execution time of merge_sort() for different list sizes on different platforms.

Through this experiment we have identified the following problems concerning web application

response times.

Operations which are responsive on PCs can be slow on mobile devices. In the case of sorting

1,000 numbers, we observe from Table 1.1 that the computation time on mobile devices (d) and

(e) exceed 100 ms. At this level of delay, the user would notice a delay in the response [11, 12].

Performance of can be low with some browsers even on the same PC. Considering (a) and (b),

which are different browsers on the same system, we see that the merge_sort took 21 ms to

complete in Chrome while it exceeded 1000 ms with Safari.

.

Very large computations can lead to the script fail to complete on both mobiles devices and PCs.

When sorting 100,000 numbers, the script failed to complete in PC (b), mobile devices (d) and

(e). However in (a), it completes successfully within 773 ms. On desktop machines, the browser

issues a warning and prompts the user if he wants to terminate the script. On mobile devices, the

browser would become unresponsive and would require a force quit.

4

1.3. Aims and Objectives

This project aims to propose a solution to mitigate the limitations incurred on web applications

due to the limited processing powers of mobile devices. Taking inspiration from the CloneCloud

[13] project, this project would clone client side application code to cloud servers for

computation. Limitations of this model would be addressed followed by some discussion. For the

ease of illustration, the system to be developed is named JSCloud. JSCloud aims to provide

shortened execution time of web applications through migrated execution. JSCloud would

transparently and automatically modify the web application code to perform the necessary

migration procedure.

1.4. Scope

This project would focus on the client-side program of web applications implemented in

JavaScript. JavaScript [14] is a scripting language for computation and interaction with the

Document Object Model (DOM) of webpages. The reason for focusing on JavaScript is

primarily for its prevalence and support for cross platform compatibility. Each JavaScript

program runs on a JavaScript Virtual Machines (VM), which are also known as JavaScript

engines. They are built into standard compliant browsers and require no installation of additional

plugins. As a result, JavaScript web applications are compatible with all computers and mobile

devices which have standard compliant web browsers.

The logic for migration of JavaScript code partitions to the cloud server could be performed in

the JavaScript VM or in a module written as a JavaScript class. This project would implement

the cloning logic as a JavaScript module. The justification would be provided in the Section 3.

Some optimizations to JSCloud would be made to address a subset of problems. Considerations

like security issues would not be in the scope of this project. In short, this project provides a

working prototype of JSCloud only.

5

1.5. Deliverables

Apart from the delivery of the JSCloud module, supporting documents would be produced.

Deliverable Target Date

Project Plan 24-Oct-11

Interim Report 5-Feb-12

System Demonstration 10-Apr-12

Final Report 10-Apr-12

1.6. Overview of the Report

The rest of the report is divided into five sections. Section 2 would cover the Literature Review.

Section 3 is the documentation of the System Design. Section 4 describes the Methodology and

Implementation. Section 5 presents the Performance Evaluation. Section 6 is the Conclusion.

6

2. Literature Review

2.1. Web Application Overview

A typical web application consists of programs running on both the client C and server S. The

computation of a web application begins with a client-side application P being downloaded to

the web browser from a HyperText Transfer Protocol (HTTP) server. P provides the user

interface to the user. When resources in a web server is required by P, P sends a request to the

HTTP server that can reply the request with a response. Figure 2.1 shows the overview of a

typical web application.

Server Machine(s)Client Machine

Web Browser HTTP Server DB Server

DBClient-side App

Server-side App

User

Figure 2.1 Diagram illustrating the relation among user-client-server in a typical web

application.

The client-side application is transferred as HyperText Markup Language (HTML), Cascading

Style Sheets (CSS) and JavaScript (JS) files. Each HTML file describes some contents and

structure of the webpage. Each CSS file specifies and controls the presentation style of the

webpage. JavaScript is the language used in client side application programming. JavaScript

manipulates objects in the Document Object Model (DOM) [15] of a web browser. The DOM is

an interface defining the logical document structure and the methods to access and manipulate

documents. The DOM object tree contains HTML documents, CSS and JS source scripts. The

webpage (i.e. user interface) is a rendering of the DOM object tree by the web browser layout

engine. Thus, manipulating the DOM objects would manipulate the UI. JavaScript manipulates

and accesses the DOM objects through the DOM application programming interface (API).

Figure 2.2 shows the relation between the DOM, UI and JS.

7

Web Browser

Client-side App

DOM

User Interface

User

JS

Server-side App

Figure 2.2 Diagram illustrating relation between UI, DOM and JavaScript.

To further illustrate, the spreadsheet sorting web application used as example in Section 1.2

would have the structure shown in Figure 2.3. The addEventListener(), getElementById()

and setAttribute() methods invoked by JavaScript are provided by the DOM. The DOM

would listen for the left click event on the sort button on the webpage to invoke sortCol(). The

sorted column would then be displayed to the spreadsheet by updating each node of the

spreadsheet with the sorted array. Updates to the DOM tree (i.e. the Object Tree in Figure 2.3)

would automatically be rendered to the UI in accordance to the DOM standard.

DOM

button:sort

spreadsheet

...<input type="button" value="sort" id="btnSort"/>...<div id="spreadsheet">....</div>...

User Interface

HTML Code

Object Tree

document

input div

API

addEventListener() getElementById()

function sortCol(){ var sorted = merge_sort(col); displayResult(sorted, document.getElementById("spreadsheet"));}

function displayResult(arr, target){ for (var i in arr) target.setAttribute("cell " + i, arr[i]);}

// bind event listener to sort buttonvar evt = 0; // 0 denotes left clickdocument.getElementById("btnSort").addEventListener(evt, sortCol);

JavaScript

setAttribute()

id id cell 0 cell n...

btnSort spreadshet

Figure 2.3 Example of how JavaScript manipulates DOM Objects in a web application.

8

2.2. Client-Server Communication

Asynchronous JavaScript and XML (AJAX) [16] is one of the fundamentals of the modern web

applications. It is a development method that enables asynchronous requests between the server

and the client. The client can perform other operations while waiting for the responses from the

server. Despite the name XML, data transferred by AJAX could also be in JavaScript Object

Notion (JSON) [17], plaintext, or any data model. AJAX disassociates data request from HTML

page requests. With AJAX, full webpage reloads are not necessary for new data to be transferred.

Requests are made in the background and the user stays on the same page. Upon receiving the

reply from the server, a JavaScript callback function would be executed to show the information

to the user by manipulating the DOM which in turn causes the UI of the webpage to be re-

rendered. AJAX requests are made by the XMLHttpRequest method.

To convert JavaScript objects to JSON format, an external library json2.js [18] is used. The

library contains two methods. The stringify method serializes the object passed into it and

returns the object in JSON representation. The method simply casts the object passed into it to a

string to produce the JSON string. The parse method deserializes the JSON string passed into it

and returns the deserialized object. The parsing of the JSON string is performed in three stages.

First, all unicode characters are converted to escape sequences. Then, the JSON string is

validated by applying multiple regular expression matches. An error is thrown if the JSON string

is invalid. In the last stage, the objects serialized in the JSON string are recursively deserialized

by the JavaScript built-in eval method. The eval method executes the string passed into it as

JavaScript code (which is similar to the backtick ` operator in the bash shell). For example, eval

(“[‘foo’, ‘bar’]”) returns the array [‘foo’, ‘bar’].

9

2.3. Augmented Computation

Augmented computation refers to the execution of certain partitions of a program on a remote

machine. In the scope of this project, the purpose is to migrate the computation of complicated

code from resource-starved devices to more powerful machines in order to gain higher

performance.

Original Machine Remote Machine

VM VM

cloned

Figure 2.5 Illustration of augmented computation. Code partitions represented as circles.

A working prototype of augmented computation on mobile devices by migrating code to cloud

servers for high performance computation called CloneCloud [13] has been experimented by

Chun et. al, allowing up to 20 faster lower computation speed.

2.3.1. Code Partitioning

Augmented computation begins with code partitioning - to divide the code into partitions which

are suitable for migration and remote computation. This process can be carried out at various

levels. Chun et. al partitioned code at the VM level [13], while Gu et. al, Messer et. al and Ou et.

al partitioned at the Java class level [19, 20, 21]. Partitioning at different levels calls for different

considerations and techniques. In this section, we would review the principles for partitioning

CloneCloud used.

10

As code can be partitioned at any point in theory, practical implementation calls for specific

partition points. CloneCloud restricts partition points to method entry and exit points.

Additionally, partitions have to fulfill a set of properties to become legal. The first requirement is

the partition must be self contained. A partition which accesses native methods on the device

such as I/O devices would not be qualified as a legal partition and would not be migrated to a

cloud server. The second requirement is that the partition must not access native states of the

local machine. Partitions accessing native states below the application VM layer would not be

legal. The third property prohibits nested partitions. Migration and re-integration points must be

alternated. A thread which is migrated to the cloud server would be suspended on the client, and

could not be suspended again until the thread is re-integrated from the cloud server. By applying

the mentioned rules, a set of legal partition points can be obtained statically.

2.3.2. Migration and Re-integration

After partition points have been defined, the next step is to migrate the partitions to a remote

machine for computation. Migration involves the recreation of the necessary runtime

environment to execute the partition on the remote machine. For example, with VM level

partitions, we could suspend the VM on the original machine and resume the snapshot on a

remote machine [22]. With Java applications, the Java VM could be modified to ship objects to

remote machines as proxy objects. The execution thread is created on the remote machine [23].

When remote computation is finished, the thread is re-integrated to the original machine.

2.3.3. Migration Trigger

We now have partition principles and migration-and-re-integration strategies. The remaining is to

define a policy to where a given partition should be executed - remotely or locally. The condition

for partitions to be migrated is when the benefits of executing the thread remotely outweighs the

cost of partitioning, migration and transmission delays. The considerations could be computation

time, battery consumption and network status. CloneCloud obtains these metrics by a dynamic

profiler.

11

2.3.4. Comparing JSCloud with Existing Efforts

Existing efforts like CloneCloud offers augmented computation to specific platforms. In theory,

web browsers (which is an application itself) could benefit from existing solutions as long as the

platform is supported. When web applications could already benefit from existing solutions, how

is JSCloud justified?

The matrices in Figure 2.6 shows the applicability of augmented computation solutions for

different web applications (rows) on different platforms (columns). Existing solutions offers

solutions per-platform. As an example, CloneCloud requires manual annotations to API methods

for defining partition policies for each given platform [13]. Effort is needed to provide support

for each platform. For example, different Android phone vendors ship their customized version

of the Android OS and each version would require manual annotation.

Platform A Platform B Platform C Platform A Platform B Platform CWeb App A Web App AWeb App B Web App BWeb App C Web App C

Per-platform solution:Augmented computation supported on platform B

for all web applications.

Per-application solution:Augmented computation supported on all

platforms for web application b.

Figure 2.6 Matrices demonstrating the dimension of augmented computation support offered by

per-platform and per-application solutions.

Rather than requiring support to be rolled out to all target platforms, JSCloud aims provide a per-

application solution that supports augmented computation across all platforms. This is due to the

fact that JSCloud is actually implemented as standard-compliant JavaScript code which is

supported by all JavaScript standard compliant browsers. This allows developers to design web

applications with the assurance that augmented computation is available to all users.

12

3. System Design

The design of the proposed system JSCloud would be detailed in this chapter. JSCloud is a

module between the web client and web server that provides improved JavaScript performance

by means of code partitioning and migration.

3.1. System Overview

In an JavaScript web application, the program logic is delivered to the client as a JavaScript file

from the web server. In order to support execution migration, the JavaScript file has to be

modified to include the migration logic. This is performed by a module which automatically

inserts such logic into the original code. The modified JavaScript file would be executed on the

web browser, and when the migration logic is invoked, the code would be migrated to an

JavaScript engine on the cloud for execution. Figure 3.1 describes the relation between the three

modules: the JavaScript Code Modifier, the Modified JavaScript Code and the Cloud JavaScript

Engine.

JSCloud Web ServerWeb Browser

CloudJS Engine

JS Code ModifierJS' JS

request JS file request JS file

JS with migration logic

Original JS

JS Engine

migrates execution

integrates execution

JS'

Figure 3.1 System Overview of JSCloud

13

The JavaScript Code Modifier is an HTTP proxy which relays HTTP requests from and to the

web server. This would allow JSCloud to be offered as a transparent service. When a JavaScript

file is requested, the Cloud JavaScript Engine performs static analysis on the code to define legal

partitions. The migration logic would be appended to the original JavaScript file, producing a

Modified JavaScript File that is downloaded by the web browser.

The Modified JavaScript File is executed by the JavaScript engine of the web browser. The

code contains logic which migrates the execution of partitions to the Cloud JavaScript Engine

when the execution is estimated to be faster on the cloud. Such logic includes algorithms to

estimate execution cost and stub functions which abstracts the migration of code.

The Cloud JavaScript Engine receives and executes migrated code. It consists of an instance of

the Google V8 engine [24], which is one of the fastest open source JavaScript engines. The result

of execution would be returned to the migration code, where the execution is reintegrated to the

client JavaScript engine.

The work breakdown structure in Figure 3.2 fills the details of the three modules of JSCloud.

The implementation of the modules would be documented in Section 4.

Migration EndpointCost Estimator

Execution Migrator Code Executor

JSCloud

Code Modifier

HTTP Proxy

Code Analyzer

Javascript Code Modifier

Modified Javascript File

Cloud Javascript Engine

Figure 3.2 Work breakdown structure of JSCloud

14

3.2. Use Case Modeling

The use cases which JSCloud provide would be discussed in this section. The use case diagram

in Figure 3.3 models the functionality provided by the system and shows their relation with the

concerned actors.

Web browser

JSCLoud

Request File

Generate Modified JS

File Web app server

Migrate Execution

«extends»

Figure 3.3 Use case diagram of JSCloud

Request file is the action performed by the web browser to request a file from the web server. As

previously discussed, the JavaScript Code Modifier of the system is a HTTP proxy. When non-

JavaScript files are requested, the file is simply relayed from the web server to the web browser.

However, when a JavaScript file is requested, the JavaScript Code Modifier would append the

migration logic into the file and transmit the modified code to the web browser.

The web browser would execute the modified instance of the JavaScript file. When the cost

estimation logic in the modified code deems that a benefit is gained when code is executed

remotely on the cloud, it performs the migration of execution.

15

Use Case Description

UC1 - Request File - relays non-JavaScript file HTTP requests between web browser and web server

- for JavaScript file requests, JSCloud provides web browser with a modified JavaScript code that contains the logic for execution migration

UC2 - Migrate Execution - migrates execution of partitions from web browser to JSCloud

Table 3.2 Description of use cases

Table 3.2 gives an overview of the two use cases the system provide. UC1 describes the proxy

of the system which relays requests and modifies JavaScript files where appropriate. UC2

describes the migration of execution.

Table 3.3 and table 3.4 on the next page list the details of the two use cases, including the

primary actors involved, the stakeholders and interests, the preconditions, the success guarantees

and the scenarios.

16

UC1 - Request File

Primary actor - web browser

Stakeholders and interests - web browser want to obtain required resource from web server- web server want to provide requestor with resource- JSCloud want to provide web browser with modified code

Preconditions nil

Postcondition - web browser obtains required resource from web server

Main success scenarioActor action System response

1. web browser sends requests

2. JSCloud receives request

3. JSCloud sends request to web server

4. web server receives request

5. web server responds request

6. JSCloud receives response

7. JSCloud checks data type of resource

8. JSCloud sends response to web browser

9. web browser receives required resource

Extension - Request JavaScript File

7a. resource is a JavaScript file

7a.1. JSCloud defines legal partitions

7a.2. JSCloud appends cost estimation and migration code to JavaScript file

7a.3. continue at step 8

Table 3.3 Description of UC1 Request file

17

UC2 - Migrate Execution

Primary actor - web browser

Stakeholder and interest - web browser want to migrate execution of a partition for better execution time

Precondition - web browser is running the modified JavaScript code

Postcondition - the partition is correctly executed remotely and reintegrated

Non-functional requirement - the execution time is optimized

Main success scenarioActor action System response

1. Web browser executes JavaScript code

2. local engine estimates the cost for execution

3. local engine serializes the variables

4. local engine migrates the variables and partition to the cloud engine

5. cloud engine deserializes the variables and partitions

6. cloud engine executes the partition

7. cloud engine serializes result

8. cloud engine returns result to web browser

9. local engine receives result

10. local engine deserialize result and reintegrate execution

Extension - Execution not migrated

2a. cost for migrated execution is higher than local execution

2a.1 execute locally

Table 3.4 Description of UC2 Migration Execution

18

3.3. Object Modeling

In this section, we would perform an analysis of the object oriented model of the system. Figure

3.4 is the class diagram of the system. It corresponds to the components as listed in the work

breakdown structure in Figure in 3.2.

HTTPProxy

JavascriptCodeModifier

Code Analyzer

CodeModifier

CostEstimator

ExecutionMigrator

ModifiedJavascriptFile

CloudJavascriptEngine

MigrationEndpoint

Code Executor

11

1

1

1

1

*

1

1

1

1

1

1

1

1

1

1

1

<< creates >>

Figure 3.4 Class diagram of JSCloud

There are two relations that should be noted. CodeModifier is the creator of the

ModifiedJavaScriptFile, which is downloaded by the web browser. The ExecutionMigrator and

MigrationEndpoint reside in different systems, and therefore they communicate via message

exchanges. Table 3.5 on the next page lists the descriptions of the classes.

19

Class PurposeJavaScriptCodeModifier prepares Modified JavaScript CodeHTTPProxy relays HTTP requests between client and web serverCodeModifier appends cost estimation and migration logic to JavaScript codeCodeAnalyzer defines legal partitions in original JavaScript codeModifiedJavaScriptFile contains web application codeCostEstimator estimates the cost for migrated and local executionExecutionMigrator migrates execution to cloud engineCloudJavaScriptEngine performs migrated executionCodeExecutor executes migrated codeMigrationEndpoint accepts and replies migrated execution request

Table 3.4 Description of classes

3.4. High-Level Object Interaction Modeling

The high level object interaction of the classes mentioned in the previous section would be

documented in this section.

HTTPProxy CodeAnalyzer

CodeModifier

Web browser

1. request JS file

Web server

2. request JS file

3. return JS file

4. analyze JS file

5. Modify JS file

6. return modified JS file

Request Javascript File

Figure 3.5 Communication diagram of extension of UC1 - Request JavaScript File

20

The communication diagram in Figure 3.5 details the extension of Request JavaScript File of

UC1. In this use case, when the web browser requests the resource from the web server, it would

send the request to the HTTPProxy. The proxy then requests the resource from the web server

and then subsequently receives it. Upon receiving the JavaScript file, the CodeAnalyzer would

analyze the JavaScript file to define legal partitions and then the CodeModifier would append

cost estimation and code migration logic to it. This Modified JavaScript File would then be

returned to the web browser.

Migrate Execution

Web browser

CostEstimator

ExecutionMigrator

CodeExecutor

MigrationEndpoint

1. invokes code

3. migrates execution

5. reintegrate migration

2. initiates migration

4, executes partition

Figure 3.6 Communication diagram of UC2 - Migrate Execution

The communication diagram in Figure 3.6 shows the object interaction for UC2 Migrate

Execution. When the web browser invokes a predefined partition, it would first invoke the

CostEstimator, which estimates the time required to execute the partition locally and remotely. If

the CostEstimator decides that migrated execution is justified, it would initiate the migration

with the ExecutionMigrator. The ExecutionMigrator would transmit the serialized parameters

and the partition to the MigrationEndpoint via HTTP message exchange. The MigrationEndpoint

would invoke the CodeExecutor for the execution, and then it would reintegrate the results to the

ExecutionMigrator. The execution of the partition is then completed.

21

4. Methodology and Implementation

In this chapter, the methodology and implementation would be documented. This chapter is

divided into three sections, one for each of the three modules: the JavaScript Code Modifier; the

Modified JavaScript Code; and the Cloud JavaScript Engine.

4.1. JavaScript Code Modifier

The JavaScript Code Modifier is an HTTP proxy with added functionalities of analyzing and

modifying JavaScript files that it relays. It provides the web browser with a set of code that

would migrate execution to the Cloud JavaScript Engine adaptively. The components of the

JavaScript Code Modifier corresponds to the classes in Figure 3.5.

The JavaScript Code Modifier would be implemented in JavaScript and hosted on an node.js

[25] instance. Node.js is a platform built on the Google V8 JavaScript engine with libraries for

socket and I/O operations. It is highly suitable for running the JavaScript Code Modifier and the

Cloud JavaScript Engine on. In this case of implementing an HTTP proxy, node.js could stream

the bytes between web clients and web servers instead of treating each request as atomic events.

As such, files could be streamed in real time. This allows a lower latency in providing the web

browser with the resources. Node.js is further justified to be the platform of choice in the later

section explaining why it is suitable for running the Cloud JavaScript Engine on.

4.1.1. HTTP Proxy

JSCloud provides its service with the JavaScript Code Modifier which is an HTTP proxy. The

proxy could be located anywhere between the web browser and the web server. As such, JSCloud

could be located within the local area network (LAN), in the internet or in the server network as

illustrated in Figure 4.1. Each configuration has its associated benefits and drawbacks which is

tabulated in Table 4.1.

22

Local Network Internet Server Network

Local Network Internet Server Network

Local Network Internet Server Network

Web Server

Web Browser

JS Cloud

Web Server

Web Browser

JS Cloud

Web Server

Web Browser

JS Cloud

Figure 4.1 Locations where JSCloud could be located

JSCloud Location Benefits Drawbacks

Local area network - minimal latency- no proxy configuration required- JSCloud available to all users in

the LAN for all web applications

- not applicable to mobile networks

Internet - JSCloud available to all users for all web applications

- proxy configuration required- unoptimized latency

Server network - no proxy configuration required- JSCloud available to all users of

the web application

- unoptimized latency

Table 4.1 Benefits and drawbacks for JSCloud configurations in general cases

In the LAN setting, JSCloud is available to all users. Latency is minimized as JSCloud is located

in a local network as a forward proxy. JSCloud could also be offered as a public service on the

internet, in which users could use it by configuring their proxy settings. The JSCloud proxy

could also be a reverse proxy residing within the server network, making JSCloud available to all

users of the web application.

23

4.1.2. Code Analyzer

The Code Analyzer is responsible for defining legal partitions. Partitions are segments of code

that is between the entry and exit of a JavaScript function. There are two alternate schemes for

code partition. In the first scheme, all JavaScript functions are defined as partitions. If we apply

this scheme to the example in Figure 1.1, we would obtain three partitions: merge_sort,

split_array and merge. In the second scheme, only JavaScript functions that are annotated by

the web application developer are defined as partitions. Functions are annotated by adding a

comment //JSCLOUD MIGRATE before the function declaration. Both schemes were

implemented for testing but the first scheme faces performance issues (discussed in Section

5.1.2) and was excluded in the final version.

In the original design, partitions are defined according to the first scheme. The Code Analyzer

would then determine whether each partition is legal. The legality refers to the eligibility of

whether the partition could be migrated. Only legal partitions may potentially be migrated.

JSCloud defines legal partitions as self contained partitions that each does not require external

resources (e.g. global variables) and is not environment dependent (e.g. the window object). This

is performed by static analysis. However as the first scheme was abandoned due to performance

issues, the logic for checking the legality of partitions is demised. Under the second scheme, the

programmer would manually annotate the JavaScript functions where he should make sure the

function is self contained. Legality check is omitted to avoid the overhead. Although the legality

of each partition is not guaranteed, the Modified JavaScript Code and Cloud JavaScript Engine

would have two safeguards to ensure that any non-self contained partitions are appropriately

executed. The two safeguards would be discussed in Sections 4.2.2 and 4.3.2.

Static analysis is used to determine the entry point and exit point of the JavaScript functions. The

Original JavaScript File is searched for all occurrences of the //JSCLOUD MIGRATE annotation

and the indexes would be stored into an array. The brackets { and } would then be analyzed to

determine the entry point and exit point of the function.

24

Brackets { and } can exist in JavaScript code as part of comments or strings. These brackets are

not part of the syntax and should be ignored. An alternate version of the JavaScript code would

be constructed and stored in the string alternateJSFile where all comments and strings are

replaced by white spaces of equal length. Comments are identified by characters enclosed

between // and \n or /* and */. Strings are identified by characters enclosed by “ or ‘. In this

alternate version of the code, all brackets are part of the syntax. The entry point and exit point of

each annotated function could then be located by traversing the alternateJSFile string. Figure

4.2 shows the merge_sort algorithm with annotation. For illustration purposes the entry point

and exit points are denoted by ^ and $ respectively. The indexes of the entry points and exit

points are stored into two arrays and passed to the Code Modifier for insertion of migration code.

// JSCLOUD MIGRATEfunction merge_sort(arr){

function split_array(arr){ ^ ENTRY POINT if (arr.length <= 1) return arr;

var middle = parseInt(arr.length / 2); var left = arr.slice(0, middle); var right = arr.slice(middle, arr.length);

return merge(split_array(left), split_array(right)); }

function merge(left, right){ var result = []; while (left.length > 0 || right.length > 0){ if (left.length > 0 && right.length > 0){ if (left[0] <= right[0]){ result.push(left.shift()); } else { result.push(right.shift()); } } else if (left.length > 0){ result.push(left.shift()); } else if (right.length > 0){ result.push(right.shift()); } } return result; }

$ EXIT POINT return split_array(arr);}

Figure 4.2 Annotated version of the merge_sort code.

25

4.1.3. Code Modifier

The Code Modifier is responsible for inserting the code required for execution migration. The

code is stored in three templates which are loaded by the Code Modifier and inserted into the

appropriate locations of the Original JavaScript File to produce the Modified JavaScript File.

The jsHeader.js template contains the implementations of the Cost Estimator (Section 4.2.1),

Execution Migrator (Section 4.2.2) and the JSON serialization library (Section 2.2). This

template is prepended to the beginning of the Original JavaScript File.

The jsStubHeader.js template contains code that invokes the Cost Estimator and parameter type

checker (Section 4.2.1). The decision of whether to migrate a partition or to execute locally is

made here. This template is inserted in the entry point ^ of each partition.

The jsStubFooter.js template contains code that records the execution times. The execution times

are used by the Cost Estimator to calculate estimates (Section 4.2.1). This template is inserted in

the exit point $ of each partition.

After inserting the code from the three template files into the Original JavaScript File, the

Modified JavaScript File is produced and would be returned to the web browser by the HTTP

Proxy. This completes of the extension of UC1 Generate Modified JavaScript File.

4.2. Modified JavaScript File

The Modified JavaScript File is a version of the original JavaScript file provided by the web

server with migration logic added by the JavaScript Code Modifier. This section would

document the implementation of the Cost Estimator and Execution Migrator. These two

components are responsible for the initiation of migration.

26

4.2.1. Cost Estimator

The Cost Estimator is responsible for deciding whether to execute a partition locally or remotely.

The decision is made based on execution time. Execution time grows at different rates in

relationship to partition size on different platforms. This forms the basis of this project - to

migrate the execution when a remote execution has a shorter execution time.

local execution

remote execution + migration delay

partition size

exec

utio

n tim

e

Figure 4.3 Relationship between partition size and execution times

A partition is migrated when the time for migration plus the time for remote execution is shorter

than the time for local execution. The migration delay is the time required to transmit messages

between the web browser and the Cloud JavaScript Engine. If there is no migration overhead,

remote execution could be assumed to be always faster or as fast as local execution. In other

words, the migration overhead delay is the only cost of migration.

Assume d to be the migration overhead delay. d is not a constant value during the whole session.

This is especially true on mobile networks where a big fluctuation could be expected. The Cost

Estimator would estimate d based on recent migration overhead delays.

27

After estimating the migration overhead d, the Cost Estimator would decide if it is worthwhile to

pay the cost. Assume that the time for remote execution to be t, then the time for local execution

would be t + k, where k is the difference in the execution time; and the total time for migrated

execution would be t + d. We migrate the execution when the total time for migrated execution is

less than the total time for local execution. That is we migrate when t + d < t + k, which is d < k

(The intersection of the two curves in figure 4.2 is d = k). In other words, it is worthwhile to

migrate when d is smaller than than k.

The value of k would be estimated by the Cost Estimator based on the execution times of recent

local and remote executions. The Cost Estimator would maintain a record of k in relation to the

block size of the parameters (under the assumption that k is in direct proportion to the block size

of parameters). When a partition of parameter block size n is migrated to the cloud engine for

execution, the Cost Estimator would time the execution and the migration overhead. If we

subtract the overhead time from the execution time, we obtain the remote execution t for block

size n. When a partition of block size n is executed locally, the Cost Estimator would also time

the local execution time, which is t + k for parameter block size n. Having obtained sufficient

values of t in relation to n and t + k in relation to n. We could extrapolate the value of t and t + k

for a given n, which gives the value of k for a given n. The more data we have on local and

remote execution times, the more accurate the estimation of k would be.

The relation between k and n is maintained individually for each legal partition. This is essential

as the effect of block size to execution time is different for each partition. As an example,

consider two functions power(a,b) and add(a,b). The function power raises a to the power of b

while the function add sums a and b. Both functions take parameters of similar block size but the

rate of increase in execution time is very different. Therefore the performance metrics of k in

relation to n should be kept individually for each partition.

28

As k is the execution time, it is independent of network transmission delays. For each invoked

partition of parameter block size n, the Cost Estimator would estimate the value of k and the

migration overhead d. When d < k, the partition would be migrated to the cloud engine by the

Execution Migrator.

When the web application is just loaded, the Cost Estimator would not have sufficient samples to

estimate the local execution time t + k, remote execution time t and migration overhead d. The

flowchart in Figure 4.4 depicts the process which the Cost Estimator makes migration decisions.

BeginSufficient data for

local execution time estimation?

estimate local execution time

Sufficient data for remote execution time estimation?

estimate local execution time

d < k ?estimate migration overhead

estimated local execution time >

100ms?

migrate execution

execute locally End

yes

no

no

no

no

yes

yes

yes

Figure 4.4 Flowchart depicting the decision making process of the Cost Estimator

The Cost Estimator would first check if there is sufficient samples to estimate the local execution

time. When the web application is just loaded, no partitions are executed and therefore we do not

have any samples of local execution times t + k. The Cost Estimator would therefore make the

decision to execute the partition locally. When there are more than two samples of t + k of block

29

sizes x and y where x ! y, the Cost Estimator would attempt to estimate the tn + kn for the given

block size n. The estimation elocal for block size n is performed by linear interpolation if x " n " y

or otherwise by linear extrapolation. For linear interpolation, the samples of which x and y are

closest to n is chosen for the interpolation. For linear extrapolation, the two samples x and y of

smallest or largest block sizes are accordingly chosen for the extrapolation. If elocal(n) < 0, then

the Cost Estimator would treat the situation as having insufficient samples for estimation and

would decide to execute the partition locally. elocal(n) < 0 when the slope m of the line connecting

(x, tx + kx) and (y, ty + ky) is sufficiently big or when the slope m is negative. Both cases signify

that the estimation is inaccurate and therefore the Cost Estimator would decide to execute

locally. This decision for local execution would also provide an additional set of local execution

time tn + kn to refine future estimations.

Using the same estimation algorithm as elocal, the Cost Estimator would attempt to estimate the

remote execution time tn for given block size n. If there are insufficient samples for the

estimation, the Cost Estimator would proceed to check if elocal(n) > 100ms. This threshold is set

arbitrarily. The partition is migrated when elocal(n) > 100ms. Otherwise it is executed locally.

If the Cost Estimator has sufficient data to estimate tn then it follows that there are sufficient data

to estimate dn as t and d are obtained together in the measurement of migrated execution times

(i.e. number of samples for t = number of samples for d). The Cost Estimator would then proceed

to estimate tn and dn. kn is then calculated (elocal(n) - eremote(n) = tn + kn - tn = kn). If dn < kn then the

partition is migrated. Otherwise it is executed locally.

The estimation of the overhead dn for block size n is based on 100 recent overhead timing

samples (or as much as available if there is less than 100 samples). Assume that s samples are

available where s < 100. We first calculate the weighted average r of dx / x (i.e. overhead time per

block size) where x = 1, 2, ... s. The weight for dx / x is calculated as timestampx - timetsamp1

where timestampx is the time when the sample for dx is obtained (i.e. more recent samples have

higher weight). We then multiply r by n to obtain dn.

30

4.2.2. Execution Migrator

The Execution Migrator is responsible for the migration of partitions to the cloud engine. The

code for Execution Migrator is inserted into the Modified JavaScript File by the Code Modifier

(Section 4.1.3). The Execution Migrator provides two methods: migrate that migrates the

partition to the Cloud JavaScript Engine; and checkArgumentsType that checks the data type of

the arguments (this is the first safeguard against the migration of non-self-contained partitions as

mentioned in 4.1.2).

The pseudocode for the migrate method is shown in Figure 4.5. The migrate method accepts

the args parameter which is a JavaScript arguments object. JavaScript parameters passed into any

function is contained in the arguments object and can be accessed within the scope of the

function body. The migrate method would first serialize the arguments and the function which is

accessed by args.callee into JavaScript Object Notation (JSON) with the external library

mentioned in Section 2.2. An XML-HTTP request would be sent to the cloud engine url for the

migration of arguments a and method m. The async=false statement denotes that the call is

asynchronous. This is performed as the thread should be blocked while awaiting the result from

the cloud engine. This, however, should not be a concern as the migrated execution should be

quicker than executing the partition locally, which would also hold the thread anyhow. If an

asynchronous call is to be used, the whole web application code would have to be redesigned

with substantial changes to cater for the callbacks, which is out of the hands of the current

version of our JavaScript Code Modifier.

ExecutionMigrator.migrate = function(args){ var a = serialize(args) var m = serialize(args.callee)

var result = ajaxCall(‘async=false’, endpointURL, a, m);

return deserialize(result);}

Figure 4.5 Pseudocode of the migrate method

31

The pseudocode for checkArgumentsType is shown in Figure 4.6. The method accepts the

arguments object args as the parameter and returns a boolean value. The args object is first

casted into an array a. Then the elements in a are iteratively checked. If an element in a is found

to be a non-number, non-boolean, non-String, non-array or is undefined, the method returns false

and the partition would not be migrated. checkArgumentsType returns true when all parameters

used by the partition are primitive data types and. the partition is eligible for migration.

ExecutionMigrator.checkArgumentsType = function(args){ var a = args.toArray() for (i in a){ if (typeof(a[i]) != 'number' && typeof(a[i]) != 'string' && typeof(a[i]) != 'boolean' && typeof(a[i]) != 'undefined' && !(a[i] instanceof Array)){ return false; } }

return true;}

Figure 4.6 Pseudocode of the checkArgumentsType method

4.3. Cloud JavaScript Engine

The Cloud JavaScript Engine (refer to Figure 3.2) is the module which accepts execution

migration requests from the Modified JavaScript Engine. It is a stateless system which processes

the requests individually. The Cloud JavaScript Engine is implemented in JavaScript on the

node.js platform. (Node.js was briefly introduced in Section 4.1). Node.js is suitable for a couple

of reasons. Firstly, as node.js is written in JavaScript, it would readily parse the migration

requests which are serialized in the JSON format. Secondly, Node.js is designed to handle a large

number of simultaneous connections. while providing a high requests/second throughput [26].

Thirdly, the migrated executions could be executed directly on node.js, taking advantage of its

V8 JavaScript engine which has high performance as demonstrated in the benchmarks in table

1.1. The Cloud JavaScript engines contains two parts: the Migration Endpoint and the Code

Executor.

32

4.3.1. Migration Endpoint

The Migration Endpoint is the listener for requests. Upon receiving migration requests from the

web browser, it would deserialize the parameters and submit the execution to the Code Executor.

When the Code Executor finishes execution, it would serialize the result and return it to the web

browser.

4.3.2. Code Executor

The Code Executor accepts migrated partitions and executes them. As the required parameters

and method are already prepared by the Migration Endpoint, the Code Executor would simply

invoke the method with the parameters and return the result to the Migration Endpoint. If the

execution of the migrated partition causes a runtime error, it would throw an

MigratedExecutionFailed exception to the Execution Migrator of the Modified JavaScript Code.

The Execution Migrator would then prohibit the partition from being migrated again and resume

to re-execute the partition locally. This is the second safeguard mentioned in Section 4.1.2.

UC2 Migrate Execution is completed when the Migration Endpoint returns the result to the

Execution Migrator and the execution is reintegrated to the local runtime.

33

5. Performance Evaluation

The performance of JSCloud would be evaluated in this section. This section covers three aspects

of performance: the overhead introduced by JSCloud; the accuracy of the Cost Estimator; and the

overall performance gained by JSCloud.

5.1. Overhead Evaluation

There are two types of overheads in JSCloud. The preparation overhead is the overhead for

preparing the Modified JavaScript File by the JavaScript Code Modifier (UC1). The execution

overhead is the overhead for executing partitions in the Modified JavaScript File (UC2).

5.1.1. Preparation Overhead

The HTTP Proxy of JSCloud is the first source of preparation overhead. Requested files are

relayed through the proxy and a latency would be introduced. Moreover, additional overhead is

incurred when a JavaScript file is requested as the JavaScript file would be downloaded and

uploaded instead of streamed through the proxy. This overhead is highly variable as it is

dependent on the network condition of the user and the location of where JSCloud is located (as

depicted in Figure 4.1).

The second source of preparation overhead is the time used for static analysis and code

modification in the Code Modifier. The average processing time for each partition to be defined

and included with migration logic is 0.35ms. The number is derived from a series of samples as

shown in Table 5.1.

number of partitions 130 50 12 8 110processing time (ms) 64 10 4 2 53

Table 5.1 Samples of time spent processing a JavaScript file of a number of partitions

34

Furthermore, the Modified JavaScript File would have a larger file size than the Original

JavaScript File due to the additional code (Section 4.1.3). This larger file size is the third source

of preparation overhead as the downloading time would be increased. The size of the additional

code is tabulated in Table 5.2.

code size (bytes) minified code size (bytes)file header 35150 9119stub footer 3913 1906stub footer 660 536

Table 5.2 Additional code size of each part of the Modified JavaScript File

The file header is added to each Modified JavaScript File. The stub header and stub footer is

added to each partition of the file. The code size could be reduced by minification, which is the

process of removing unnecessary white spaces, newlines and comments in the JavaScript code.

To analyze the overall overhead in the preparation of the Modified JavaScript File, an experiment

was performed to obtain the actual overhead measurements when JSCloud is used as a reverse

proxy (refer to Figure 4.1). The time required to obtain JavaScript files of 1, 10, and 100

partitions from a web server with and without JSCloud were recorded. By computing the

difference between the time used for obtaining the file with JSCloud and the time without

JSCloud, the overhead is obtained. Table 5.3 shows the overhead data.

number of partitions without JSCloud (ms) with JSCloud (ms) overhead (ms)1 43 73 3010 50 138 88100 309 805 496

Table 5.3 Time required to complete request for JS file of different number of partitions

The time required to complete the file request is approximately doubled when JSCloud is used.

While this overhead is not insignificant, in actual usage the delay is acceptable in terms of

webpage load times. To put the figures into perspective, the homepage of Google took 1150ms to

load (including all images and scripts) on the same experiment setup.

35

5.1.2. Execution Overhead

This section would analyze the two types of execution overheads: the execution overhead in

executing a partition locally; and the migration overhead when a partition is executed remotely.

In each partition of the Modified JavaScript File are the additional logic inserted by the Code

Modifier (Section 4.1.3). These logic are used to determine whether the execution of a partition

should be migrated and to record timing data. It is executed regardless of whether the partition

was migrated and is the only source of execution overhead in the local execution of a partition.

To analyze the overhead of executing a partition locally, the execution times for sorting an array

of different sizes using the merge_sort algorithm in Section 1.2 were measured in two runs. The

first run is executed with the Original JavaScript File to obtain the baseline measurements. The

second run is executed with a special version of Modified JavaScript File which forces all

executions to not migrate, thus obtaining the local execution time + the overhead. By subtracting

the time of the second run by the first run, the overhead could be obtained. The results are shown

in Table 5.4.

array size original JS code (ms) modified JS code (ms) overhead (ms)10 0 14 14100 1 49 48

1,000 24 1975 195110,000 1627 - -

Table 5.4 Time required to sort arrays of different sizes with Original and Modified JS codes

The results show that the overhead in the execution of partitions in the Modified JavaScript File

is very high. The sorting of 10,000 elements in the Modified JavaScript File resulted in a browser

timeout. The overhead caused the local executions of partitions to be too slow.

36

The reason for the significant overhead was investigated. As we have discussed in Section 4.1.2,

there are two schemes for the Code Analyzer. The first scheme would automatically define all

methods as legal partitions. The second scheme would define partitions as per the annotations in

the JavaScript file. The figures in this experiment were obtained using the first design. All

methods in the Modified JavaScript File were defined as legal partitions. Consequently, when the

merge sort method was invoked recursively, the Cost Estimator was also invoked in each

recursion for a large number of times. This caused the long execution times in the Modified

JavaScript Code. The first scheme is therefore abandoned.

The same experiment was performed with the second design of the Code Analyzer where only

annotated methods would be defined as legal partitions. Only the method that invokes the

merge_sort method was annotated for migration (as in Figure 4.2). As with the previous

experiment, the Modified JavaScript File is a special version where execution is forced to be

performed locally. The results are tabulated in Table 5.5.

array size original JS code (ms) modified JS code (ms) overhead (ms)10 0 1 1100 1 1 0

1,000 24 24 010,000 1627 1632 5

Table 5.5 Time required to sort arrays of different sizes with Original and Modified JS codes

where Code Analyzer defines only annotated methods as legal partitions.

The figures show that the overhead is negligible when the Code Analyzer defines only annotated

methods as partitions. This is due to the fact that the Cost Estimator was invoked for one time

only as the annotated method was executed once only.

The two experiments shows that in the local execution of a partition, the automated partitioning

of all methods by the Code Analyzer would result in the local execution time being much longer

than the Original JavaScript Code. JSCloud is only practical when the Code Analyzer partitions

as per the annotations in the JavaScript file.

37

The migration overhead would then be discussed. This overhead includes the serialization of the

request; the deserialization of the request; the serialization of the reply; the deserialization of the

reply; and network transmission. In other words, the overhead is t1 + t2 + t3 + t5 + t6 + t7 in Figure

5.1.

Web Browser JSCloud

serialization transmission deserialization

deserialization transmission serialization

execution

t1 t2 t3

t4

t7 t6 t5

Figure 5.1 Lifecycle of a migrated execution

Experiments were carried out to measure the overhead. The partition entry and exit times were

recorded to calculate the time used to execute the partition (i.e. t1 + t2 + t3 + t4 + t5 + t6 + t7). The

time taken for the remote execution is also measured (i.e. t4). By subtracting the two

measurements, we obtain the overhead t1 + t2 + t3 + t5 + t6 + t7. Tables 5.6 and 5.7 list the

migration overhead measured from a notebook computer and mobile phone respectively.

JSCloud was configured as a reverse proxy.

array size 1994 2683 3543 4012 5261 6674 7590 8105migration overhead (ms) 215 141 934 261 218 377 251 275

Table 5.6 Migration overhead measured from a MacBook Pro for sorting arrays of different sizes

by accessing JSCloud over the internet on a cable modem connection

array size 1213 2302 2575 3095 3365 3978 4615 4904migration overhead (ms) 838 1219 1295 1541 1431 1741 1898 1932

Table 5.7 Migration overhead measured from a BlackBerry 9780 for sorting arrays of different

sizes by accessing JSCloud over the internet on a 3G connection

38

The figures in Table 5.6 and 5.7 show that the migration overhead is generally in proportion to

the array size. However, as transmission delay fluctuates, there are cases where a larger array had

a shorter migration overhead, such as in Table 5.6 where the sorting of 3543 elements required

and overhead of 934ms whereas the sorting of 4012 elements required an overhead of only

261ms.

The migration overhead is large when the array size is large and the network is not stable. As

discussed in Section 4.2.1, the migration overhead is used to determine whether a partition

should be migrated.

5.2. Accuracy of Cost Estimator

The Cost Estimator is responsible for making decisions on whether a partition should be

migrated or not based on the history of execution times and migration overheads in the session.

As such, the accuracy of Cost Estimator determines the efficiency of JSCloud. Two aspects

would be analyzed in this section: the accuracy of the estimations; and the accuracy of the

decisions.

5.2.1. Accuracy of Estimations

The Cost Estimator would calculate the estimated local execution time (inclusive of the local

execution overhead discussed in Section 5.1.2), estimated remote execution time (t4 in Figure

5.1) and the estimated migration overhead (t1 + t2 + t3 + t4 + t5 + t6 + t7 in Figure 5.1). The

estimation is based on historical data, and therefore the estimation should be progressively more

accurate as more samples are recorded.

To measure the accuracy, 50 arrays of random length from 1 to 5000 containing random numbers

were sorted with the merge sort algorithm in Section 1.2 and the execution times were recorded.

39

The experiment was performed on a BlackBerry 9780 connected to the Internet on a 3G

connection. JSCloud is configured as a reverse proxy (refer to Section 4.1.1). Three trial runs

were taken and the data is tabulated in Tables 5.9, 5.10 and 5.11 (starting on the next page). A

control sample was obtained by running the experiment with the Original JavaScript File to

obtain the baseline local execution times. This control data is recorded in the baseline column.

The blank cells in the estimated data columns denotes that an estimation was not possible due to

insufficient samples (see Section 4.3.1). A partition is either executed locally or migrated,

therefore in each row only the actual local time or the actual migrated time + actual overhead

could be recorded. The shaded rows are excessive migrations and would be discussed in Section

5.2.2.

Table 5.8 tabulates the mean, median and standard deviation of the percentage error of the

estimations in the three trials.

local time estimation percentage error

remote time estimation percentage error

overhead estimation percentage error

mean 7.73% 4.99% 3.51%median 2.01% 5.40% 2.30%

standard deviation 25.09% 32.44% 27.57%

Table 5.8 Mean, median and standard deviations of the percentage errors of the estimations

As the Cost Estimator makes the decision of whether to migrate based on the estimated data,

inaccurate estimations would affect the accuracy of the decision. Section 5.2.2 would look into

accuracy of the migration decision.

40

estimated (ms) actual (ms) baseline (ms)

percentage error

item array size local remote overhead local remote overhead local local remote overhead1 1228 394 3882 3112 2100 21723 377 64 674 3085 2082.11 8 2312 1997 4.26%5 1213 386.5 4 838 372 3.90%6 2957 1963.66 7.72 1575.46 8 1363 1839 6.78% -3.47% 15.59%7 2393 1448.66 6.7 1205.72 6 1177 1882 -23.03% 11.70% 2.44%8 1362 514.15 4.26 803.71 456 918 -43.99%9 3570 2540.5 8 1636.16 9 1585 2937 -13.50% -11.11% 3.23%10 3365 2343.99 8.57 1535.36 8 1431 2336 0.34% 7.15% 7.29%11 2416 1447.48 6.09 1152.98 6 1238 1268 14.15% 1.42% -6.87%12 3794 2745.96 10.05 1688.16 10 1584 2983 -7.95% 0.46% 6.58%13 4770 3670.77 14.5 2017.43 20 1851 4523 -18.84% -27.49% 8.99%14 1229 393.47 4.03 713.72 385 387 1.67%15 433 85.47 2.69 431.01 151 69 23.87%16 2302 1340.04 5.85 1095.74 7 1219 1163 15.22% -16.46% -10.11%17 221 29 2618 4343 3256.01 15.52 1865 11 1721 3882 -16.13% 41.05% 8.37%19 2537 1568.04 6.47 1189.22 8 1311 1386 13.13% -19.10% -9.29%20 3978 2925.52 10.35 1739.34 9 1741 3214 -8.98% 15.02% -0.10%21 4838 3726.89 21.22 2051.7 15 1882 4629 -19.49% 41.45% 9.02%22 1689 761.55 5.31 886.08 665 671 13.50%23 1823 799.57 5.68 934.06 847 759 5.35%24 1527 561.98 4.87 828.51 558 560 0.35%25 2098 1116.4 6.44 1033.74 7 979 14.03% -8.02%26 1857 885.49 6.2 1020.46 789 791 11.95%27 4904 3979.22 9.8 2197.25 14 1932 4750 -16.23% -30% 13.73%28 1375 464.95 4.56 814.42 466 465 -0.01%29 4173 3219.16 10.08 1873.19 8 1855 3508 -8.23% 25.97% 0.98%30 4615 3682.36 16.71 2043.17 11 1898 4226 -12.86% 51.89% 7.65%31 3095 2087.7 8 1449.28 7 1541 2005 4.12% 14.29% -5.95%32 1566 583.9 5.2 887.13 581 581 0.50%33 1921 857.29 6.42 1023.25 920 840 2.06%34 1412 489 4.69 829.79 487 487 0.41%35 4851 3832.75 14.84 2130.55 11 2337 4654 -17.65% 34.87% -8.83%36 2890 1882.79 8 1421.24 7 1408 1759 7.04% 14.29% 0.94%37 1106 349.5 3.65 729.56 319 318 9.91%38 2466 1465.98 6.89 1257.97 10 1372 1316 11.40% -31.09% -8.31%39 616 196.42 1.99 549.46 122 123 59.69%40 743 172.94 2.42 599.59 168 178 -2.85%41 2299 1294.82 7 1214 6 1229 1159 11.72% 16.67% -1.22%42 3201 2190.4 7.38 1575.15 7 1544 2133 2.69% 5.40% 2.02%43 39 7 344 1699 684.71 5.66 977.72 673 671 2.04%45 2575 1568.92 7.91 1322.94 6 1295 1426 10.02% 31.78% 2.16%46 3326 2316.87 7.75 1621.63 7 2870 2289 1.22% 10.76% -43.50%47 2222 1220.16 6.37 1372.05 1088 1084 12.56%48 460 147.02 1.46 564.67 158 75 96.03%49 1096 314.07 3.61 855.66 315 319 -1.54%50 1886 846.8 6.29 1217.78 814 806 5.06%

Table 5.9 Actual and estimated execution times and overheads recorded when sorting a 50

number array on a BlackBerry 9780 on a 3G connection to the internet. First trial.

41

estimated (ms) actual (ms) baseline (ms)

percentage error

item array size local remote overhead local remote overhead local local remote overhead1 1228 389 3882 3112 2036 21723 377 62 674 3085 2013.98 8 5161 1997 0.85%5 1213 382.49 3 1304 372 2.82%6 2957 1902.4 7.66 2446.79 1844 1839 3.45%7 2393 1368.25 6.15 2076.77 1332 1882 -27.30%8 1362 496.17 3.4 1401.68 465 918 -45.95%9 3570 2607.94 9.28 2844.3 2623 2937 -11.20%10 3365 2362.75 8.74 2712.36 2345 2336 1.14%11 2416 1354.17 6.22 2092.79 1845 1268 6.80%12 3794 2937.8 9.89 2993.72 3652 2983 -1.52%13 4770 8064.52 12.5 3634.42 13 3612 4523 78.30% -3.83% 0.62%14 1229 388.67 3.04 1306.98 384 387 0.43%15 433 82.79 0.91 787.77 77 69 19.99%16 2302 1252.42 5.9 2003.17 1181 1163 7.69%17 221 19.41 0.35 650.17 29 26 -25.36%18 4343 6131.41 11.73 3334.37 13 2051 3882 57.94% -9.78% 62.57%19 2537 1844.79 6.52 1716.49 8 3236 1386 33.10% -18.44% -46.96%20 3978 4504.78 11.57 3290.58 9 1828 3214 40.16% 28.51% 80.01%21 4838 8362.57 13 3386.16 13 2002 4629 80.66% 0% 69.14%22 1689 710.16 4.78 1341.02 670 671 5.84%23 1823 788.16 5.32 1418.6 855 759 3.84%24 1527 570.16 4.19 1255.95 565 560 1.81%25 2098 1041.17 6.34 1565.88 989 979 6.35%26 1857 867.97 5.42 1432.86 791 791 9.73%27 4904 8666.75 13 3096.96 19 3109 4750 82.46% -31.58% -0.39%28 1375 472.75 3.61 1174.31 469 465 1.67%29 4173 5398.16 11.2 2704.41 9 5122 3508 53.88% 24.41% -47.20%30 4615 7358.85 13 3482.79 9 2914 4226 74.13% 44.44% 19.52%31 3095 2015.26 8.01 2426.98 2016 2005 0.51%32 1566 594.59 4.35 1472.12 676 581 2.34%33 1921 849.01 5.69 1692.84 842 840 1.07%34 1412 490.82 3.74 1371.07 495 487 0.79%35 4851 8416.2 14.06 3527.18 10 3274 4654 80.84% 40.58% 7.73%36 2890 1844.12 8 2272.43 1770 1759 4.84%37 1106 335.54 2.58 1165.09 410 318 5.51%38 2466 1837.47 7.74 2008.38 1323 1316 39.63%39 616 168.15 0.74 863.06 213 123 36.71%40 743 263.85 1.21 941.02 172 178 48.23%41 2299 1189.95 7.13 1908.65 1257 1159 2.67%42 3201 2139.97 8.12 2460.84 2151 2133 0.33%43 39 6 344 1699 692.3 4.84 1534.55 684 671 3.17%45 2575 1439.29 8 2077.07 1433 1426 0.93%46 3326 2297.48 8.26 2539.32 2374 2289 0.37%47 2222 1107.9 6.82 1857.31 1097 1084 2.20%48 460 96.48 0.14 765.54 167 75 28.64%49 1096 402.51 2.54 1158.04 319 319 26.18%50 1886 817.05 5.56 1650.91 819 806 1.37%

Table 5.10 Actual and estimated execution times and overheads recorded when sorting a 50

number array on a BlackBerry 9780 on a 3G connection to the internet. Second trial.

42

estimated (ms) actual (ms) baseline (ms)

percentage error

item array size local remote overhead local remote overhead local local remote overhead1 1228 390 3882 3112 2026 21723 377 67 674 3085 2000.88 8 2296 1997 0.19%5 1213 385.15 5 877 372 3.54%6 2957 1892.03 7.8 1649.06 10 1388 1839 2.88% -22.01% 18.81%7 2393 1399.77 8.37 1238.28 6 1281 1882 -25.62% 39.56% -3.33%8 1362 511.63 5.13 852.16 463 918 -44.27%9 3570 2431.57 0.32 1730.07 10 1608 2937 -17.21% -96.82% 7.59%10 3365 2257.36 9.19 1599.06 9 2496 2336 -3.37% 2.14% -35.93%11 2416 1398.77 6.15 1502.07 1273 1268 10.31%12 3794 2753.34 11.15 2152.75 10 4462 2983 -7.70% 11.50% -51.75%13 4770 3808.12 10 3748.07 20 4269 4523 -15.81% -50% -12.20%14 1229 394.67 5.02 1420.61 390 387 1.98%15 433 89.04 4.34 854.91 163 69 29.04%16 2302 1182.45 5.92 2172.12 1172 1163 1.67%17 221 29 2618 4343 3336.51 15.53 3616.63 3841 3882 -14.05%19 2537 1404.78 7.01 2341.95 1424 1386 1.35%20 3978 3313.39 11.92 3365.25 3291 3214 3.09%21 4838 4619.88 20.64 3972.63 12 3302 4629 -0.20% 72.03% 20.31%22 1689 713.13 5.41 1634.85 669 671 6.28%23 1823 777.74 5.52 1721.11 765 759 2.47%24 1527 564.93 5.27 1524.98 561 560 0.88%25 2098 1001.65 5.75 1902.96 986 979 2.31%26 1857 792.33 5.55 1743.6 797 791 0.17%27 4904 4705.29 5.03 3756.33 13 3062 4750 -0.94% -61.31% 22.68%28 1375 468.53 5.14 1340.72 464 465 0.76%29 4173 3591.1 13.89 3088.93 11 1924 3508 2.37% 26.25% 60.55%30 4615 4265.92 17.53 3049.7 11 2901 4226 0.94% 59.32% 5.13%31 3095 2001.84 8.02 2167.43 2013 2005 -0.16%32 1566 585.43 5.3 1311.49 669 581 0.76%33 1921 848.22 5.6 1512.01 847 840 0.98%34 1412 489.89 5.17 1227.46 487 487 0.59%35 4851 4636.7 12.2 3153.83 13 2836 4654 -0.37% -6.18% 11.21%36 2890 1801.74 9.52 2008.25 1770 1759 2.43%37 1106 356.46 4.91 1030.81 327 318 12.10%38 2466 1340.78 6.54 1775.81 1326 1316 1.88%39 616 207.87 4.5 762.76 129 123 69%40 743 178.38 4.6 829.61 170 178 0.21%41 2299 1173.9 5.92 1682.65 1162 1159 1.29%42 3201 2141.68 8.38 2173.65 2138 2133 0.41%43 39 6 344 1699 671.75 5.41 1353.61 690 671 0.11%45 2575 1458.42 7.26 1832.34 1431 1426 2.27%46 3326 2332.07 8.84 2246.26 9 3142 2289 1.88% -1.82% -28.51%47 2222 1106.32 5.86 1780.66 1088 1084 2.06%48 460 157.71 4.36 734.17 84 75 110.28%49 1096 322.36 4.9 1110.57 321 319 1.05%50 1886 817.83 5.57 1578.15 816 806 1.47%

Table 5.11 Actual and estimated execution times and overheads recorded when sorting a 50

number array on a BlackBerry 9780 on a 3G connection to the internet. Third trial.

43

5.2.2. Accuracy of Decisions

In Section 5.2.1 we have discussed the accuracy of estimations. Based on these estimations the

Cost Estimator would make a decision on whether the execution of a partition should be

migrated. The accuracy of the decision would be discussed in this section.

As discussed in Section 4.2.1, the Cost Estimator would decide to migrate the execution of a

partition when d < k (i.e. estimated local execution time - estimated remote execution time <

estimated overhead). However, as both the value of d and k are based on estimation, the Cost

Estimator could possibly arrive at a wrong decision when the values of d and k are inaccurate.

When a partition is executed locally, we could not judge on the correctness of the decision as we

do not have the actual timing for the migrated execution of the partition. In other words, we

cannot claim in hindsight that we should have migrated for a shorter execution. As an example,

at time t = 0, the Cost Estimator decides to execute partition x locally. The execution completes

at t = 5. To conclude that the decision is wrong, we have to show that if the execution was

migrated at t = 0, it would complete before t = 5. However, the migration overhead at t = 0 would

never be known as it is dependent on the network condition at that instant. Thus, we could not

determine in hindsight that a decision to execute locally is wrong.

For migrated partitions, we could determine the correctness by comparing the migrated

execution time with a baseline local execution time. The baseline time is recorded in the

execution of a special version of the Modified JavaScript File which forces all executions to be

performed locally. Local execution times do not suffer from the fluctuations of network

conditions and would serve as a reliable comparison.

We could conclude that a partition is correctly migrated when execution time is shortened. On

the contrary, a partition is excessively migrated when the migrated execution takes longer than

executing it locally. The shaded rows in Tables 5.9, 5.10 and 5.11 are excess migrations where

44

the baseline local execution time < actual remote execution time + actual overhead time. Table

5.12 tabulates the number of excessive migrations in Tables 5.9, 5.10 and 5.11.

trial 1 trial 2 trial 3 averagenumber of excessive migrations 6 4 5 5

number of migrations 26 11 14 17percentage of excessive migrations 23.08% 36.34% 35.71% 31.38%

Table 5.12 Statistics on excessive migrations

Statistics show that 31.38% of the migrations in the three trial runs are excessive. Excessive

migrations could be occur because of inaccurate estimations or a surge in overhead due to

unstable network conditions.

Items 4 and 5 of the three trials are excessively migrated because of insufficient timing samples.

The estimated remote execution time and estimated overhead could not be calculated as there

were insufficient samples of remote execution times. At least two points are required for the

interpolation/extrapolation. The partition was migrated because the estimated local time exceeds

the arbitrary threshold of 100ms (refer to Section 4.2.1).

The excessive migrations would cause the total execution time to be increased. The increased in

execution time would be discussed in Section 5.3 where the performance gain delivered by

JSCloud would be discussed.

45

5.3. Performance Gain

Section 5.2.2 discussed how excessive migrations would increase the total execution time. The

performance gain delivered by JSCloud would be discussed in this section.

The performance gain is analyzed based on three measurements obtained from Tables 5.9, 5.10

and 5.11. First, the execution time without JSCloud which is the sum of the baseline local

execution time. Second, the execution time with JSCloud which is the sum of actual local,

remote and overhead times. Third, the ideal execution time which is the execution time when no

excessive migrations were performed. This ideal execution time is calculated by taking the sum

of the execution times for local executions; the execution times for correct migrated executions;

and the baseline local execution time for excessive migrations. The three measurements are

tabulated in Table 5.13.

trial 1 trial 2 trial 3 averageexecution time without JSCloud (ms) 77373 77373 77373 77373

execution time with JSCloud (ms) 53320 74554 70236 66036.67ideal execution time with JSCloud (ms) 51936 66371 67102 61803

Table 5.13 Statistics on execution times

In Table 5.14, the same data is presented as the percentage relative to the execution time without

JSCloud.

trial 1 trial 2 trial 3 averageexecution time without JSCloud (ms) 100% 100% 100% 100%

execution time with JSCloud (ms) 68.91% 96.36% 90.78% 85.35%ideal execution time with JSCloud (ms) 67.12% 85.78% 86.73% 79.88%

Table 5.14 Statistics on execution times shown as relative percentages

The experiment results shows that the execution time was reduced by 14.65%. The excess

migrations caused by incorrect decisions made by the Cost Estimator has prevented a potential

5.47% reduction in execution time.

46

The same experiment used to obtain the data in Tables 5.9, 5.10 and 5.11 was repeated on

different devices to obtain the performance statistics of JSCloud in different scenarios. The

results are presented in Figure 5.2.

!""#""$%

!""#""$%

&'#(($%

)!#("$%

*'#+,$%

!!,#()$%

!")#()$%

()#+)$%

),#!)$%

)&#')$%

"#""$% ,"#""$% *"#""$% -"#""$% ("#""$% !""#""$% !,"#""$%

.//01%234561%*7%829:;<91%)#"#!%=1><?0@%A95;B19%

7<:B?6C%D<0<EF%7,%2'!""%829:;<91%,#+#)%=1><?0@%A95;B19%

GHI%J0<KLA199F%'&("%829:;<91%-#"#"#,()%=1><?0@%A95;B19%

.//01%235M%N5?K4%!B@%D16#%829:;<91%+#!#+%=1><?0@%A95;B19%

.//01%I<KJ55L%395%,#,D4O%P,=%Q7%R%!"#-#&%7<><92%)#"#*%

<K@?<0%1E1K?S56%S:1%;2@4%T7P05?M%U:BV%

2M1<0%1E1K?S56%S:1%;2@4%T7P05?M%U:BV%

Figure 5.2 Statistics on execution times shown as relative percentages on various devices. Lower

number is better.

47

To account for the differences in execution performance of the devices, the length of the arrays

were adjusted individually for each device such that the sorting takes around 77000ms without

JSCloud. In other words, 100% equals to 77000ms of execution time for all devices.

The MacBook Pro and iPod Touch were connected to the Internet via Wi-Fi to a router that

accesses the internet from a cable modem. The BlackBerry, iPhone 4S and Galaxy S2 (Android

device) were connected to the internet via 3G network.

In the case of MacBook Pro and iPod Touch, JSCloud brought the execution time down to

57.95% and 52.15% of the original respectively. The execution was almost twice as fast. The

performance gained by JSCloud on these 2 devices are high due to two reasons: the internet

connection is fast and stable; and the JavaScript engine in the two devices are slow.

For the BlackBerry 9780, JSCloud brought the execution down to 85.35% of the original. The

lower performance gain is due to the high latency and instability of the 3G network.

On the iPhone 4S and Galaxy S2, JSCloud had increased the execution times to 112.85% and

105.85% respectively. The JavaScript engines in these two devices are already efficient enough

and any migration would suffer from the high latency of the 3G network. The ideal execution

time being 100% suggests that the best performance is achieved when no partitions are migrated

(i.e. when JSCloud is not used).

48

6. Conclusion

This section is a summary of the JSCloud project. The discussion would be divided into four

sections: the achievements; the critical review; the limitations; and future developments.

6.1. Achievements

The performance evaluation (Section 5) of JSCloud demonstrated that part of the aims were

successfully achieved.

JSCloud had successfully improved the execution time of JavaScript intensive web

applications on devices that have a lower JavaScript performance. The execution time could

be reduced by as much as 47.85% (Section 5.3).

The overhead for preparing the Modified JavaScript Code is negligible in comparison to the

average loading time of a webpage (Section 5.1.1).

6.2. Critical Review

Although the performance evaluation (Section 5) showed positive results, the analysis also

revealed two issues with JSCloud.

JSCloud was originally intended to provide performance benefits to all existing web

applications as shown in Figure 2.6. However, when using the first scheme (Section 4.1.2) of

partitioning which defines all functions in the Original JavaScript File as eligible for

migration, the overhead for local executions were too high (Section 5.1.2). The second scheme

where only annotated partitions was finally adopted. This scheme would require the manual

annotation of partitions by the web developer.

49

JSCloud also increased the execution time on devices which already have a high processing

power (Figure 5.2). This performance issue brings the practicality of JSCloud into doubt as the

future mobile devices would become faster and faster. The high JavaScript performance of the

current generation of smartphones (iPhone 4s and Samsung Galaxy S2) has already defeated

the purpose of JSCloud. The benefits of JSCloud is only limited to devices and web browsers

with low JavaScript performance.

6.3. Limitations

JSCloud is accessed as an HTTP Proxy. As such, JSCloud is incompatible with the HTTPS

protocol as the data stream is encrypted. Furthermore, some web servers would compress the

reply to the resource requests from web browsers to gzip format to minimize the transit time.

The current version of JSCloud would state explicitly in the HTTP request header that gzip is

not accepted such that the web server would reply only in plaintext. This incurs an overhead to

the transmission time as compression is not used.

Partitions also must be self-contained (Section 4.1.2) for migration. Therefore the

implementation of web applications must have a clear separation of control classes and

boundary classes to benefit from JSCloud. Control classes should be responsible for

processing only and must not access the DOM. Existing web applications where control

classes would access the web browser environment would have to be refactored in order to

meet the self-contained criteria.

50

6.4. Future Developments

The future developments of the JSCloud should emphasize on improving the issues in

performance and practicability as mentioned in Section 6.2.

The issue of performance degradation on already JavaScript efficient devices would be

addressed. When the HTTP Proxy receives a page request from an already powerful device it

would not insert migration logic to the code. The detection is performed by inspecting the

HTTP request header. The attribute User-Agent would state the name of the device as well as

the make and version of the web browser. If the HTTP Proxy receives a request from an User-

Agent that is in a predefined list of JavaScript efficient devices, then the JavaScript file is left

unmodified.

In JSCloud, the bottleneck in the performance of migrated executions is the transmission time

in the migration overhead (Section 5.1.2). The overhead could be further reduced by

compressing the reply from the Cloud JavaScript Engine into gzip format by JSCloud.

51

References

1. Microsoft Corporation (2012). Internet Explorer. Retrieved 26 January, 2012 from http://

windows.microsoft.com/en-us/internet-explorer/products/ie/home/

2. Apple Inc. (2012). Safari. Retrieved 26 January, 2012 from http://www.apple.com/safari/

3. Google Inc. (2012). Gmail. Retrieved 26 January, 2012 from http://www.gmail.com/

4. Facebook Inc. (2012). Facebook. Retrieved 26 January, 2012 from http://

www.facebook.com/

5. Twitter Inc. (2012). Twitter. Retrieved 26 January, 2012 from http://www.twitter.com/

6. Wikimedia Foundation. Wikipedia. Retrieved 26 January, 2012 from http://

www.wikipedia.com/

7. Tech Target (2006). What is Software as a Service (Saas)?. Retrieved 26 January, 2012 from

http://searchcloudcomputing.techtarget.com/definition/Software-as-a-Service/

8. Facebook Inc. (2012). Facebook Mobile Webpage. Retrieved 26 January, 2012 from http://

m.facebook.com/

9. Facebook Inc. (2012). Facebook Mobile. Retrieved 26 January, 2012 from https://

www.facebook.com/FacebookMobile/

10. Official Gmail Blog (2008). Introducing Gmail Labs. Retrieved 26 January, 2012 from http://

gmailblog.blogspot.com/2008/06/introducing-gmail-labs.html

11. Miller, R. B. (1968). Response time in man-computer conversational transactions. Proc.

AFIPS Spring Joint Computer Conference Vol 33.

12. Card et al. (1991). The information visualizer: An information workspace. Proc. ACH CHI'91

Conf.

52

13. Chun, B. G., Ihm, S., Maniatis, P., Naik, M., Patti, A. (2011). CloneCloud: Elastic

computation between mobile device and cloud. Proceedings of the 6th European Conference

on Computer Systems (EuroSys 2011).

14. Crockford, D. (2007). JavaScript. Retrieved 26 January, 2012 from http://

javascript.crockford.com/

15. W3C. (1998). What is the Document Object Model?. Retrieved 22 October, 2011 from http://

www.w3.org/TR/1998/REC-DOM-Level-1-19981001/introduction.html

16. Adaptive Path (2005). Ajax: A New Approach to Web Applications. Retrieved 26 January,

2012 from http://www.adaptivepath.com/ideas/ajax-new-approach-web-applications/

17. JSON.org. (2012). JSON. Retrieved 26 January, 2012 from http://www.json.org/

18. Crockford, D. (2012). Retrieved 26 January, 2012 from https://github.com/douglascrockford/

JSON-js/

19. Gu, X., Nahrstedt, K., Messer, A., Greenberg, I., Milojicic, D. (2003). Adaptive offloading

inference for delivering applications in pervasive computing environments. PerCom.

20. Messer, A., Greenberg, I., Bernadat, P., Milojicic, D., Chen, D., Giuli, T. J., Gu, X. (2002).

Towards a distributed platform for resource-constrained devices. ICDCS.

21. Ou, S., Yang, K., Zhang, J. (2007). An effective offloading middleware for pervasive services

on mobile devices. Journal of Pervasive and Mobile Computing.

22. Satyanarayanan, M., Kistler, J. J., Kumar, P., Okasaki, M. E., Siegel, E. H., Steere, D. C.

(1990). Coda: A highly available file system for a distributed workstation environment. IEEE

Trans. Comput.

23. Aridor, Y., Factor, M., Teperman, A. (1999). cJVM: A single system image of a JVM on a

cluster. ICPP.

53

24. Google Inc. (2012). V8 JavaScript Engine. Retrieved 26 January, 2012 from http://

code.google.com/p/v8/

25. Node.js. (2012). Node.js Homepage. Retrieved 26 January, 2012 from http://www.nodejs.org

54

Appendix

A. Monthly Log

Month Progress LogOctober 2011 - literature review

- produce project planNovember 2011 - literature review

- feasibility testDecember 2011 - literature review

- use case modelingJanuary 2012 - object modeling

February 2012 - object modeling- algorithm design- produce interim report- implementation

March 2012 - implementation- system testing- measure performance data- evaluate performance data

April 2012 - evaluate performance data- produce final report

B. User Guide

Cloud.js executes on the node.js runtime which could be obtained from http://nodejs.org/. After

the successful installation node.js, JSCloud could be started by the following procedures:

1. Configuring the HTTP Proxy

As mentioned in Section 4.1.1, there are multiple configurations for the HTTP Proxy. JSCloud

provides the option to set the HTTP Proxy as a standard proxy or a reverse proxy. This setting is

configured by modifying the var forwardProxy = true line in HTTPProxy.js.

55

The default port for the HTTP Proxy is 8000. To change the listening port of the HTTP Proxy,

modify the var listeningPort = 8000 line in HTTPProxy.js.

2. Configuring the Cloud JavaScript Engine

The default port for the Cloud JavaScript Engine is 8001. To change the listening port of the

Cloud JavaScript Engine, modify the var cloudEnginePort = 8001 line in HTTPProxy.js.

Then modify the var listeningPort = 8001 line in MigationEndpoint.js.

3. Starting the HTTP Proxy

The HTTP proxy could be started by the command node HTTPProxy.js in the command line

utility of the operating system.

4. Starting the Cloud JavaScript Engine

The Cloud JavaScript Engine could be started by the command node MigrationEndpoint.js

in the command line utility of the operating system.

JSCloud should then be successfully started. If JSCloud is configured as a normal proxy, any

devices that has added the JSCloud HTTP Proxy to the internet settings would benefit from

JSCloud. If JSCloud is configured to be a reverse proxy, devices only have to access the web

application normally by typing in the URL in the web browser.

56