För att spara tid och pengar i ett utvecklingsskede av en applikation, kan med fördel redan befintliga teknologier användas. För att skapa en arkivapplikation där användaren kan titta på och tanka hem arkiverat material utan för stora tidsförluster så krävs teknologier som klarar detta. Teknologin måste även klara av att hantera stora mängder data då arkivering av webben gör att datamängderna i arkivet hela tiden ökar. En teknologi som uppfyller kriterierna i OAIS-modellen som är en standard för arkivering och som kan hantera stora mängder data är NoSQL-databaser. Dessa finns i olika utföranden och är olika svåra att hantera. Denna studie har fokuserat på två populära dokumentbaserade NoSQL-databaser som är lätta att installera och relativt enkla att hantera. Vilken av dessa två NoSQL-databaser är då lämpligast för en applikation som skall lagra webbinnehåll? Frågan besvaras genom ett experiment vars inriktning är att utröna hur de två NoSQL-databaserna fungerar som arkivmedium. Utifrån studiens analys kan svaret ges att de fungerar olika bra i olika situationer. Skall applikationen användas för att lagra relativt små filer i form av PDF eller TXT så är MongoDB det bästa valet av de två. Om det däremot skall hanteras större filer så är CouchDB det bättre valet.

Val av databas kan vara ett svårt val då det finns en uppsjö av alternativ. Detta är ett val som alla har framför sig vid skapandet av ett nytt projekt. Denna undersökning av jämförelse med databaser kan underlätta valet av en databas.Genom ett eget experiment av två databashanterare (Mysql och Mongodb), så testades databaserna med läs, skriv och uppdateringsoperationer. En server skapades för att testa databaserna så att en jämförelse kunde ske med latenstider. Med hjälp av tidigare forskning i ämnet så gjordes en jämförelse också.Experimentet visade att Mysql var snabbare och hade lägre latenstider vid läsoperationer, men resultaten från litteraturstudien var oklara eftersom en studie visade på att Mysql var snabbare medan en annan studie visade att Mongodb var snabbare. Resultaten från både experimentet och litteraturstudien visade att vid skriv och uppdateringsoperationer så var Mongodb snabbare med lägre svarstider.Alla resultat i experimentet finns i appendix. / Choosing a database can be a difficult task as there are a plethora of options available. This is a decision that everyone faces when creating a new project. This comparison study of databases can facilitate the choice of a database. Through an own experiment of two database managers (MySQL and MongoDB), the databases were tested with read, write, and update operations. A server was created to test the databases so that a comparison could be made with latency times. Using previous research on the subject, a comparison is also made. The experiment showed that MySQL was faster and had lower latency times for read operations, but the results from the literature study were unclear as one study showed that MySQL was faster while another study showed that MongoDB was faster. The results from both the experiment and the literature study showed that for write and update operations, MongoDB was faster with lower response times. All results from the experiment are available in the appendix.

Syftet med detta arbete är att undersöka om det är möjligt att kunna i realtid undersöka kod på en webbsida för att rekommendera uppdatering av en befintlig webbläsare vid behov, utan att användarupplevelsen påverkas negativt. För att undersöka detta implementerades ett program i JavaScript. Sex olika JavaScript-bibliotek användes som testfall. Programmet söker igenom koden som finns i ett JavaScript-bibliotek och gör en rekommendation med hänsyn till några kända säkerhetsrisker och försvar mot dem. Dessutom beräknar programmet svarstiden med hjälp av klockan på klientsidan. Enligt Tolia, Andersen och Satyanarayanan (2006) visar undersökningar som har gjorts att användare föredrar svarstider som är under en sekund, och att svarstider som är över en sekund kan få användarna att bli missnöjda. För att användarupplevelsen inte skall påverkas negativt, bör svarstiden inte överstiga en sekund. Resultaten från undersökningen visar att svarstiderna inte blir tillräckligt långa för att kunna påverka användarupplevelsen negativt.

Det blir allt mer populärt att använda mobilapplikationer och det finns en ökning i popularitet för att utveckla hybrida applikationer på mobila enheter. I det kommande arbetet ställs frågan är om det är en skillnad på svarstiderna mellan de valda ramverken när det de hämtar data från en utomstående källa. De valda ramverken är React Native och NativeScript-Vue. Undersökningen motiveras av att det behövs mer information om de hybrida-ramverken. Det har använts ett teknik-orienterat experiment där det har skapats implementationer av en reseapplikation med React Native och NativeScript-Vue till en Android enhet. Dessa implementationer används sedan för att mäta tiden det tar för de olika ramverkens implementationer att skicka en förfrågan och ta emot den efterfrågande datan. Resultaten blev att det inte var en statistisk mätbar skillnad på svarstiderna mellan implementationerna. För framtida arbeten så kan det utökas med ytterligare hybrida ramverk och använda andra operativsystem för att mäta svarstider.

Hur presterar en webbplats som är byggd efter en multi-page arkitektur eller single-page arkitektur prestandamässigt? Hur stor påverkan har navigeringstider för webbplatser på användare och hur blir en webbplats mer användbar? En single-page applikation i två versioner har byggts upp med en Ajax sökfunktion som tillhandahåller en datauppsättning från StackOverflow. Undersökningsmetoderna experiment och användarstudie har tillämpats för att bevisa eller motbevisa hypotesen. Resultatet blev att single-page arkitekturen bevisades vara snabbare än multi-page arkitekturen. Användare anser att svarstider på webbplatser är mycket viktiga. En webbsidas design påverkar användarens vilja att använda denna och enligt deltagande testpersoner valdes en av versionerna ut som mer användbar.

No description available.

Med användning av ramverk kan förenkling av utritningen med pixel- och vektorgrafik i webbläsaren ske vid användning av WebGL API:t och Canvas 2D API:t. Men problemet är, att en dålig utritningshastighet är inget som vill upplevas när en 2D scen ritas ut i en webbapplikation. Genom att jämföra olika ramverk mot varandra, som använder sig av WebGL API:t eller Canvas 2D API:t, togs det reda på vilket av dessa ramverk som var snabbare i utritning. Tre ramverk valdes ut till studien för att göra mätningar på. Det implementerades en webbapplikation för att jämföra hur lång tid en utritning tar i de valda ramverken vid olika scenarier. Resultatet visade att ett hybridramverk som använde sig av förstnämnda API:t och föll tillbaka på andranämnda API:t var snabbare i 9 av 10 scenarier. I en fortsatt studie skulle flera ramverk kunna jämföras och även jämföras i olika användningsfall för att se hur ramverken presterar i dessa.

Webbapplikationers komplexitet och mängden avancerade tjänster ökar. Loggning av aktiviteter kan öka förståelsen över användares beteenden och behov, men används i för stor mängd utan relevant information. Mer avancerade system medför ökade krav för prestandan och loggning blir än mer krävande för systemen. Det finns behov av smartare system, utveckling inom tekniker för prestandaförbättringar och tekniker för datainsamling. Arbetet kommer undersöka hur svarstider påverkas vid loggning av serverdata, enligt datainsamlingsfasen i web usage mining, beroende på lagringsstrategier. Hypotesen är att loggning kan försämra svarstider ytterligare. Experiment genomförs där fyra olika lagringsstrategier används för att lagra serverdata med olika tabell- och databasstrukturer, för att se vilken strategi som påverkar svarstiderna minst. Experimentet påvisar statistiskt signifikant skillnad mellan lagringsstrategierna enligt ANOVA. Lagringsstrategi 4 påvisar bäst effekt för prestandans genomsnittliga svarstid, jämfört med lagringsstrategi 2 som påvisar mest negativ effekt för den genomsnittliga svarstiden. Framtida arbete vore intressant för att stärka resultaten. / Web applications complexity and the amount of advanced services increases. Logging activities can increase the understanding of users behavior and needs, but is used too much without relevant information. More advanced systems brings increased requirements for performance and logging becomes even more demanding for the systems. There is need of smarter systems, development within the techniques for performance improvements and techniques for data collection. This work will investigate how response times are affected when logging server data, according to the data collection phase in web usage mining, depending on storage strategies. The hypothesis is that logging may degrade response times even further. An experiment was conducted in which four different storage strategies are used to store server data with different table- and database structures, to see which strategy affects the response times least. The experiment proves statistically significant difference between the storage strategies with ANOVA. Storage strategy 4 proves the best effect for the performance average response time compared with storage strategy 2, which proves the most negative effect for the average response time. Future work would be interesting for strengthening the results.

Traditional relational databases store data in tabular form and have existed for several decades. The new requirements for data such as high availability and scalability have led to an increase in NoSQL databases in popularity. NoSQL databases meet these requirements as they use other methods for handling and storing data, for example document databases and graph databases are two of these variants. This study examined the difference in performance between the SQL Server 19 relational database and the Neo4j graph database. An experiment with the hypothesis: "Graph databases have faster response times compared to relational databases when retrieving the shortest route between two specified locations" was performed by executing a function on a dataset provided by the study's partner the Swedish Transport Administration. The data set represents Sweden's railway network and consists of 1320 places and 2788 associated connections. The function searched for the shortest route between two locations for four selected sections in each database architecture. The observed and analyzed response times show that Neo4j has an average response time that is 50 times faster than SQL Server 19, which verifies the hypothesis. The response times from the two databases were also tested with a Wilcoxon test which showed that the median response times differ from each other at a 1 % significance level. In addition, the results show that the average response time for SQL Server 19 will increase more than Neo4j as more sites and connections become involved in the search. Relational databases have slower response times than graph databases as they use join statements to find current relationships between its tables, which means that they must search all the data to find the shortest path between two places. Unlike relational databases, graph databases only use relationships directly connected to the current node where the algorithm is located, which means that response times are shorter. / Traditionella relationsdatabaser lagrar data i tabellform och har existerat i flera årtionden. De nya kraven på data som hög tillgänglighet samt skalbarhet har gjort att NoSQL databaser ökat i popularitet. NoSQL databaser tillgodoser dessa krav då de använder andra sätt för hantering och lagring av data, exempelvis är dokument-databaser samt grafdatabaser två av dessa varianter. I denna studie undersöktes skillnaden i prestanda mellan relationsdatabasen SQL Server 19 och grafdatabasen Neo4j. Ett experiment med hypotesen: “Grafdatabaser har snabbare svarstider i jämförelse mot relationsdatabaser vid hämtning av kortaste vägen mellan två angivna platser” genomfördes genom att exekvera en funktion på ett dataset som tillhandahållits av studiens samarbetspartner Trafikverket. Datasetet representerar Sveriges järnvägsnätverk och består av 1320 platser och 2788 tillhörande förbindelser. Funktionen sökte efter den kortaste vägen mellan två platser för fyra utvalda sträckor i varje databasarkitektur. De observerade och analyserade svarstiderna visar att Neo4j har en genomsnittlig svarstid som är 50gånger snabbare än SQL Server 19 vilket verifierar hypotesen. Svarstiderna från de två databaserna testades även med ett Wilcoxon-test som visade att svarstidernas median skiljer sig från varandra påen 1 % signifikansnivå. Därtill visar resultatet att den genomsnittliga svarstiden för SQL Server 19 kommer att öka mer än Neo4j då fler platser och förbindelser blir involverade i sökningen. Relationsdatabaser har långsammare svarstider än grafdatabaser då de använder join-satser för att hitta aktuella relationer mellan dess tabeller vilket gör att de måste söka igenom all data för att hitta kortaste vägen mellan två platser. Till skillnad från relationsdatabaser använder grafdatabaser endast relationer direkt anslutna till den nuvarande noden där algoritmen befinner sig vilket gör att svarstiderna blir mindre.

För att spara tid och ändå få en responsiv webbplats, kan med fördel ett responsivt front-end ramverk användas. Ett responsivt front-end ramverk kan använda olika angreppssätt: desktop-first och mobile-first. Påverkar front-end ramverkens angreppssätt (approach) något på en webbplats svarstider? Eller finns den stora betydelsen var webbplatsen renderar data, som hämtas från en databas? Ett experiment lämpar sig för att testa studiens hypotes. Utvärdering av studiens fyra olika webbapplikationer och analysering av mätningarna finns, för att få fram slutsatsen som är: Det finns ingen större skillnad mellan front-end ramverken, den stora betydelsen finns på val av rendering. Hypotesen motbevisas, då klientapplikationerna är snabbare än serverapplikationerna på alla plattformarna. Mätningar av svarstider finns och vid ett fortsatt arbete är det intressant bland annat också mäta batterimängden och plattformarnas minne. Implementera fler webbapplikationer, som använder andra front-end ramverk, där mätningarna kan exekveras på fler plattformar, webbläsare och scenarier.