As the Internet has become increasingly important for people and for businesses that rely on it to create revenue, Internet unavailability can have major consequences. A common cause to unavailability is performance related problems. In order to evade such problems, the system’s quality characteristics in terms of performance need to be evaluated, which is commonly done with performance testing. When performance tests are conducted, the system under test is driven by an artificial workload or a sample of its natural workload while performance related metrics are measured. The workload is a very important aspect of performance testing, proved by measured performance metrics being directly dependent on the workload processed by the system under test. In order to conduct performance tests with representative workloads, the concept of workload modelling should be considered. Workload models attempt to model all relevant features of the workload experienced by a system within a given period of time. A workload model is created by set of consecutive activities that together constitute a process. This explorative feasibility study focuses on exploring, describing and evaluating the feasibility of a tool for automating the process of modelling Web server workloads for performance testing. A literature review was conducted in this student thesis, from which a research model was developed that describes the key factors in the process of modelling Web server workloads for performance testing, the relationships between these factors and their variables. The key factors constitute of four sub-processes and the relationships between them are the sequence flow, i.e. the order of events in the process. The process is initiated by the sub-process Establish Workload Data, where the workload data are retrieved and sanitised. The workload data are then categorised in homogeneous groups called workload entities, which is done in the Identify Workload Entities sub-process. Each workload entity has some associated workload attributes that are identified in the Identify Workload Attributes sub-process. In the last sub-process, Represent Workload, statistical methods, such as standard deviation and arithmetic mean, are applied in order to represent the workload in graphs and tables. Based on the research model and in order to evaluate the feasibility of a tool, a prototype was developed. The feasibility was evaluated through analysis of the primary empirical data, collected from an interview with a field expert who had tested the prototype. The analysis indicated that developing a tool for automating the process of modelling Web server workloads for performance testing is indeed feasible, although some aspects should be addressed if such a tool was to be realised. Analysis implied that an important aspect of modelling Web server workloads for performance testing is that the modeller must be in controller of what is being modelled. The prototype that was developed is highly static, i.e. it is not possible to create customised workload models. Therefore, if the tool is going to be realised, functionality for customising workload models should be added to the tool. Another important aspect that should be addressed if the tool is going to be realised is graphical representation of multiple workload attributes. The analysis indicated that there might be correlations between workload attributes. It is therefore important to be able to graphically represent multiple workload attributes together so that such correlations can be identified.

Denna uppsats mäter och jämför prestanda mellan en objektorienterad databas och en relationsdatabas. Uppsatsen bygger på en utredande karaktär utifrån vår hypotes och vårt intresse att testa den.Hypotesen bygger på problematiken omkring mängden kod utvecklaren måste skriva för att kunna koppla ihop applikation med databas. En större mängd skriven kod som utvecklaren måste skriva borde göra att prestanda och svarstider blir långsammare. Därför ville vi undersöka om verktyg som medför en mindre mängd skriven kod kan förbättra prestandan och ge snabbare svarstider. Vi valde att testa vår hypotes mellan ADO. NET relationsdatabas och ADO. NET Entity Framework objektorienterade databas då ADO. NET genererar större mängd kod och Entity Framework innehåller verktyg som i sin tur genererar mindre mängd kod. För att kunna mäta och jämföra prestandan utvecklades en mindre kundapplikation kopplad med respektive ramverks databasmodell där båda använder sig av samma databas. Genom att mäta prestandan har vi kunnat jämföra de olika modellerna och då även kunnat se vilka fördelar och nackdelar respektive modell genererat. Vi har även mätt antal kodrader och diskuterat hur det påverkar kostnaden av systemutvecklingen samt underhållbarheten för applikationen. Det som framförallt framkom var att relationsdatabasen resulterade i en något snabbare prestanda mätt i millisekunder trots att antal kodrader blev fler jämfört med en objektorienterad databas. Den objektorienterade databasen resulterade i något sämre prestanda men med färre antal skrivna kodrader. Det medför att den kräver mindre underhåll i koden vid förvaltning av den nya applikationen. Det innebär även att tiden vid utveckling för den vane programmeraren minskar med cirka 50 % och därmed sjunker även utvecklingskostnaden, under förutsättning att en något långsammare prestanda kan accepteras.

There is problem that every company has its own customer portal. This problem can be solved by creating a platform that gathers all customers’ portals in one place. For such platform, it is required a web API protocol that is fast, secure and has capacity for many users. Consequently, a survey of various web API protocols has been made by testing their performance and security. The task was to find out which web API protocol offered high security as well as high performance in terms of response time both at low and high load. This included an investigation of previous work to find out if certain protocols could be ruled out. During the work, the platform’s backend was also developed, which needed to implement chosen web API protocols that would later be tested. The performed tests measured the APIs’ connection time and their response time with and without load. The results were analyzed and showed that the protocols had both pros and cons. Finally, a protocol was chosen that was suitable for the platform because it offered high security and fast connection. In addition, the server was not affected negatively by the number of connections. Reactive REST was the web API protocol chosen for this platform. / Det finns ett problem i dagens samhälle gällande att varje företag har sin egen kundportal. Detta problem kan lösas genom att skapa en plattform som samlar alla kundportaler på samma plats. För en sådan plattform krävs det ett web API protokoll som är snabb, säker och har kapacitet för många användare. Därför har en undersökning om olika web API protokolls prestanda samt säkerhetstester gjorts. Arbetet gick ut på att ta reda på vilket web API protokoll som erbjuder hög säkerhet och hög prestanda i form av svarstid både vid låg och hög belastning. Det ingick också i arbetet att göra en undersökning av tidigare arbeten för att ta reda på om eventuella protokoll kunde uteslutas. Under arbetet utvecklades också plattformens backend som implementerade de olika web API protokollen för att sedan kunna utföra tester på dessa. Testerna som utfördes var svarstid både med och utan belastning, uppkopplingstid samt belastning. Resultaten analyserades och visade att protokollen hade både för- och nackdelar. Avslutningsvis valdes ett protokoll som var lämpad för plattformen eftersom den hade hög säkerhet samt snabbast uppkopplingstid. Dessutom påverkades inte servern negativt av antalet uppkopplingar. Reactive REST valdes som web API protokoll för denna plattform.

Tidigare forskning visar att responstid har stor inverkan på användarens upplevelse online. Trots det saknas tydliga metodiker för hur man ska arbeta med responstid. Med detta i åtanke blev studiens syfte att undersöka hur företag bör arbeta med responstid i webbapplikationer och huruvida man bör ta hjälp av användare i arbetet. Undersökningen skedde med hjälp av en litteraturstudie, följt av sju intervjuer med yrkesverksamma inom IT-branschen. Därefter genomfördes en analys av empirin för att hitta likheter och skillnader i data. Studiens resultat påvisar att man bör definiera krav som är anpassade efter webbapplikationens mål och syfte. Kraven bör definieras för varje funktion i webbapplikationen och vara tydliga samt mätbara. En metod för att uppnå det är att använda SMART-kriterierna. För att säkerställa att kraven uppfylls bör prestandatester genomföras. Dessa bör automatiseras och verktyget som används ska vara anpassat för applikationen. Användare kan med fördel vara involverade i arbetet med responstid. Huruvida användbarhetstest är rätt metod går inte att säkerställa. Monitorering är ett bra komplement i arbetet med krav för responstid, men kan inte återge användarens upplevelse och ersätter inte heller användarmedverkan vid kravframtagning. / Previous research shows that response time has big impact on the user's experience online. Despite this, there are no clear methodologies for how to work with response time. With this in mind, the aim of this study was to investigate how companies should work with response time in web applications and whether one should take help from users. The study was conducted using a literature study, followed by seven interviews with active professionals in the IT industry. An empirical analysis was then performed to find similarities and differences in data. The study's results show that one should define requirements that are adapted to the goals and purpose of the web application. The requirements should be defined for each function in the web application and be clear and measurable. One method of achieving this is to use the SMART criteria. To ensure that the requirements are met, performance tests should be carried out. These should be automated, and the tool used should be adapted for the application. Users can advantageously be involved in the work with response time. Whether usability test is the right method cannot be guaranteed. Monitoring is a good complement in the work with requirements for response time but cannot reproduce the user's experience nor does it replace user involvement in the production of requirements.

Företaget Nordicstation hanterar stora datamängder åt Swedbank där datalagringen sker i relationsdatabasen Microsoft SQL Server 2012 (SQL Server). Då det finns andra databashanterare designade för stora datavolymer är det oklart om SQL Server är den optimala lösningen för situationen. Detta examensarbete har tagit fram en jämförelse med hjälp av prestandatester, beträffande exekveringstiden av databasfrågor, mellan databaserna SQL Server, Cassandra och NuoDB vid hanteringen av stora datamängder. Cassandra är en kolumnbaserad databas designad för hantering av stora datavolymer, NuoDB är en minnesdatabas som använder internminnet som lagringsutrymme och är designad för skalbarhet. Resultaten togs fram i en virtuell servermiljö med Windows Server 2012 R2 på en testplattform skriven i Java. Jämförelsen visar att SQL Server var den databas mest lämpad för gruppering, sortering och beräkningsoperationer. Däremot var Cassandra bäst i skrivoperationer och NuoDB presterade bäst i läsoperationer. Analysen av resultatet visade att mindre access till disken ger kortare exekveringstid men den skalbara lösningen, NuoDB, lider av kraftiga prestandaförluster av att endast konfigureras med en nod. Nordicstation rekommenderas att uppgradera till Microsoft SQL Server 2014, eller senare, där möjlighet finns att spara tabeller i internminnet. / The company Nordicstation handles large amounts of data for Swedbank, where data is stored using the relational database Microsoft SQL Server 2012 (SQL Server). The existence of other databases designed for handling large amounts of data, makes it unclear if SQL Server is the best solution for this situation.  This degree project describes a comparison between databases using performance testing, with regard to the execution time of database queries.  The chosen databases were SQL Server, Cassandra and NuoDB. Cassandra is a column-oriented database designed for handling large amounts of data, NuoDB is a database that uses the main memory for data storage and is designed for scalability. The performance tests were executed in a virtual server environment with Windows Server 2012 R2 using an application written in Java. SQL Server was the database most suited for grouping, sorting and arithmetic operations. Cassandra had the shortest execution time for write operations while NuoDB performed best in read operations. This degree project concludes that minimizing disk operations leads to shorter execution times but the scalable solution, NuoDB, suffer severe performance losses when configured as a single-node. Nordicstation is recommended to upgrade to Microsoft SQL Server 2014, or later, because of the possibility to save tables in main memory.

Internet of Things (IoT) är en växande teknologi som spelar en allt större roll i samhället. Den innefattar ett nätverk av internetanslutna enheter som samlar in och utbyter data. Samtidigt som IoT växer uppstår utmaningar kring hantering av stora datamängder och säkerhetsaspekter. Företaget Softhouse står inför utmaningen att välja en effektiv tidsseriedatabas för hantering av temperatur- och geopositionsdata från värmesystem i privata bostäder, där både prestanda och dataintegritet via kryptering är av stor vikt. Detta examensarbete har därför utfört en prestandajämförelse mellan AWSTimestream och InfluxDB, där olika tester har använts för att mäta exekveringstiden för inskrivning av sensordata och databasfrågor. Jämförelsen inkluderar AWS Timestream i krypterad form mot InfluxDB i dess AWS-molnversion i krypterad form, samt InfluxDB AWS i krypterad form mot InfluxDB i okrypterad form. Syftet med studien var att ge riktlinjer för valet av tidsseriedatabaser med fokus på prestanda och säkerhetsaspekter, inklusivekryptering. Studien undersökte även hur valet av rätt databas påverkar företag som Softhouse, både i termer av kvantitativa och kvalitativa fördelar, samt att ge en bedömning av kostnaderna. Resultatet visade att InfluxDB i dess AWS-molnversion generellt presterade bättre än AWS Timestream och InfluxDB i dess standardversion. Det fanns tydliga skillnader i prestanda mellan AWS Timestream och InfluxDB i dess AWS-molnversion, men inte lika tydliga skillnader i prestanda mellan InfluxDB i dess AWS-molnversion och standardversionen. Med hänsyn till både prestanda och säkerhet framstår InfluxDB i dess AWS-molnversion som det mest lämpliga alternativet. Det är emellertid av stor vikt att ta kostnadaspekten i beaktande, då AWS Timestream visar sig vara avsevärt mer kostnadseffektivt än InfluxDB. / The Internet of Things (IoT) is a growing technology that plays an increasingly significant role in society. It encompasses a network of internet-connected devices that collect and exchange data. As IoT continues to expand, challenges arise regarding the management of large volumes of data and security aspects. The company Softhouse faces the challenge of choosing an efficient time-series database for handling temperature and geoposition data from heating systems in homes, where both performance and data integrity through encryption are of great importance. Therefore, this thesis has conducted a performance comparison between AWS Timestream and InfluxDB, using various tests to measure the execution times for data ingestion of sensor data and database queries. The comparison includes AWS Timestream in encrypted form versus InfluxDB in its AWS cloud version in encrypted form, as well as InfluxDB AWS in encrypted form versus InfluxDB in unencrypted form. The aim of the study was to provide guidelines for the selection of time-series databases with a focus on performance and security aspects, including encryption. The study also explored how the choice of the right database affects companies like Softhouse, both in terms of quantitative and qualitative benefits, and provided an assessment of costs. The results showed that InfluxDB in its AWS cloud version generally outperformed AWS Timestream and InfluxDB in its standard version. There were clear performance differences between AWS Timestream and InfluxDB in its AWS cloud version, but not as pronounced differences in performance between InfluxDB in itsAWS cloud version and the standard version. Considering both performance and security, InfluxDB in its AWS cloud version appears to be the most suitable option. However, it is crucial to consider the cost aspect, as AWS Timestream proves to be significantly more cost-effective than InfluxDB.

This study has developed a method to create an, to a big extent, automated testing system for NMP (Networked Music Performance) communication over LAN and WAN to be able to benchmark the UDP streaming engine JackTrip using a client-server model. The method is not locked into using JackTrip only, it could be used to do experiments with other engines too. The study tried to answer the question if latency correlates to amount of correctly aligned audio, and to what extent the audio is correctly aligned in respect to tolerated latency (based on earlier research) when at least two musicians remote-conducting musical pieces together. There were 13 different buffer settings tested, which used no redundancy and redundancy of 2, and which were sent through 4 different LAN/WAN-scenarios. A big dataset was produced, with about 82 minutes’ worth of audio per test. To post-process the data a phase cancelling method was used to measure correctly aligned audio, while the latency was measured by counting the number of samples from the start of each audio file to the first sample that were not null or not under a certain threshold. The results showed clear correlations of buffer sizes impact of latency and amount of correctly audio sent over the network. If the buffer sizes are greater, it will produce higher latency and increase the amount of correctly aligned audio, and on the opposite side, if using less buffer, it will produce lower latencies and less correctly aligned amount of audio. The study also showed that there was very little impact of using higher redundancies, both regarding latency and amount of correctly audio. When analysing the amount of correct data when respecting the tolerated level of latency, the study showed a support for correctly aligned amount of streamed audio up to 65% when using JackTrip. / Den här studien har utvecklat en metod för att skapa ett, till stor del, automatiserat testsystem för NMP-kommunikation (Networked Music Performance) över LAN och WAN för att kunna prestandatesta den UDP-strömmande ljudmotorn JackTrip, med en klient-server-modell. Metoden är inte låst till att endast användas med JackTrip, den kan användas för att göra experiment med andra motorer också. Studien försökte svara på frågorna om latens korrelerar med mängden korrekt justerat ljud, och till hur stor del som ljudet är korrekt justerad med hänsyn till tolererbar latens (baserat på tidigare undersökning) när minst två musiker fjärrmusicerar tillsammans. Det testades 13 olika buffertinställningar, som använde ingen redundans samt med redundans på 2, och som kördes genom 4 olika LAN / WAN-scenarier. En stor datamängd producerades, med ca 82 minuters ljud per test. För att post-bearbeta data användes en fas-elimineringsmetod för att mäta mängden korrekt justerat ljud, medan latensen var uppmätt genom att räkna antalet samplingar från starten av varje ljudfil till den första samplingen som inte var innehållslös eller inte under ett specifikt tröskelvärde. Resultaten visade tydlig korrelation av buffertstorlekens påverkan av latens och mängd korrekt ljud skickat över nätverket. Om buffertstorlekarna är större kommer det att ge högre latens och öka mängden korrekt justerat ljud, och tvärtom, om mindre buffert används, kommer det att ge lägre latens och mindre rätt justerad mängd ljud. Studien visade också att det gav mycket liten effekt att använda högre redundans, både vad gällande latens och mängden korrekt ljud.  Vid analys av mängden korrekta data med hänsyn till den tolererade latensnivån visade studien ett stöd för korrekt justerat mängd av strömmat ljud upp till 65% vid användning av JackTrip.

Denna studie syftar till att beskriva prestandatest av feta klienter, ibland också kallade skrivbordsapplikationer. Studien syftar även till att kartlägga testverktyg som kan användas för att utföra prestandatest av feta klienter och att identifiera vilka egenskaper som anses vara viktiga kriterier för dessa testverktyg. Undersökningen är skapad som en fallstudie som undersökningsstrategi där fallets utgångspunkt är Trafikverkets behov men undersökning och dess resultat kan även appliceras på andra verksamheter där testarbete utförs. Både kvalitativ och kvantitativ datainsamling användes i undersökningen genom intervjuer och dokumentstudier samt enkätformulär. Då insamlat data i undersökningen är av både kvalitativ och kvantitativ form så användes också en blandning av en kvalitativ tematisk analys och kvantitativ dataanalys. En del av analysen är en utvärdering av ett testverktygsurval mot sammanställda kriterier, en kriteriebaserad utvärderingsmetod. Tillvägagångssättet för val och utvärdering av testverktyg som tillämpats genom studien är baserat på tidigare befintliga teorier som funnits genom litteraturstudier. Litteraturstudierna har även stått till grund för att definiera undersökningens centrala begrepp och bidrar till resultat genom en jämförelse med insamlat data. Resultatet från undersökningen bidrar med ett beslutsunderlag för verksamheter som står inför ett val av testverktyg för prestandatest av feta klienter och en utvärdering av dessa innan licenser införskaffas. Undersökningen bidrar även med en karakterisering av prestandatest av feta klienter. I just detta fall var de mest passande testverktygen för syftet HP LoadRunner samt två testverktyg från eggPlant i kombination (eggPlant Functional och eggPlant Performance). / The aim of this study is to describe performance testing on thick clients, sometimes also referred to as desktop applications. Another aim with this study is to map out a selection of testing tools that can be used for performance testing of thick clients and to identify what qualities that is considered to be important criteria for these testing tools. The study is based on the research strategy called case study where the case is grounded the needs from Trafikverket but the results from this study could be applied on other business organizations that works with testing. Both qualitative and quantitative data collecting methods where used in this study, in the form och interviews, document studies and questionnaires. Since the collected data in the study where in both qualitative and quantitative form the use of a mix between a qualitative thematical data analysis and a quantitative data analysis had to be done. A part of the analysis was an evaluation on a selection of testing tools towards a compiled list of criteria, as an evaluation method based on criteria. The course of action for choosing and evaluation a testing tool that has been applied throughout the study is based on preexisting theories that has been found through reviews of literature. The reviews of literature have also been the ground for defining the central concepts of the study and contributes to the result by comparing what’s been found in literature to the collected data. The result of the study contributes with a basis for decision for companies and organizations that is in the process of getting a testing tool for performance testing thick clients och how to evaluate these before obtaining the testing tool licenses. The study also contributes with a characterization of performance testing thick clients. In this particular case, the most suitable testing tools came to be HP LoadRunner and also two testing tools from eggPlant combined (eggPlant Functional and eggPlant Performance).