INOM EXAMENSARBETE TEKNIK,GRUNDNIVÅ, 15 HP

, STOCKHOLM SVERIGE 2017

A comparative study between server and client rendering of real-time data visualizations using D3

PETTER ANDERSSON

ROBERT WÖRLUND

KTHSKOLAN FÖR DATAVETENSKAP OCH KOMMUNIKATION

A comparative study between serverand client rendering of real-time datavisualizations using D3

PETTER ANDERSSON AND ROBERT WÖRLUND

Bachelor in Computer ScienceDate: June 5, 2017Supervisor: Michael SchliephakeExaminer: Örjan EkebergSwedish title: En jämförande studie mellan server- och klientrendering avreal-time data visualiseringar med D3KTH

ii

Abstract

Applying visualization techniques to larger data sets is important to make them easier toexplore and analyze. It is also desirable for the visualizations to be done efficiently wherethere is a continuous flow of data that needs to be visualized. This thesis will explore theperformance difference of client and server rendering respectively with the implementedJavaScript visualization framework D3. To perform the comparative study, two prototypeswere created, one using server-side rendering and one using client-side rendering. The timewas measured and compared between the two versions to see the impact on render and totaltime for different data sizes and different amount of concurrently connected clients. Render-ing times on the client version showed to be faster than on the server, however the data asJSON objects transferred in the client version was significantly larger than the SVG elementsin the server version, which leads to a trade off between transferring times and renderingtimes between the two versions. Increasing the amount of concurrent clients showed to havea significant impact on the server version for larger data sets which was to be expected.

iii

Sammanfattning

Appliceringen av visualiseringstekniker för större mängder av data är viktigt för att göradem lättare att utforska och analysera. Det är också önskvärt för visualiseringarna att gö-ras effektivt där det finns ett kontinuerligt flöde av data som behöver visualiseras. Dennarapport utforskar prestanda skillnaderna mellan klient och server rendering med det imple-menterade JavaScript visualiseringsramverket D3. Den jämförande studien gjordes genomatt göra två stycken prototyper, den ena renderade på server-sidan medan den andra ren-derade på klient-sidan. Olika data mängder och olika antal klienter testades för att se deraspåverkan på renderings- och totaltiden för de två versionerna. Renderingstiderna på klient-versionen var snabbare än på servern, dock var datan som skickades på klient-versionenstörre än de SVG element som skickades på server-versionen vilket leder till att det blir enavvägning mellan överföringstider och renderingstider för de två versionerna. En ökningav antalet parallella klienter hade en stor inverkan på tiden för server-versionen för störredatamängder vilket var förväntat.

Contents

Contents v

1 Introduction 11.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Background 32.1 Real-time data visualization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1.1 Web technologies and frameworks . . . . . . . . . . . . . . . . . . . . . 32.1.2 FusionCharts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.1.3 Dygraphs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.1.4 SVG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.1.5 Alternative Systems: Non-web based technologies . . . . . . . . . . . . 5

2.2 Communication Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2.1 Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2.2 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2.3 Different rendering techniques . . . . . . . . . . . . . . . . . . . . . . . 62.2.4 Server architecture and language . . . . . . . . . . . . . . . . . . . . . . 72.2.5 Server hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2.6 Server/Client Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2.7 Network delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3 Method 113.1 Test approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.1.1 Time measurement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.2 Test data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.3 Testing environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4 Architecture and implementation 144.1 Design choices and motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.1.1 Choosing visualization framework . . . . . . . . . . . . . . . . . . . . . 144.1.2 Choosing server hardware . . . . . . . . . . . . . . . . . . . . . . . . . . 144.1.3 Choosing server architecture . . . . . . . . . . . . . . . . . . . . . . . . 15

4.2 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164.2.1 D3 graph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164.2.2 Generating test data - data feed . . . . . . . . . . . . . . . . . . . . . . . 16

v

vi CONTENTS

4.2.3 Web site hosting the visualization . . . . . . . . . . . . . . . . . . . . . 16

5 Results 185.1 Data sizes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195.2 Graphs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

5.2.1 Fixed Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205.2.2 Increasing Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215.2.3 Concurrent Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

6 Discussion 246.1 Discussion of results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

6.1.1 Fixed data result . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246.1.2 Increasing data result . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256.1.3 Concurrent users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256.1.4 Comparing render times . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

6.2 Discussion of Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266.2.1 Choice of implementation . . . . . . . . . . . . . . . . . . . . . . . . . . 266.2.2 Data sizes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276.2.3 Performed tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

7 Conclusion and Future work 297.1 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297.2 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

7.2.1 Different implementations . . . . . . . . . . . . . . . . . . . . . . . . . . 307.2.2 Stronger Server System . . . . . . . . . . . . . . . . . . . . . . . . . . . 307.2.3 Concurrent user testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

8 References 31

Chapter 1

Introduction

Simulations are widely used in scientific purposes as well as other industries that producelarge volumes of data. Since the data items would be like a drop in the ocean when deal-ing with a lot of data when presented as text, it becomes necessary to apply visualizationtechniques in order to not render the data useless (Keim 2002). Without visualizing the datait would become very difficult to explore the data efficiently. This is why visualization is apowerful tool when dealing with big chunks of data.

In order to produce results from the data efficiently, the visualizations need to be done in afast and adequate manner. An example would be if a facility has a continuous flow of datato analyze. It would be helpful and interesting to be able to feed that stream of data to avisualization application that translates the data into graphs in real time. Now the results ofthe data can be used at the same time they are being produced.

Web-based frameworks can be a tool for achieving such visualizations in real-time. This re-port will explore the possibilities of translating that data into meaningful graphs in real-timeusing web technologies. Web-based visualization is an area in need of more research whichmakes it an interesting field to examine.

1.1 Purpose

When rendering data in real-time the visualizations need to be fluent, meaning that the dataneeds to be rendered within a certain time period to not fall behind the frequency of theinput data stream. In order to create a consistent and fluent environment a good workloadbalance is required between the server and client.

The purpose of this report is to examine the time difference between server-side renderingand client-side rendering when visualizing data.

1.2 Problem Statement

This study attempts to investigate and compare the performance for real-time visualizationon client- and server-side respectively. To compare performance the render time and totaltime will be measured with consideration to the amount of clients making requests concur-rently and different sizes of data sets. These parameters will be quantified in order to seetheir relation to the performance of the two different rendering techniques. What are the

1

2 CHAPTER 1. INTRODUCTION

drawbacks and benefits of using server-rendering compared to client-rendering when visu-alizing data in real-time?

1.3 Scope

This study will compare two specific implementations of real-time data visualizations on aserver/client model presented in chapter 3. The aim of the study is to test these two versionsusing different combination of values for the amount of connected clients and sizes of datasets.

The tests are performed by measuring the total amount of time it takes from the moment thatthe client makes a request to the server up until it presents the final result of the visualiza-tion. Additionally the rendering time on the client and server is also measured exclusivelyin order to divide the time results into two sections; the rendering time of the server or clientand the time it takes to transfer the data between server and client.

The data sets used as input for the visualizations are limited to the format of the data thatcan be found at SMHI open climate data on temperature (SMHI.se 2017). The data is mod-ified with some simplifications to only include temperature and the point in time for thattemperature value.

The two different versions will be implemented with the same underlying framework alsopresented in chapter 3 for visualizing data on the web to minimize any differences differentframeworks may have in the comparisons.

Chapter 2

Background

This chapter introduces the technical background of the report. It contains information aboutreal-time data visualization, existing technologies and frameworks, what communicationarchitecture to be used in web based visualization systems and their roles as well as somediscussion of relevant formats such as SVG and JSON.

2.1 Real-time data visualization

The main goal of data visualization is to relay key aspects of different data sets in a moreperceptive way. Functionality and design goes hand in hand as the purpose of the visualiza-tion is to communicate data in a more comprehensible manner (Friedman 2008). Its purposeis essentially to amplify cognition in terms of the intellectual process of perceiving the infor-mation (Jacko 2012).

Furthermore the data visualizations also need to be done efficiently as mentioned earlier.The real-time aspect of graphical visualizations aims to render the images within a certaintime frame, thus providing a sense of real-time rendering for the lowest performance costpossible. However, the term fast is relative and not a sufficient time-constraint for defining areal-time system. Typical time-constraints for certain tasks are periodic or aperiodic, wheretasks occur in an interval or have a deadline for when to start and finish. Many real-time sys-tems are often designed to be as fast as possible, where it is a question of certain trade-offs(Stankovic 1992).

The performance aspect of rendering the images efficiently becomes more relevant as thevisualizations are interactive, because user-interactions often desire immediate feedback.

2.1.1 Web technologies and frameworks

There exist various web-based visualization frameworks offering the possibility of real-timedata visualization.

Web technologies offer a much larger and easier availability of the visualizations comparedto using a native software program, because solely a web browser is required in order toaccess it, without any extra installation processes. A web-based visualization solution wouldtherefore be more advantageous for data that is stored on remote servers.

3

4 CHAPTER 2. BACKGROUND

2.1.1.1 D3

D3 is a widely used JavaScript visualization library that offers efficient data manipulation,with minimal overhead. It supports large data sets and various dynamic interactive be-haviours, such as zooming and panning. The visualization library uses HTML, CSS andSVG to visualize the data (D3js 2017). It also offers the possibility of creating almost any typeof visualization from the ground up. However, as there are no pre-built charts, this further-more steepens the learning curve for developers using the library (Thenextweb 2015).

D3 allows for the binding of arbitrary data to HTML DOM elements, and different transfor-mations to a document based on that data. Data can be used to create an HTML table froman array or create different SVG charts explained in 2.1.4. D3 is all about efficient manipu-lation of data on web documents. It is extremely fast and supports very large data sets andenables dynamic behaviours for interaction and animation (D3js 2017). D3 uses selectors tomanipulate specific nodes which are defined in W3C Selectors API (W3 2017). Attributes andother properties of the visualizations can also take the form of functions rather than simpleconstants to allow for more dynamic behaviours.

D3 is also supported on server-side when working with Node.js, running JavaScript on theserver.

2.1.1.2 C3

C3 is based on D3 with the purpose of making it easier to generate different charts by wrap-ping necessary code from D3.js into actual chart templates. (C3js 2017). These existing charttemplates allow for simpler chart management for developers, which is a big benefit whenusing this framework. C3 is likely to be less efficient than D3 because of its extra step totranslate back into D3, which consequently would lead to slower visualizations.

Most of the technical aspects can be viewed in the previous section 2.1.1.1 about D3. C3 pro-vides each generated element with some classes which enables for easy style customizationand the possibility to extend structures directly. It also gives the ability to update charts evenafter rendering, thanks to various APIs and callbacks that provide access to the state of thechart. However, C3 has no support for server-side rendering (C3js 2017).

2.1.2 FusionCharts

FusionCharts is a JavaScript visualization tool that presently has one of the most exhaustivechart and map collections on the market with over 90 different chart types available and hasa wide support for modern to old browsers. It supports both JSON and XML data formatsand export charts in formats like SVG, PNG or JPG. FusionCharts is also supported on serverside and their charts work across all devices (Sharma 2015).

2.1.3 Dygraphs

Dygraphs is an open source JavaScript charting library with support to all major browsers.The visualizations are limited to line graphs that can handle very large data sets, millionsof plot points, without hanging up. Interactive functionality, zooming, panning and mouseover are enabled by default (Dygraphs 2017).

CHAPTER 2. BACKGROUND 5

2.1.4 SVG

Scalable Vector Graphics, also known as SVG, is a format that is used in many areas such asanimation, user interfaces, Web graphics and mobile applications (Jiang, et al. 2007). Scal-able Vector Graphics (SVG) is a vector based image format for handling two-dimensionalgraphics. The format consists of an XML-based file format as well as a programming API forgraphical applications.

An XML-based file format uses the Document Object Model, also known as DOM, which isa programming API which defines the way documents are accessed and manipulated. DOMis also used in HTML which makes it easy for the SVG format and HTML format to worktogether. HTML is the standard markup language for developing web sites and integrateswell with JavaScript, CSS and many other languages. Using the DOM API, HTML has thebenefit of being able to work very fluently with frameworks using the XML-based file for-mat, since these XML-based elements, such as SVG, can be represented as elements in theHTML document. This makes the SVG format very relevant when developing web sites thatis using interactive vector graphics(W3.org 2017).

The format has support for animation and its key features include shapes, text and rastergraphics (Jiang, et al. 2007). Raster graphics are images often represented in bitmaps whichstores pixels and colors representing an image. Most images you see on your computer areraster graphics since they consist of an array of pixels (Techterms.com 2017).

2.1.5 Alternative Systems: Non-web based technologies

Using non-web based technologies for the visualizations, also known as native applications,has pros and cons. One of the pros is that native solutions can speed up the visualizationprocess since desktop applications generally have more access to the users hardware thanweb based technologies. One of the cons on the other hand is that it requires more work toreach a bigger audience because they are more specific to the native software or hardware ofa device, possibly requiring multiple versions supporting different operating systems, whichin turn might limit the availability of the non-web based solution (Guido 2013).

2.2 Communication Architecture

When developing web sites, a communication architecture is needed between the compo-nents to enable interaction for the user base. The most common form of network architectureused within data communication today is the server/client model. One medium where thearchitecture is widely used is in the ever expanding World Wide Web as stated by GilbertHeld in the book Server Management in the best practices series (Held 2000).

The author also mentions how there is not a single solution to a server/client architecture im-plementation, meaning it varies from case to case depending on what is needed. However,what all servers have in common is the strive for availability which also refers to consistentdata transmission at high data rates (Held 2000). Other advantages with the server/clientnetwork model is that it offers easier maintenance, security and administration (Exforsys2007). Upgrades and repairs can be made to the server without affecting the clients be-cause of the encapsulation of the server, also a variety of security configurations are possibleranging from passwords to certificates including different encryption techniques in order to

6 CHAPTER 2. BACKGROUND

minimize the risk of information theft. (Held 2000).

The common usage of a server-client architecture on web sites today provides a straightfor-ward option for the communication architecture when developing web sites.

2.2.1 Client

The client in a server/client architecture is described by Gilbert Held (2000) as a program orsystem that requests services from one or more other systems, that are referred to as servers,where these services usually accomplish specific tasks. The client is usually the workstation,where the user-interaction takes place (Held 2000). In figure 2.1 examples of different clientplatforms can be seen where client systems are connected to the server. One of the most usedform of a client is the web browser, since this type of client can be reached on a majority ofdevices. This facilitates the development of clients, since a version for every type of hardwareis not required.

Figure 2.1: An example of different clients connecting to the server

2.2.2 Server

The server is a program that receives requests from one or multiple clients to perform activ-ities which can allow the client to accomplish more assignments. (Held 2000)

To differentiate different web servers, every web server has an IP address that is unique tothat server. Each IP address consists of four numbers between 0 and 255, with the numbersseparated by a period. In the addition to an IP address, the server also has a unique IP namewhich is also referred to as its domain name. These names make it easier for the ordinaryday-to-day users to find web sites, since these names are easier to remember than the exactIP address. (Held 2000)

2.2.3 Different rendering techniques

When working with a server-client architecture in web visualization, there are two ways torender the data for the user. One is on the client itself and the other is on the server.

CHAPTER 2. BACKGROUND 7

2.2.3.1 Client-side rendering

Client-side rendering is when the visualization graphs are rendered on the client itself; pointsof data are turned into a graph. One of the strengths of rendering on the client is that itrequires less communication between the server and client but it requires more power fromthe client itself. When it comes to visualization libraries for client-side rendering, JavaScriptis a very popular and handy tool for developing these frameworks since it is able to beexecuted on the web site client. D3, as mentioned in 2.1.1.1, is an example of a JavaScriptframework that visualize data with help of SVG elements.

2.2.3.2 Server-side rendering

Server-side rendering is when the data points are turned into a graph on the server side andthen that visualized data is sent to the client in order to be presented to the user. One ofthe strengths of server-side rendering is that it requires less power from the client but it canbecome costly when many users are connected. For example, if the D3 framework is used torender SVG elements on the server, the rendered SVG element is then sent to the client. Tobe able to use this technology on the server side, the server also needs to run JavaScript toenable the usage of the D3 framework.

2.2.4 Server architecture and language

The server architecture can be described as the language that controls the server-managementof the server-client architecture. This is the application that controls the flow of deliveringthe content of the web site to each client and manages every concurrent user so that they allreceive the correct content. There are many alternatives when choosing which server setupto use, where two of the most widely used today are Node.js and PHP as the server corelanguage.

2.2.4.1 Node

Node is JavaScript on the server and has existed since 2009. Node works as an asynchronousevent driven environment designed to handle requests concurrently and to build small tobig network applications (nodejs.org 2017). One of the strengths of Node lies in that it isevent driven instead of using threads which is more commonly seen today. Dead-lock andI/O-blocks do not exist as they do in thread environments, which provides a system wherenothing is blocking, consequently making it good for developing scalable systems. HTTP isvery commonly used in Node, designed with consideration to low latency and streaming.This makes Node a good option for hosting web libraries and frameworks (nodejs.org 2017).

2.2.4.2 PHP

PHP has been used as one of the, if not the, most popular language to program serversin since 1995. The web server runs a single-threaded process that will stall if a request isblocked. The language started off as a dynamic language to update HTML pages. PHP codeis executed on the server, generating HTML which is then sent to client. One of the strengthsof PHP is that it has been around for many years, which has lead to it being able to integratewell with necessary APIs and drivers to interact with databases and other useful web necessi-ties. PHP has support for all major operating systems, including Linux, many Unix variants,

8 CHAPTER 2. BACKGROUND

Microsoft Windows, Mac OS X and RISC OS. It also supports countless protocols such as Hy-per text transfer protocol (HTTP) and File transfer protocol (FTP). It can also instantiate Javaobjects and use them transparently as PHP objects. Beyond server-side scripting PHP canalso be used for command line scripting and desktop applications although not as commonas its main field (php.net 2017).

2.2.5 Server hardware

Running the server on different machines might produce different results since the speci-fications on the machines can result in big differences when rendering on the server andhandling multiple concurrent clients.

2.2.5.1 AWS

AWS stands for Amazon Web Services and is a service that offers cloud computing servicesto businesses first and foremost. They offer services such as hosting applications and websites. AWS offers a vast diversity in different hardware setups for all scenarios of usage.Example of different purpose instances are generally purpose instances, memory optimizedinstances and compute optimized instances.

T2 instances are Burstable Performance Instances which provide a baseline level of CPU per-formance with the ability to "burst" above this baseline and get higher performance. Theseinstances are suitable for services with a CPU usage that occasionally bursts and need to usemore CPU power than usual. These T2 instances are used for web sites and web applicationsamongst other things.

T2.micro is a generally optimized instance.

InstanceType

vCPUMemory(GB)

Storage(GB)

NetworkingPerformance

PhysicalProcessor

ClockSpeed(GHz)

t2.micro 1 1EBSOnly

Low to Mod-erate

Intel XeonFamily

Up to 3.3

Table 2.1: AWS T2.micro instance specifications

As seen in figure 2.1, the t2.micro instance uses 1 GB of Memory and uses a High FrequencyIntel Xeon Processor with up to 3.3GHz clock speed. Its networking performance is limitedbut should be good enough for the testing environment. It uses EBS storage which standsfor elastic block store and is dynamically allocated cloud storage where the data size can bechanged by the user at any time (Amazon Web Services, Inc. 2017).

2.2.6 Server/Client Protocol

This section discusses which protocol to use for the transmission of the data and data formatsavailable between server and client.

CHAPTER 2. BACKGROUND 9

2.2.6.1 HTTP

“The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for dis-tributed, collaborative, hypertext information systems.” (Fielding, Reschke 2014). HTTP is arequest-response protocol. It works in the way that a client sends a HTTP request to a HTTPserver and then the server sends back a HTTP response. The principles, properties and con-straints of the Hyper text transfer protocol are now called REST. HTTP servers are used asthe servers managing web sites (Gaol, et al. 2017). Since the usage of HTTP is so popular,it has a lot of pros as in firewall access among other things, and is widely supported (Corey.2014).

2.2.6.2 JSON

JSON, JavaScript Object Notation, is a lightweight data-interchange format. JSON is lan-guage independent and is both easy for humans to read and write and easy for computersand systems to parse and generate. Even though it is language independent it uses languageconvention from the C-family languages (JSON.org 2017).

In a server and browser data exchange, the data can only be transferred in text. JSON, as atext-format, makes it easy for both server and client to work with the data, since it requires nocomplicated parsing or translations to modify and work with the data (w3schools.com 2017).The role of the JSON format is that it works as the format to transport the data between serverand client. For example, in a client-rendered version, the raw data can be transmitted fromthe server as a JSON which the client then can receive and render on the client-side.

JSON is widely supported both by language and software developers and it works naturallyin every JavaScript framework since it is implemented in the core of JavaScript.

2.2.6.3 TSV

A TSV file stands for a Tab-separated values file and is a data format that is used for rawdata. The format is most commonly found in spreadsheets and the data itself can be openedin a text editor, since they are essentially text files. The format is common when movingdata between spreadsheets. The D3 framework have implemented methods for handlingTSV data formats which makes it an option for data transmission. TSV could be used asthe format to store the generated data in and then render the data from this format, as analternative to JSON (Whatis.techtarget.com 2017).

2.2.7 Network delay

Network delay and the impact of the network is also an interesting aspect to take into accountas it plays a big role when transferring large amounts of data over the Internet. The effectof the network is something that will always affect the result, since the time to connect toa server and get a response can vary a lot from time to time. This can easily be shown inthe results below where the times of a ping to google.com is shown. Almost every entry issimilar but the pings unreliability results in one oddity with much higher ping.

time=1.78 mstime=1.72 mstime=1.72 ms

10 CHAPTER 2. BACKGROUND

time=1.70 mstime=1.84 mstime=1.79 mstime=1.70 mstime=1.67 mstime=40.1 mstime=1.52 mstime=1.75 mstime=1.74 ms

Controlling the effect of the network completely is hard to do but to minimize its impact onecan stay in the same network environment during testing, so the connection stays the sameas well as remove network irregularities from the result since they can be seen as effects ofthe network and not on the system itself.

Chapter 3

Method

This chapter describes the methodology that was used to carry out the comparative studybetween the version using server-side rendering and the version using client-side renderingof the data visualization prototype testing environment.

3.1 Test approach

The tests were performed by creating two prototypes, one for each version, in order to com-pare their performance of visualizing data in real time when increasing the parameters datasize and concurrent clients. The prototypes were comparable because they achieved the samething: rendering a 2D graph as an SVG element in an HTML document.

One version uses client-side rendering and will be referenced as the client-rendered versionin future context. This version requests the data from the server and the server sends the rawdata over as a JSON object. When the data is received on the client-side, it is drawn usingthe visualization framework which creates the SVG elements, which are displayable for theclient user.

The other version will be referenced as the server-version since it uses server-side rendering.It renders the data on the server instead, so when the client requests the graph, the serverrequests the data and creates the SVG element containing the graph and sends it to the client.

3.1.1 Time measurement

The comparison was made by measuring the time between requesting the graph to the fin-ished rendering of the graph. The definition of the time measuring is set by the time it takesfrom requesting the data to that the graph is visible on screen. The rendering times are alsomeasured to compare which time that increases the most when the amount of data or con-current users increase.

The time measurements are performed within the JavaScript code, executing time measure-ments for each part of the program. The total time is calculated on the client side by simplymeasuring the time from start to finish. The render times are executed within both the server-render code and the client-render code, and is put around the visualization algorithm to fullymeasure the render time measurement.

11

12 CHAPTER 3. METHOD

Figure 3.1: Time measurement differences between the two versions

Figure 3.1 above shows where the rendering takes place, in which component and when intime, for both versions. The total time for both versions is the entire spectrum from start tobeing done. It also shows that if both total time and render time are calculated, a remainingtime will be received. The remaining time mainly includes the time for transferring data andreceiving data between components added together shown above in figure 3.1, which is re-ceived by removing the render time from the total time. This time aspect is interesting sinceit shows how the different parts get affected in the tests.

3.2 Test data

For testing purposes, SMHI data was analyzed and its format recreated and generated in itsown server environment to allow for more customizable data sizes and frequency of howmuch and often data is generated. This was done to not limit the tests of the project to theSMHI data stream mentioned, which was updated only once per hour. The data is stored ina JSON object explained in 2.2.6.2 with two tags: time and temperature.

Unchanged data compared to changing data was tested to compare how the different ren-dering techniques handle this scenario. Unchanged data is the same data rendered multipletimes to get an average result of how long this data takes to render, compared to changingdata where, for every visual update, one or more nodes are added to the graph to producereal-time data. Comparing these two will show how server-rendering and client-renderingperform versus each other in the tests. Unchanged data will be referenced as fixed data, sincethe amount of nodes is unchanged and changing data will be referenced as increasing data,since the amount of nodes increases during testing.

The generated data elements will be called node elements and are defined as a data valuewith a point in time. When comparing different data sizes, they are separated into amountof nodes, which could also be described as amount of generated data elements that wasrendered for this test.

CHAPTER 3. METHOD 13

3.3 Testing environment

All tests were conducted with the server specifications presented in 4.1.2.1 and client speci-fications presented in 4.1.2.2.

Each result on fixed data was an average of measured time from 100 test cases. To excludelarger network irregularities from affecting the results, the top 10 percentile of the testingdata was removed since most of these irregularities were spotted in this region. As a result,the final average value was measured using the results of 90 test cases.

The tests were conducted on singular devices but also on multiple devices running concur-rently to see its impact on the results. When concurrent devices where tested, up to tenclients were used on five different devices, all with the specifications stated in section 4.1.2.2.When five concurrent clients were tested, five computers were concurrently connected to thetesting environment using one browser tab each. For testing ten concurrent clients, the samefive computers were used but two tabs were used for each device. The same data was sentto each concurrent client in every request. When measuring the time for these concurrentlyconnected devices, the mean value was calculated for all of the clients for every test.

The tests were put into three categories. First test was testing one device with fixed data fordifferent data sizes, to see the data sizes impact on the time. The second test was focusedon measuring the time for increasing amount of nodes to see the impact of increasing datasizes on the result. At every render point in the increasing data test, more nodes were addedto simulate a real-time environment. The third test was testing for multiple concurrentlyconnected devices, using one, five and ten concurrently connected units.

Chapter 4

Architecture and implementation

This chapter presents and motivates the design choices of this project and discusses the cho-sen architecture and implementation options.

4.1 Design choices and motivation

When the comparison of the speed between rendering on the server and rendering on theclient is at focal point, the effect that other factors have on the result should be minimizedso the major difference between the two outcomes is a result of the two different renderingtechniques. One of these factors is the use of the visualization framework, where using adifferent framework when rendering server-side compared to client-side could have an un-wanted effect on the results. For this reason the same framework should be used on theclient-side version as well as on the server-side version, to minimize any differences visual-ization libraries have as well as to reuse the same visualization code for the graphs with thesame properties.

4.1.1 Choosing visualization framework

There exist many alternatives for different client-side rendering frameworks. As referencedin section 2.1.1.1 D3 is a suitable framework for rendering visualization of data on the web,because of its wide usage and documentation as well as its support for both client- andserver-side rendering.

Initially C3 seemed like a good alternative since it was built on the D3 framework and alsoconsisted of pre-built graphs. The problem with C3 was that it did not support server-siderendering and since a comparison between server- and client-side rendering was required itwas not an optimal choice as a framework for the project. This made D3 the best choice forthe project with its wide support and documentation as well as working on both server andclient for rendering.

4.1.2 Choosing server hardware

To get the results from a more realistic scenario, a remote server was used as the serverenvironment. Using AWS, the instance this project utilizes is the t2.micro instance which is avalid server environment. This will provide more relevant results compared to if a personalcomputer would be used since a relevant server hardware setup is used.

14

CHAPTER 4. ARCHITECTURE AND IMPLEMENTATION 15

4.1.2.1 Server specifications

The server ran on an AWS t2.micro instance where the specifications can be found in sec-tion 2.2.5.1. Worth noting is the limited network performance, which is low to moderateand that is only single cored on its virtual processor with 1 GB of memory. Low to moder-ate networking performance corresponds approximately to a speed between 50-900Mbit/s,since it depends a lot on the instance itself. This makes the t2.micro instance low-end whencomparing it to other instance types available.

4.1.2.2 Client specifications

The specifications for the client computer was a windows 7 computer with the followingprocessor and amount of RAM.

Processor Clock Speed (GHz) Memory (GB) Networking SpeedIntel(R) Core(TM) i7-4790S 3.20 GHz 16.0 GB 929.52 Mbit/s

Table 4.1: The client specifications

The specifications shown in figure 4.1 provide a good testing environment since it providesa CPU with more than enough RAM and processing power for the projects testing purposes.It is worth noting that the clients tested on are high-end, which might lead to better perfor-mance than doing the tests on a smart phone with worse specifications.

4.1.3 Choosing server architecture

Continuing on the motivation behind using the D3 framework as the chosen visualizationframework, the server will be required to run the D3 framework as well to achieve that theframeworks impact on efficiency will be as minimal as possible. To run the D3 frameworkfor server-side rendering, the server needs to run on JavaScript which makes Node.js themost optimal choice as the server architecture, as it is modern, well used, lightweight, andsupports the chosen framework.

4.1.3.1 Communication protocol

When talking about server-client architecture, the HyperText Transfer Protocol(HTTP) hasmany advantages. One of its strengths lies in that it is widely used without exception whichgives it a lot of benefits. Using an alternative would require much more work since any goodalternative for the REST API with as much usage as HTTP does not exist. This makes HTTPan obvious choice for the communication protocol.

4.1.3.2 Choosing data format

JSON was chosen as a data format since its wide support together with all the available doc-umentation and discussion of the format made it a natural choice to use for transmitting thedata between server and client. The knowledge that it works fluently in JavaScript providesenough motivation for its usage.

16 CHAPTER 4. ARCHITECTURE AND IMPLEMENTATION

4.2 Implementation

When discussing the implementation of the different versions, focus was on stable and work-ing simplicity, as focus was not to produce a complex D3 graph, but more on performance.

4.2.1 D3 graph

The D3 graph that was used in the tests for both server-rendering and client-rendering washeavily influenced by the line graph implementation hosted on bl.ocks.org by Mike Bostock(Bostock, Mike 2017).

The additions and editing of this code focused on using JSON for storing the data instead ofTSV and making the necessary code changes for the code to work in a server environment,since that environment does not have a window, an HTML document, to work with in thesame way as the client-rendered version that the code is originally written for. JSDOM wasused to simulate an HTML document in the node server environment.

4.2.2 Generating test data - data feed

A data feed where the data can be requested as a JSON, was created using another Nodeserver that added a data node on every interval, which by default was set to three secondsto replicate a faster updated version of the SMHI data. The data itself contained the timeof update as well as the current temperature, which was generated by the application as anumber between a set interval of -10 to 30.

This data generating application also provided the option to start the system with pre gen-erated amounts of data, for example a start value of 10000 nodes. This is used in the teststo generate data between different sizes more quickly. For the results to produce a continu-ous graph, the time of the start-up data ends at the start of the current time to not break theline-graph and to provide a fluent continuous graph.

4.2.3 Web site hosting the visualization

The test environment was created as a dashboard on a web site; as a simple HTML pagehosted by a Node server. The HTML page gave users the ability to either render through theserver, render through the client or test both using an input of how many tests that shouldbe done on each version, and then these tests are performed calculating the average resultof the render times. The time results are shown on the web site and also in the developerconsole for easier analyzes of the result with an average result calculated. An illustration of avisualization rendered with the previously described implementations can be seen in figure4.1.

CHAPTER 4. ARCHITECTURE AND IMPLEMENTATION 17

Figure 4.1: Test-data with 10 000 nodes

Figure 4.1 shows the result of a visualization made with 10 000 nodes.

Chapter 5

Results

Here follows graphs showing the time measuring results of the data calculations for differenttesting scenarios. The tests that were conducted can be shown in table 5.1 down below,where all tests were separated into different graphs which are shown in this chapter. Moreexplanation about the different tests can be read in section 3.3.

Graph number Amount of nodes Concurrent clients5.2 1000 15.2 10000 15.2 50000 15.2 100000 15.2 200000 15.2 300000 15.3 10000-30000 15.4 1000 55.4 1000 105.5 10000 55.5 10000 105.6 100000 55.6 100000 10

Table 5.1: Tests performed and which graph they are displayed in

To display the data for the fixed and concurrent tests, a double bar graph was used. Tosimplify understanding these graphs, a demo graph is shown in figure 5.1 to display whatthe double bar graph indicates in the chapter. The left bar will display the time measurementof the version using client-side rendering while the right bar indicates the time measurementof the version using server-side rendering. The render time is displayed as the bottom partof the bar for both elements, and the top half displays the remaining time of the calculation.The concept of the remaining time is discussed in section 3.1.

18

CHAPTER 5. RESULTS 19

Figure 5.1: Demo graph showing how the data will be displayed in this chapter

5.1 Data sizes

Nodes JSON SVG103 69 kb 23 kb104 680 kb 160 kb105 6795 kb 1536 kb

Table 5.2: Byte sizes of different data samples

This table shows the differences in data sizes for both client-rendered version and server-rendered version for increasing data sizes and amount of nodes. The client version sends allthe data from the server to the client to get rendered. The data being sent is the generatedraw JSON elements with time and temperature, where one temperature and time gets repre-sented by one JSON element. The server-rendered version sends the generated SVG elementto the client, where the data is also integrated into the SVG element. The SVG elements aresmaller in size which means that the server-rendered version has less data to send for eachnew data update.

5.2 Graphs

Here follows the graphs for the tests, separated into sections. The sections are fixed data,increasing data and concurrent clients to separate the result into different interest since theyfocus on different areas.

20 CHAPTER 5. RESULTS

5.2.1 Fixed Data

Figure 5.2: Fixed data samples with unchanged data tested on 1 client with render times

The figure presented above in 5.2 shows the results of time measurements made with fixed,unchanged, data sample using 1 client. Both client- and server-versions follow the samelinear pattern when the data samples get larger. As can be seen in the figure the render timesconstitute a large portion of the total times measured for each sample. The server version isslightly slower in every case using only 1 client and fixed data where the biggest differenceis due to the render times for the two versions.

CHAPTER 5. RESULTS 21

5.2.2 Increasing Data

Figure 5.3: Data range: [103, 3*103], with an interval step of 10 nodes.

When increasing the amount of data each measurement using 1 client, figure 5.3 shows thatthe server-version was faster in the tested data range than the client-version. The rendertimes for both versions were approximately the same, but was slightly faster for the client-rendered data.

22 CHAPTER 5. RESULTS

5.2.3 Concurrent Clients

Figure 5.4: Data sample of 103 nodes, testing 1, 5 and 10 clients

The measured time for concurrent clients in figure 5.4 shows that for 103 nodes the total andrender times are approximately unchanged for 1, 5 and 10 clients.

Figure 5.5: Data sample of 104 nodes, testing 1, 5 and 10 clients

CHAPTER 5. RESULTS 23

The measured time for concurrent clients in figure 5.5 shows that for 104 nodes the total andrender times are approximately unchanged for 1, 5 and 10 clients.

Figure 5.6: Data sample of 105 nodes, testing 1, 5 and 10 clients

Increasing the amount of clients for a data size of 105 nodes showed in figure 5.6 an increasein total times for both client- and server-version where the server-version got significantlyslower than its client-version counterpart as the number of clients increased from 1 to 10,although when clients increased from 5 to 10 the client-version also slowed down a lot.

Chapter 6

Discussion

Here follows the discussion of the results and method of the study.

6.1 Discussion of results

When studying the graphs the results are separated into three different sections: Fixed data,increasing data and concurrent clients.

6.1.1 Fixed data result

The results for fixed data node samples can be seen in figure 5.2.

The results show that the render times increase when increasing the amount of nodes, whichis logical since it takes longer time to render additional data points. The server-render timesseems to increase faster than the client-render times which makes up the notable differencebetween the two versions.

The two different versions follow a similar linear pattern dependent on the data size in thistesting sequence. This is most likely because the same rendering algorithm was used forboth versions. If two different algorithms would have been implemented and compared, theresults for the different version could potentially differ more from each other at higher nodeinstances.

The remaining time also increases slightly when the amount of nodes increase but stays rel-atively close to each other for both versions. This shows that the differences between theamount of data that is being sent between the two different versions, where some size dif-ferences can be seen in table 5.2, are not affecting the total time that much. An increase ofremaining time is however logical due to larger data should take somewhat longer to trans-fer and parse.

Looking more at the table with data sizes, the JSON object that is being sent for the client-rendered version is bigger than the SVG element being sent by the server-rendered version.The results of the remaining time in figure 5.2 for data sizes of 100000 nodes and 200000nodes show that the client-rendered version take a little longer than the server-rendered ver-sions remaining time. This is probably due to the different transfer sizes, but the differencebetween the two times are too small to draw any concrete conclusions.

24

CHAPTER 6. DISCUSSION 25

6.1.2 Increasing data result

The increasing data test can be seen in figure 5.3. These tests ranged from 10000 nodes to30000 nodes to see how the results were affected by using alternating data, i.e. data that gotadditional nodes for every render cycle.

For the increasing data, the render times are approximately equal between the two versions,but the client-rendered version requires a lot more time for its remaining time. The only spotwhere the remaining time differs in the calculations according to figure 3.1 is when the JSONelements is sent from the server to the client, since the server-rendered version first rendersit. It is logical that this remaining time would be larger for the client-rendered version sinceit has to send more data as shown in table 5.2.

Drawing this conclusion however, that the remaining time for the client should be largersince it sends more data than the server-rendered version, does not show very well in thefixed test data where almost no effect by the data size could be seen. This makes it difficultto draw a clear conclusion of the impact of the data sizes since the result differ between thesetwo tests.

6.1.3 Concurrent users

The results for testing concurrent clients showed that increasing the amount of clients didnot affect the time measured for any version when the data size ranged between 1000 and10000 nodes. This is probably because the server is capable enough to handle up to thetested limit of 10 clients without a decline in performance when the data samples are smallenough. However, the difference in time for the two versions became visible when the datasize increased to 100000 nodes.

Compared to the fixed data results where the render times for each version were a largeproportion of the total times, the render times for the concurrent client tests were lower inrelation to the remaining times which mostly consists of transporting the data and handlingthe requests for all the concurrent clients. This is to be expected because the amount of clientsshould not affect the render times which are dependent on the data sizes.

It is also logical that the server-version was affected the most by increasing the amount ofclients for the test in 5.6 as it has to handle all the rendering for the clients which could lead tosome stalling for other clients making requests simultaneously, thus increasing the averagetimes for those tests. It is worth noting that the client-version still was affected by increasingconcurrently connected clients. This might come down to implementation factors since ittakes longer for the clients to receive the data from the server, so the server would have to beoptimized more to prevent client requests from stacking up and the server not being able tohandle them effectively.

6.1.4 Comparing render times

The fixed data time discussed in section 6.1.1, shows that since the remaining time is closeto equal, the render time constitutes the difference between the server-rendered version andclient-rendered version. When analyzing the data in the increasing data result on the otherhand, the result show that the server-render time and client-render time was approximatelyequal with the client-rendered version being slightly faster but it is difficult to compare their

26 CHAPTER 6. DISCUSSION

exact correlation. Determining if the client-rendered time is on average faster than the server-rendered time from the figure 5.3 is difficult, but since the difference is rather small for thesedata sizes in the fixed data result, between 10000 and 30000 nodes, it is a valid conclusion todraw with the help of the fixed data result. It is logical that these times are equal since thesame algorithm is used to render the data so it needs be discussed why this time differenceexists.

An explanation why the client performed better when rendering the data could be the dif-ference in hardware. The client had notably stronger specifications when it comes to CPUand RAM compared to the remote server, which could make the difference between the twoversions when it comes to rendering. Benchmarks for the two used hardware systems couldhave better shown their performance differences, but the results of the benchmarks werenot taken in consideration due to technical difficulties to run uniform benchmark tests forthe two hardware setups. A tunneled browser benchmark was made on the server side tocompare to the client benchmarks but was omitted since the reliability of the result was un-certain.

An explanation might be that the client-rendered version is better at rendering the same dataover and over, which happens in the fixed data test. This version runs the D3 JavaScript inthe web browser, which could save time when re-rendering the same data multiple timessince it could potentially utilize caching the data used in the algorithm, if the D3 algorithmsupports it. The server-rendered version cannot utilize this since on the server-side it is notcapable of storing that data in the same way because it has to create a new JSDOM windowfor every rendering request.

An alternative point of view in comparing the difference in render-times might be that theclient-rendered version is overall slightly faster than the server-rendered version due to theimplementation of the two.

6.2 Discussion of Method

This section discusses what could have been improved in the studies method to provide evenbetter result.

6.2.1 Choice of implementation

The tests were performed using a second server to generate the data and feed it to the vi-sualization server. Another realistic option would also be to provide the data directly to theserver or client. Having the data directly provided to the server and client would result in thetime measurement being more accurate in showing a render-time comparison. The results inthis studies case showed that the rendering time of the data was faster on the client in everycase compared to rendering it on the server, which would be interesting if that was the casefor this alternative version. With this method, rendering the data on the server would addadditional transfer times for the rendered data, which means the total time for the server-rendered version would be even worse in comparison to the client-version, whereas the totaltime for the client version would only consist of its render time. However, the renderingtime results are related to the hardware specifications of the server and client rather than theactual implementation, which means that if a server with much higher performance than the

CHAPTER 6. DISCUSSION 27

clients was used the results for rendering times might have been vastly different.

6.2.2 Data sizes

When working with re-rendering the same data multiple times with only minor additionsof data, an optimal solution would be to only send the added elements instead of all dataelements. This would accelerate the performance for the client-rendered version because itwould not have to transport all of the data at every render point. Since the impact of thedifference in data size was discussed and constituted the major difference between the twoversions in our increasing data test, it is definitely something to acknowledge when analyz-ing those results and should be more optimized to minimize unnecessary transportation ofdata in future work.

Table 5.2 show that the amount of bytes was larger for the client-rendered version sendingthe data in a JSON compared to a SVG element sent in the server-rendered version. Thissize for the elements was something that could have been decreased. The JSON elementnames were based on the SMHI data names which were "validTime" and "temp" (SMHI.se2017). The impact of shorter variable names is almost none for small amount of elementsbut when the data size increases, these variable names is what constitutes the major dif-ference between the client-rendered version and server-rendered version in table 5.2. Theserver-rendered version did not have these variables when transmitting data from server toclient since the elements were already rendered into the SVG element. It may not have hada big impact on the end result but more similar values would have been more interestingsince it would mean that aspect was having less of an impact on the end result. The datasent in the server-rendered version would still be smaller in size compared to the data in theclient-rendered version, but at least the difference between them would be smaller.

6.2.3 Performed tests

Three different kinds of tests were performed: fixed data, increasing data and concurrentclients.

6.2.3.1 Fixed Data test

The fixed data test shows the render and total time for visualizing the same fixed data forincreasing amount of nodes. Comparing these results to time measurement of data of a fixeddata size but where the data changes on each update could also be an interesting aspect sinceit would show if the client-rendered version had an advantage in rendering time for all casesas it looks with the current results.

6.2.3.2 Increasing Data test

The increasing data test was calculating the time for 10000 to 30000 nodes. This test wouldhave been improved if an even larger range of nodes would have been tested since the twoversions behaviour might differ for a larger amount of nodes than what was currently testedin this test. The size range of 20000 test nodes here, from 10000 to 30000 were chosen to showan area where the time measurements starts to increase. The time limits of the project andthe developed testing environment made it difficult to perform tests for even bigger rangesthat would provide even more relevant results.

28 CHAPTER 6. DISCUSSION

Testing the impact of only sending the added elements in the client-rendered version wouldalso be an interesting result to compare to the current results. The total time should be lowerthan in the current results due to drastically reduced amount of data being sent betweenserver and client for the client-rendered version.

6.2.3.3 Concurrent clients test

When it comes to the concurrent clients tests, the effect of running the concurrent tests forten clients on only five devices is unclear and could be discussed. In an optimal world,every connected client would have their own hardware to work with to make sure that theydo not interfere with each other. The tests could be affected by this which means that itbecomes difficult to draw conclusions from the concurrent clients test using ten concurrentlyconnected clients.

Chapter 7

Conclusion and Future work

7.1 Conclusions

Here follows the conclusions of the report, when to use server-side rendering and when touse client-side rendering when visualizing data using the D3 framework. Developing a dy-namic server that could adapt to the current server load, which would use the most optimalsolution at all time depending on the amount of connected users would be the most optimalserver environment since it can utilize the advantages of both versions. These conclusionsare closely connected to the testing environment and implementation. It was difficult todraw a conclusion where one version was the clear favorite and most suitable in all situa-tions; different situations favored one version over the other.

The server-version showed to be faster than the client-version when the data was changingand only one client was making requests, due to the difference in transfer times betweenthe two versions where the JSON data was significantly larger than the server rendered SVGelement. However, for unchanged data the client-version performed better than the server-version mainly due to better render times.

The client-version showed to be significantly faster than the server-version when increas-ing the amount of concurrent clients where the performance of the server-version was muchmore affected by an increase of clients at larger data samples. However, for data samplessmaller than or equal to 10000 nodes the two versions performed approximately the samefor 1 to 10 concurrent clients.

Thus, for stationary situations visualizing data, when you only need to render the data oncefor every client, the client-rendered version was most optimal since it had a faster rendertime compared to the server-rendered version. However, when working with real-time datawhere the amount of data nodes increase, the D3 framework was stronger using server-siderendering. It needs to be kept in mind that the server needs to be strong enough to handle theuser base since otherwise the server-rendered version needs to use a lot of time on handlingrequests of all the clients.

A conclusion would be that if your server can handle the user base, a server-rendered ver-sion would be stronger for real-time data visualization since it does not need to send as muchdata but the D3 framework is more optimized to work for client-side rendering where it isfaster.

29

30 CHAPTER 7. CONCLUSION AND FUTURE WORK

7.2 Future work

This section describes how the used methods could be improved upon as well as interestingaspects to focus on in the future.

7.2.1 Different implementations

The tests were conducted with the same rendering implementation on both server and client.In order to draw more general conclusions when comparing the two versions, more anddifferent implementations should be tested. An optimal solution on the client side might notbe the optimal solution on the server side making the results for using the same solution onboth sides misleading if the intention is to produce solutions that are as fast as possible forboth client and server. Thus, motivating the frameworks choices around having the mostoptimal implementation for both server-rendering and client-rendering would be a validdesign motivation to find the strengths in both rendering methods. However, testing thesame solution still provides a representation for how the two rendering techniques performunder the same conditions.

7.2.2 Stronger Server System

For further research in the area, more tests need to be performed with a stronger server-system. When looking at the server specifications in figure 2.1 in section 2.2.5.1, it is clear thatt2.micro is the bottom of the scale when comparing to other available instances that are alsoused for server environments. These statistics need to be taken into account when analyzingthe data since the tests performed in this project might not produce the same result that ahigh-end server with multiple concurrent processors would produce. More research with astronger server environment would be interesting for comparative research. It should alsobe interesting to test the client and server implementations on different hardware systems inorder to determine the impact of hardware performance on the two versions.

Using restricted hardware was also problematic since it limited the usability of differentbenchmarks when comparing the specifications of server and hardware.

7.2.3 Concurrent user testing

To improve the results and to get better conclusions how the amount of concurrent usersaffect the result, better concurrent testing needs to be conducted. Different but equally strongmachines should be used so all machines can use their hardware to its full potential, which inthis project was not fulfilled since parts of the concurrent tests were run on the same machine.Also the amount of users to be tested should increase a great amount since the result wouldbe more relevant to an actual web sites server usage when the amount of users goes up intothousands, compared to the tests of this project that tested the impact on up to ten concurrentusers. This test would go together with testing on stronger server hardware.

Chapter 8

References

Amazon Web Services, Inc. (2017). About AWS. [online] Available at: https://aws.amazon.com/about-aws/ [Accessed 24 Apr. 2017].

Amazon Web Services, Inc. (2017). EC2 Instance Types – Amazon Web Services (AWS). [online]Available at: https://aws.amazon.com/ec2/instance-types/ [Accessed 24 Apr. 2017].

Bostock, Mike. (2017). Line Chart. [online] Available at: https://bl.ocks.org/mbostock/3883245 [Accessed 2 May 2017].

C3js.org. (2017). C3.js | D3-based reusable chart library. [online] Available at: http://c3js.org/ [Accessed 24 Apr. 2017].

Corey. Web hosting blog (2014). The Pros And Cons Of Implementing SSL / HTTPS. [online]Available at: https://blog.nexcess.net/2014/09/03/the-pros-and-cons-of-implementing-ssl-https/ [Accessed 24 Apr. 2017]

Dygraphs.com. (2017). [online] Available at: http://dygraphs.com/ [Accessed 12 May2017].

Exforsys.com. (2007). Peer-to-Peer and Client-Queue-Client Architecture | IT Training and Con-sulting. [online] Available at: http://www.exforsys.com/tutorials/client-server/peer-to-peer-and-client-queue-client-architecture.html [Accessed 24 Apr.2017].

Fielding, R. Reschke, J. (Editors). (2014). Hypertext Transfer Protocol (HTTP/1.1): Message Syn-tax and Routing. [online] Available at: https://tools.ietf.org/html/rfc7230 [Ac-cessed 24 Apr. 2017].

Friedman, V. (2008). Data Visualization and Infographics [online] Smashing Magazine. Avail-able at: https://www.smashingmagazine.com/2008/01/monday-inspiration-data-visualization-and-infographics/ [Accessed 8 May 2017].

Guido, M. (2013). What’s the Big Deal with Native vs. Web vs. Hybrid Applications? [on-line] Mendix. Available at: https://www.mendix.com/blog/whats-the-big-deal-with-native-vs-web-vs-hybrid-applications/ [Accessed 3 May 2017].

Held, Gilbert. Best Practices Series: Server Management. 2005 IEEE. 2000 CRC Press LLC.https://books.google.se/books?hl=sv&lr=&id=Y9q-i_HGtAAC&oi=fnd&pg=PA3&

31

32 CHAPTER 8. REFERENCES

dq=server+client+architecture&ots=4CuPnwZm-U&sig=nSezVEzcCEiHcsrvCnYnUbI+EUxk&redir_esc=y#v=onepage&q=server%20client%20architecture&f=false

Gaol, et al. 2017. Server for SQLite database: Multithreaded HTTP server with synchronizeddatabase access and JSON data-interchange. Published in Advanced Communication Technology(ICACT), 2017 19th International Conference.

Jacko, Julia A. 2012. The Human-Computer Interaction Handbook, Third Edition. https://books.google.se/books?hl=sv&lr=&id=dVrRBQAAQBAJ&oi=fnd&pg=PP1&dq=human+computer+interaction+handbook&ots=wUejebvsj-&sig=B3Lzu58pg9sjroYj6Zt2+MOBSbvQ&redir_esc=y#v=onepage&q=human%20computer%20interaction%20handbook&f=false

Jiang, Fang, Ge, Zhou. 2007. Information Retrieval through SVG-based Vector Images Using anOriginal Method. Published in e-Business Engineering, 2007. ICEBE 2007.

Keim, Daniel A. (2002). Information visualization and visual data mining. [online] Published in:IEEE Transactions on Visualization and Computer Graphics

Nodejs.org, (2017). About Nodejs. [online] Available at: https://nodejs.org/en/about/[Accessed 25 Mar. 2017].

Php.net, (2017). Built-in web server, [online] Available at: http://php.net/manual/en/features.commandline.webserver.php [Accessed 25 Mar. 2017]

Sharma, N. (2015). The 14 best data visualization tools. [online] Available at: https://thenextweb.com/dd/2015/04/21/the-14-best-data-visualization-tools/ [Ac-cessed 10 Apr. 2017].

SMHI.se (2017). SMHI Öppna data. [online] Available at: http://opendata-catalog.smhi.se/explore/ [Accessed 24 Apr. 2017].

SMHI.se (2017). SMHI Öppna data - JSON data stream [online] Available at: http://opendata-download-metanalys.smhi.se/api/category/mesan1g/version/1/geotype/point/lon/16/lat/58/data.json [Accessed 24 Apr. 2017].

Stankovic, J. (1992). Real-time computing. Technical Report. University of Massachusetts [on-line] Available at: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.19.5916&rep=rep1&type=pdf [Accessed 28 Apr. 2017].

Techterms.com. (2017). Raster Graphic Definition. [online] Available at: https://techterms.com/definition/rastergraphic [Accessed 28 Apr. 2017].

W3.org. (2017). Selectors API Level 1. [online] Available at: https://www.w3.org/TR/selectors-api/ [Accessed 8 May 2017].

W3.org. (2017). What is the Document Object Model?. [online] Available at: https://www.w3.org/TR/WD-DOM/introduction.html [Accessed 24 Apr. 2017].

W3schools.com. (2017). JSON Introduction. [online] Available at: https://www.w3schools.com/js/js_json_intro.asp [Accessed 24 Apr. 2017].

Whatis.techtarget.com. (2017). What is TSV? What Opens a TSV? [online] Available at: http:

CHAPTER 8. REFERENCES 33

//whatis.techtarget.com/fileformat/TSV-Tab-separated-values-file [Ac-cessed 3 May 2017].

www.kth.se