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.

This thesis is dealing with vulnerabilities of web applications. The aim of the work is to create tools for attack detection of certain attacks, specifically Same Origin Method Execution (SOME), XML Signature Wrapping attack, XPATH Injection, HTTP Response Smuggling and Server-Side Includes (SSI) injection. Another aim is to create logs that display detected attacks. In the first part, the theory is analyzed and vulnerabilities of chosen attacks are described including their misuse. In the next section there are web application implemented which contain vulnerabilities for successful execution of the attacks. Furthermore, in Python language detection methods are designed and developed for these attacks, which are accompanied by a log entry.

Today, companies are developing processor demanding applications on the web, for example, 3D visualization software and video and audio software. Some of these companies have a native desktop application written in for example C++. These C++ codebases can consist of several hundred thousand lines of code, and companies would therefore like to reuse their codebase in the web version of the software. This thesis makes a performance comparison between two different approaches that can be taken to reuse the C++ codebase. The first approach is to compile the C++ codebase to WebAssembly and run it on the client-side. The second approach is to compile the C++ codebase to native code and run it on the server-side. It is not clear which approach to take if the goal is to achieve low execution times. This thesis will therefore answer the question of whether a client-side solution inWebAssembly is faster than a server-side solution in native code. To answer this question, this project work looked at one use case namely image processing. Two different web applications were developed, one that did image processing on the server-side in native code, and another one that did image processing on the client-side in WebAssembly. Execution time measurements were collected from both web applications. The results showed that for most algorithms WebAssembly was a factor of 1.5 slower than native code, without considering the additional delay from the internet that will affect the web application that performs image processing on the server-side. If this delay is taken into account, the web application that performs image processing on the client-side inWebAssembly will be faster than the server-side solution in native code for most users in the world. If the Round-Trip Time (RTT) is 1 ms the required average throughput needed to make the two web applications equally fast is 249 Mbps (Google Chrome) or 226 Mbps (Firefox). Most users in the world do not have such a high average throughput. / Idag utvecklar företag processorkrävande applikationer på webben, till exempel 3D-visualiseringsprogramvara och video- och ljudprogramvara. Några av dessa företag har även skrivbordsprogram skrivna i exempelvis C++. Dessa C++ kodbaser kan bestå av flera hundra tusen rader kod, och företag vill därför återanvända sin kodbas i webbversionen. Detta projektarbete gör en jämförelse mellan två olika tillvägagångssätt för att återanvända C++ kodbasen. Det första tillvägagångssättet är att kompilera C++ kodbasen till WebAssembly och köra koden på klientsidan. Det andra tillvägagångssättet är att kompilera C++ kodbasen till maskinkod och köra koden på serversidan. Det är inte klart vilken metod man ska ta om målet är att uppnå optimal prestanda. Detta projektarbete kommer därför att besvara frågan om en klientsidslösning i WebAssembly är snabbare än en serversidslösning i maskinkod. För att svara på den här frågan tittade projektarbetet på ett användningsfall, nämligen bildbehandling. Två olika webbapplikationer utvecklades, en som gjorde bildbehandling på serversidan i maskinkod och en annan som gjorde bildbehandling på klientsidan i WebAssembly. Körtidsmätningar samlades in från båda webbapplikationerna. Resultaten visade att för de flesta algoritmer var WebAssembly en faktor 1,5 långsammare än maskin kod, utan att ta hänsyn till den extra fördröjningen från internet som kommer att påverka webbapplikationen som utför bildbehandling på serversidan. Om denna fördröjning tas med i beräkningen kommer webbapplikationen som utför bildbehandling på klientsidan i WebAssembly att vara snabbare än serversidslösningen i maskinkod för de flesta användare i världen. Om tur och retur tiden (RTT) är 1 ms är den genomsnittliga genomströmning som krävs för att göra de två webbapplikationerna lika snabba 249 Mbps (Google Chrome) eller 226 Mbps (Firefox). De flesta användare i världen har inte så hög genomsnittlig genomströmning.

Websites are shifting from static model to dynamic model, in order to deliver their users with dynamic, interactive, and personalized experiences. However, dynamic content generation comes at a cost – each request requires computation as well as communication across multiple components within the website and across the Internet. In fact, dynamic pages are constructed on the fly, on demand. Due to their construction overheads and non-cacheability, dynamic pages result in substantially increased user response times, server load and increased bandwidth consumption, as compared to static pages. With the exponential growth of Internet traffic and with websites becoming increasingly complex, performance and scalability have become major bottlenecks for dynamic websites. A variety of strategies have been proposed to address these issues. Many of these solutions perform well in their individual contexts, but have not been analyzed in an integrated fashion. In our work, we have carried out a study of combining a carefully chosen set of these approaches and analyzed their behavior. Specifically, we consider solutions based on the recently-proposed fragment caching technique, since it ensures both correctness and freshness of page contents. We have developed mechanisms for reducing bandwidth consumption and dynamic page construction overheads by integrating fragment caching with various techniques such as proxy-based caching of dynamic contents, pre-generating pages, and caching program code. We start with presenting a dynamic proxy caching technique that combines the benefits of both proxy-based and server-side caching approaches, without suffering from their individual limitations. This technique concentrates on reducing the bandwidth consumption due to dynamic web pages. Then, we move on to presenting mechanisms for reducing dynamic page construction times -- during normal loading, this is done through a hybrid technique of fragment caching and page pre-generation, utilizing the excess capacity with which web servers are typically provisioned to handle peak loads. During peak loading, this is achieved by integrating fragment-caching and code-caching, optionally augmented with page pre-generation. In summary, we present a variety of methods for integrating existing solutions for serving dynamic web pages with the goal of achieving reduced bandwidth consumption from the web infrastructure perspective, and reduced page construction times from user perspective.

This paper takes a closer look and conducts a   comparison of two different approaches to generate interactivity of web   applications today, namely server or client side generation. The overall   purpose of the comparison is to help determine which approach is best suited   to generate maximum business advantage to least possible time cost. The   perspective used to measure this is usability seen from a developer's point   of view. The time it takes to acquaint oneself with a framework may vary on   several aspects and therefore a demarcated scenario has been set up and   individual parts have been evaluated side by side in the frameworks JSF and   Angular.io. Together with interviews of developer’s gathered experiences a   result has been possible to assemble. This result speaks neither for or   against either of the two approaches as both techniques have their own   advantages and disadvantages. What has been most prominent in the comparison   however is the introduction of the design pattern Model View Controller in a   framework for client side generation as Angular.io. This results in a similar   experience in usability as in a corresponding framework for server side   generation as JSF, which is good in an efficiency point of view. Still, the   lack of relevant error messages is experienced as a big problem in client   side frameworks and is an issue which stands out negatively in the   comparison. / Detta arbete avser titta närmare på och jämföra två   vanliga tillvägagångssätt för att skapa interaktivitet via webbsidor idag,   nämligen server- och klientsidegenerering. Det övergripande syftet med   undersökningen är att hjälpa till att utröna vilket tillvägagångssätt som är   bäst anpassat för att generera maximal affärsnytta till minsta möjliga   tidskostnad. Perspektivet som används för att mäta detta är usability ur   utvecklarsynpunkt. Tiden att sätta sig in i ett ramverk kan bero på ett   flertal aspekter och därför har en avgränsat scenario satts upp och   individuella delar har utvärderats sida vid sida i ramverken JSF och   Angular.io. Tillsammans med intervjuer av utvecklares samlade upplevelse har   ett resultat kunnat sammanställas. Detta resultat talar vare sig för eller   emot endera tillvägagångssätt då båda tekniker har sina för- och nackdelar.   Det som dock har varit mest framträdande i jämförelsen är att införandet av   designmönstret Model View Controller i ett ramverk för klientsidegenerering   så som Angular.io. Detta ger en likartad upplevelse i usability som ett   motsvarande för serversidegenererande så som JSF, vilket är bra ur   effektivitetssynpunkt. Dock upplevs bristen på relevanta felmeddelanden som   ett stort problem på klientsidegenererande ramverk och något som sticker ut   negativt i jämförelsen.