Ett griddsystems prestanda beror till stor del på hur det hanterar data som ska bearbetas. I stora griddsystem finns det delsystem och till och med dedikerade relämaskiner för att hantera all data. Det spelar ingen roll hur mycket beräkningskraft som finns till förfogande om det som beräkningen ska utföras på inte finns tillgängligt. För att undersöka mindre icke dedikerade system implementerar det här examensarbetet ett nytt griddsystem och integrerar tre olika buffringstekniker i det. Dessa tekniker används i ett mycket litet griddsystem med begränsad hårdvara för att utvärdera hur de påverkar processhastigheten. Även om förhoppningen finns att öka prestandan är detta inget som kunde påvisas i den specifika hårdvarumiljö där utvärderingen gjordes. Trots detta kan positiva effekter ses som bör undersökas vidare.

This study has been performed with an aim to provide an insight into how Node.js is used and the Node.js technology adaptation in the open source community. This research displays the diversity of Node.js and can inspire the reader to further development or continued research. Studies into different usages of Node.js have been missing in academic research and therefore this study gives a new, important insight into this technology. The authors used the exploratory case study methodology. For data collection, the authors created a JQuery and HTML script that fetched the desired dataset from Github and that were used as a static base for the study. Based on the usage areas extracted from the literature study, the authors specified different categories of usage. The dataset was manually investigated and placed into the categories, if they were relevant. The results show that web applications is by far the most well represented category with over 50% of all usages falling into this category. Network applications and Web servers come in at second and third position with 14% and 13% respectively. This study provided further categories and the authors could generate a set of diagrams, showing a trend on how the different usage areas changed from 2010 to 2015.

GraphQL is a query language for web APIs and a service for carrying out server requeststo interact with the data from the API. Research show that even for simple GraphQL queriesboth the size of the response object and the execution times to retrieve these objects may beprohibitively large and that current implementations of the language suffers from this issue.This thesis explores the implementation of an algorithm for calculating the exact size of theresponse object from a GraphQL query, and the performance based evaluation of the implementation. A proof of concept of a server using the implementation of the algorithm and subsequent tests of thecalculation times for particularly problematic queries sent to the server, show that the implementationscales well and could serve as a way to stop these queries from executing.

The thesis deals with the creation of the application solution for device localization using blockchain.The first part of the thesis is an overview of blockchain platforms and existing projects working with localization and description of technologies used in the implementation. The second part deals with the creation of the solution which is divided into the mobile application, the server application and the blockchain part. The last part describes testing, results, evaluation of the whole solution and its use.

When developing web applications using traditional methods, developers need to partition the application logic between client side and server side, then implement these two parts separately (often using two different programming languages) and write the communication code to synchronize the application's state between the two parts. CloudBrowser is a server- centric web framework that eliminates this need for partitioning applications entirely. In CloudBrowser, the application code is executed in server side virtual browsers which preserve the application's presentation state. The client web browsers act like rendering devices, fetching and rendering the presentation state from the virtual browsers. The client-server communication and user interface rendering is implemented by the framework under the hood. CloudBrowser applications are developed in a way similar to regular web pages, using no more than HTML, CSS and JavaScript. Since the user interface state is preserved, the framework also provides a continuous experience for users who can disconnect from the application at any time and reconnect to pick up at where they left off. The original implementation of CloudBrowser was single-threaded and supported deployment on only one process. We implemented CloudBrowser 2.0, a multi-process implementation of CloudBrowser. CloudBrowser 2.0 can be deployed on a cluster of servers as well as a single multi-core server. It distributes the virtual browsers to multiple processes and dispatches client requests to the associated virtual browsers. CloudBrowser 2.0 also refines the CloudBrowser application deployment model to make the framework a PaaS platform. The developers can develop and deploy different types of applications and the platform will automatically scale them to multiple servers. / Master of Science

The purpose of this thesis was to investigate whether utilization of the Node.js Cluster module within a web application in an environment with limited resources (the Heroku Cloud App Platform) could lead to an increase in throughput of the application and, in the case of an increase, how substantial it was. This has been done by load testing an example application when utilizing the module and without utilizing it. In both scenarios, the traffic sent in to the application varied from 10 requests/second to 100 requests/second. For the tests conducted on the application utilizing the module the number of worker process used within the application varied between 1 and 16. Furthermore, the tests were first conducted in a local environment in order to establish any increases in throughput in a stable environment, and, in case there were notable differences in throughput of the application, the same tests were conducted on the Heroku Cloud App Platform. Each test was also aimed towards testing one of two different types of tasks performed by the application: I/O or CPU bound. From the test results, it could be derived that utilization of the Cluster module did not lead to any increases in throughput when the application was doing I/O bound tasks in neither of the environments. However, when doing CPU bound tasks, it led to a ≥20% increase when the traffic sent to the application in the local environment was 10 requests/second or higher. The same increase could be seen when the traffic sent to the application was 50 requests/second or higher in the Heroku environment. The conclusion was, thus, that utilization of the module would be useful for the company (that this thesis took place at) in case an application installed on Heroku was exposed to higher traffic. / Syftet med detta examensarbete var att undersöka om huruvida nyttjande av Node.jsmodulen Cluster i wen webbapplikation i en miljö med begränsade resurser (Heroku cloud appplattformen) skulle kunna leda till en ökning i throughput hos applikationen, och om det skedde en ökning – hur stor var då denna? Detta har gjorts genom att belastningstesta en exempelapplikation nyttjande modulen och utan den. I båda scenarier varierade trafiken som skickades till applikationen mellan 10 och 100 requests/sekund. För testerna utförda i applikationen som nyttjade modulen varierade antalet workerprocesser mellan 1 och16. Vidare utfördes testerna i den lokala miljön med målet att slå fast möjlig throughputökning i en stabil miljö först, och om det fanns några märkbara skillnaden i throughput hos applikationen skulle samma tester även utföras på Heroku app cloudplattformen. Varje test strävade också för att testa en av två olika typer av arbetsuppgifter utförda av applikationen: I/Oeller CPUbundna. Från testresultatet kunde det fastslås att: Clustermodulen ledde inte till några ökningar vad gällde throughput när applikationen gjorde I/Obundna arbetsuppgifter i någon av miljöerna. När applikationen däremot gjorde CPUbundna arbetsuppgifter ledde det till en ökning på ≥20% när trafiken var 10 requests/sekund eller högre. Samma ökning kunde ses först när trafiken kommer över 50 requests/sekund eller högre i Herokumiljön. Slutsatsen var därmed att användande av modulen skulle vara användbart för företaget som arbetet uträttades hos om en applikation som låg installerad på Heroku utsattes för vad som ansågs vara högre trafik.

Webbapplikationer blir mer och mer avancerade och ställer mer krav på dagens enheter. Rendering av grafik i HTML5 canvas är något som kan ställa stort krav på enheter och en påföljd av detta är att svarstiden blir lång. En eventuell lösning på problemet med bristande prestanda hos enheter är att förflytta renderingen från klientsidan till serversidan. Två versioner av samma webbapplikation skapades där renderingen sker på klientsidan i en version och på serversidan i annan version med hjälp av Node.js. Webbapplikationen renderar diagram som baseras på olika variabler. Tester genomfördes för att jämföra versionerna, där det visade sig att klientversionen var den version som resulterade i lägst svarstid och minst överförd datamängd. Ytterligare tester med större skillnad gällande prestanda och typ för enheter är av intresse för framtida arbete.

A new high-level language is sought after for implementing and mocking functional-ity on the Axis Communications platform. We analyze what impact the Node.js run-time environment has regarding performance and its ability to perform functionality.The performance refers to metrics on CPU, memory, free disk space and responsetimes and what effect an added Node.js runtime has on the platform. The functional-ity is based on Axis’ ideas about having Node.js run high-level services. A test planvalidates the functionality of a JavaScript service implemented as an API with JSONobjects as a POST and GET methods. To test the performance a test suite that sam-ples the data on a device and saves it like log files on a client. The variable is threedifferent stages, where the current device serves as the baseline. Secondly, to findout what impact Node.js itself has the second stage is with Node.js present and thethird stage represents a device where Node.js and the JavaScript service is put underload. The results show that it is possible to implement a JavaScript service runningunder Node.js since the test plan with its assertions passed on all tests. Regardingperformance and response time we did see a decrease in CPU idle time and memoryand an increase in the response time compared to the baseline.

Denna studie har undersökt vilken av CouchDB och MongoDB som har lägst svarstider vid hantering av filformaten epub, mobi, txt och html. De operationer som har undersökts är insert, update, select och delete för att se vilken av databaserna som presterar kortast svarstid. Resultatet av undersökningen är att databaserna är bra på olika saker där CouchDB presterade bättre vid inmatning av epub, txt och html-formaten samt vid uppdatering och borttagning av alla format. MongoDB presterade däremot bättre vid hämtning av alla filformaten vilket gör att databaserna är bra i olika situationer beroende på vad databasen ska användas till. Om databasen kommer att utföra många select-operationer passar MongoDB bäst medans vid borttagning och uppdatering passar CouchDB bäst. Vid inmatning beror det på vilket filformat som kommer hanteras mest då databaserna presterade liknande resultat för mobi-formatet medans CouchDB presterade bättre vid de andra formaten.

Since JavaScript code that is executed by the Node.js run-time environment is run in a single thread without really utilizing the full power of multi-core systems, fairly new approaches attempt to solve this situation. Some of these approaches are considered well publicly tested and are widely used at the time of writing this document. The objectives for this study are to check which ones of these approaches achieve the better scalability in accordance to the number of handled requests, and to what extent those approaches utilize the multi-core power compared to the raw Node.js environment with the normal CPU scheduling.