Hantering av larm från nätverksnoder är i dagsläget en process som kräver att nätverkstekniker besöker flera olika källor av information för att dra en slutsats över vad orsaken till larmet kan vara. Genom att besöka flera olika källor av information kan det vara komplicerat att få en överblick över problemet. Studien utförs på uppdrag av Trafikverket för att underlätta arbetet för Trafikverkets nätverkstekniker på avdelningen network operations center (NOC). En webbapplikation har utvecklats för att sammanställa de vanligaste källorna som nätverkstekniker besöker. Webbapplikationen amalgamerar och presenterar information på ett sätt som bör underlätta felsökningsprocessen för nätverkstekniker. Webbapplikationen indikerar de vanligaste felorsakerna, beroende på vilken typ av larm som hanteras. Valmöjligheter vid utveckling av en webbapplikation kan göra det svårt för utvecklare att välja mjukvara. Även om mjukvara delvis sorteras ut beroende på i vilket syfte som utvecklingen sker finns fortfarande en stor mängd alternativ. Denna studie har förtydligat och bevisat att mjukvaran NodeJS, PostgreSQL och PostGIS fungerar enhetligt och är att föredra för en webbapplikation med spatiala funktioner. För att utvärdera webbapplikationen genomfördes ett användartest där nio personer, 47% av personalen på Trafikverket NOC deltog. Användartestet visar positiva resultat gällande hur väl webbapplikationen fyllde sitt syfte med att indikera möjliga orsaker för nätverkslarm samt deltagarnas upplevelse med webbapplikationen. I användartestet anser 100% av deltagarna att webbapplikationen skulle spara dem tid och de tre populäraste funktionerna var polygoner för att visa elnätägare, realtids väderdata samt en sammanställning av interna data på samma ställe. / Handling of alarms on network nodes is a process that requires network technicians to visit several sources of information before they can draw a conclusion on the reason behind the alarm. By visiting several different sources of information, it may be difficult to establish a good overview of the problem. This study is made on request by the Swedish traffic authority Trafikverket to ease the workload of the co-workers at the department network operations center (NOC). A web application has been developed to amalgamate the most common sources a network technician visits. The web application presents the amalgamated information in a way that eases the troubleshooting process for the network technicians. The web application also indicates what the most common reasons are, depending on which kind of alarm that is being handled. Due to the large availability of different software it can be difficult for a developer to choose a suitable software. Even if some are excluded based on the purpose of the development there are still many choices. This study emphasizes that the software NodeJS, PostgreSQL and PostGIS works well together and is a suitable choice when creating a web application that needs to use spatial functions. To evaluate the web application a user test was conducted were nine participants, 47% of the personnel at Trafikverket NOC participated. The result shows positive results in both how well the web application filled its purpose by indicating possible reasons for a network alarm as well as the participants experiences with the web application. In the user test 100% of the participants claim that the web application would save them time and the three most popular features were polygons of electricity distributors, real time weather data and an amalgamation of internal data in one place.

Migration av data innebär att data flyttas från en databas till en annan. Denna åtgärd kan företag behöva av olika skäl, till exempel för att ändra språk eller förnya befintlig databas. Något som diskuteras är hur denna process ska ske och hur data migreras på bästa smidigaste sätt. Ett av IT företagen som var i behov av svaren är XLENT Sundsvall. XLENT har en webbshop där gränssnittet är föråldrat, samt i behov av en bättre serverlösning ur ett förvaltningsperspektiv. Den här studien syftar till att se över möjligheterna att flytta över den befintliga hemsidan till en modern e-handelslösning. Titta på vilket bästa sätt är att migrera datan till en ny databas som är mer lämplig för hemsidan. De metoderna som ska jämföras är en export-import möjlighet och Extract Transform Load ( ETL) verktyg. Export-import metoden visade sig vara den mest lämpade processen för en databas med våra egenskaper, och en migration med valda processen genomfördes. Till migrationsprocessen hör även städning av data. Ett viktigt steg då databasen bestod av redundant data. En jämförelse mellan den nya och gamla databasen visade att städningen vara en lyckad process då den redundanta datan reducerades med 24 procent. Export-import processen valdes då metoden passade bäst för databas egenskaperna. Då databasen hade varit mycket större eller vara skrivet i ett annat SQL språk så vore metoden inte helt optimalt längre. Då skulle ETL verktyget vara med önskvärt. Vid fortsatt arbete så skulle det vara intressant att göra en mer teoretisk jämförelse. Testa att migrera på de olika sätten, med databaser med olika egenskaper för att få en mer övergripande blick av vilken som passar bäst i olika fall. / Data migration means the transfer of data from one database to another. This is something that more and more companies need to do. for various reasons, for example to change the language or renew the existing database. Something that is discussed is how this process should take place and how data is migrated in the best and most flexible way. One of the IT companies that was in need of the answers is XLENT Sundsvall. XLENT has an online shop where the interface is outdated, and in need of a better server solution from a management perspective. This study aims to review the possibilities of moving over the existing website to a more modern solution. Look at the best way to migrate the data to a new database that is more suitable for the website. The methods to be compared are an export-import method and Extract Transform Load (ETL) tool. The export-import method proved to be the most suitable process for a database with our properties, and a migration with the selected process was performed. The migration process also includes cleaning of data. An important step as the database consisted of redundant data. A comparison between the new and old databases showed that cleaning was a successful process as the redundant data was reduced by 24 percent. The export-import process was chosen as the method best suited the characteristics of the existing database. With a database being much larger or being written in another SQL language, it might not be the most optimal solution anymore. Then the the ETL tool would be better. With continued work, it would be interesting to make more than a theoretical comparison. Try migrating with many different databases with different properties to get a more comprehensive look of which one is best suited in different cases.

To meet the demands of 5G and what comes after, telecommunications companies will need to replace their old embedded systems with new technology. One such solution could be to develop cloud-native applications that offer many benefits but are less reliable than embedded systems. Having the different units in the 5G system store their state, or their operational context, in cloud-based databases could reduce downtime in case of failing processes, but various database systems have their advantages and disadvantages. Thus, the choice of implementation must be carefully considered.   This study primarily aims to create a simulator that can measure latency, or the time it takes to write or read dummy data to or from one of two different kinds of databases. Its secondary aim is to produce use cases that mimic situations that a database for state data would need to handle and to collect measurements from them with the help of the simulator.   The simulator was implemented using C++17 and contains a simulator object and separate database clients. The actors representing the units interacting with a 5G network were created by the clients and their state data was stored in either Redis or PostgreSQL databases. Various use cases were designed with the instruction from Ericsson to simulate real-life scenarios and to measure latencies. Quantitative data analysis was performed on the collected data to compare the performances of Redis and PostgreSQL databases in the different use cases.   The study found that Redis on average worked the fastest and that its latency was largely the same regardless of data sizes, while PostgreSQL's latencies, and thus the differences between the databases, varied more depending on the scenario.   The results of the study show that Redis is the one of the two databases that operates more consistently and predictably, which may partly be explained by the fact it is mainly based in the RAM, while PostgreSQL is mainly disk-based.   Future work could involve testing the databases under higher workloads, exploring what would be the impact of running simulations in environments with reduced RAM and not letting Redis use it to its full advantage, and maybe analyzing more latency figures by creating new use cases and running them. Future work can also include an investigation of the effect of Redis database crashes. Moreover, the simulator implementation allows for changing to other types of databases.

В данной работе проведено исследование для создания программного обеспечения управления контролем качества, позволяющего автоматизировать процесс оценки агентов, а также постановку задач менеджерам по контролю качества. Предметом исследования является разработка программного обеспечения, которое обеспечивает автоматизацию выбора взаимодействия агента и клиента, создание оценочных карт, отчетов о качестве, управление персоналом и многое другое. / In this work, a study was carried out to create a quality control management software that allows you to automate the process of evaluating agents, as well as setting tasks for quality control managers. The subject of the research is the development of software that automates the choice of interaction between the agent and the client, the creation of scorecards, quality reports, personnel management, and much more.

Submitted by Neusa Fagundes (neusa.fagundes@unioeste.br) on 2018-02-09T16:58:35Z No. of bitstreams: 2 Jefferson_Silva2017.pdf: 21962500 bytes, checksum: b5f3e1638dea54ab903a20e7e41671d6 (MD5) license_rdf: 0 bytes, checksum: d41d8cd98f00b204e9800998ecf8427e (MD5) / Made available in DSpace on 2018-02-09T16:58:35Z (GMT). No. of bitstreams: 2 Jefferson_Silva2017.pdf: 21962500 bytes, checksum: b5f3e1638dea54ab903a20e7e41671d6 (MD5) license_rdf: 0 bytes, checksum: d41d8cd98f00b204e9800998ecf8427e (MD5) Previous issue date: 2017-07-10 / Brazil is the fourth largest swine producer and exporter in world, with swine farming being very representative in the national scenario. This production, however, implies generation of waste and this needs to be mitigated. One of the alternatives to reduce the impact caused by pig waste is the application of anaerobic biodigestion treatment, obtaining biogas and digestate as by-products. Digestate can be used as biofertilizer, generating a new product. In this context, this work proposes to define a geographic database from different sources about the national production of swine and to estimate, supported by calculation methodology defined in activities of the BiogasFert Network, the respective production of waste and biogas. These results were provided in an web system using GeoServer map server. In addition, a methodology was defined in this work to identify areas of permanent preservation in top of hills, based on the Brazilian new forest code published since 2012, and in classes of declivity unfit for fertilizer inputs (regions with slopes greater than 45%). As result, a total of 60,879,431 km² (0,72%) of areas considered inapt for the application of fertilizers in the national territory were identified. Another objective of this work was to highlight the use of free GIS software and its processing power, since the metrics applied here were elaborated using exclusively open source software. / O Brasil é o quarto maior produtor e exportador de carne suína mundial, tendo a suinocultura uma grande representatividade no cenário agropecuário nacional. Essa produção, contudo, implica na geração de resíduos, que necessitam ser mitigados. Uma das alternativas para reduzir o impacto causado por dejetos de suínos é a aplicação de um tratamento de biodigestão anaeróbia, obtendo-se como subproduto o biogás e o digestato, o qual pode ser utilizado como biofertilizante, tornando-se não só uma forma de tratamento como também de geração de novos produtos. Neste contexto, este trabalho propôs definir uma base de dados geográfica a partir da integração de fontes distintas acerca da produção nacional de suínos e estimar, apoiado por metodologia de cálculo definida em atividades da Rede BiogásFert, a respectiva produção de dejetos e biogás. Tais resultados foram aportados em sistema web via servidor de mapas GeoServer. Além disso, define-se neste trabalho metodologia para identificar áreas de preservação permanente em topo de morro, a partir do novo código florestal veiculado desde 2012, bem como as classes de declividade inaptas ao aporte de fertilizantes (regiões com declividade superior a 45%). Como resultado, foi identificado um total de 60.879,431 km² (0,72%) de áreas consideradas inaptas à aplicação de fertilizantes no território nacional. Um outro objetivo deste trabalho foi o de evidenciar o uso de softwares SIG livres e o seu poder de processamento, visto que as metologias aqui aplicadas foram elaboradas com uso exclusivo de softwares open source.

Open-plan offices are widely used by companies today. There is also secluded rooms in the form of group and meeting rooms, although these are often limited in numbers. Not being able to book these rooms when needed leads to problems planning for example customer meetings. Which is also a problem for students in the school world. Today there is a number of studie rooms at Royal Institute of Technology in Kista, school for information and communication technology, where none of them are bookable. Earlier there where bookable studie rooms in the library and in other parts of the school, but such a system is no longer available because of the new facilities. The result of this is that students at the school are not able to plan their studies in an effective way because they do not know if they have a suitable place to study at between lectures or exercises. Because of this there is a need for a system that can provide students the opportunity to book a studie room. The thesis documents the development of a booking system prototype for study rooms. The prototype have been developed with HTML, PHP, PostgreSQL, JavaScript och Ajax. The thesis contains a literature studie of the current booking systems available. An analysis and an evaluation of these systems have been used as a foundation for the development. Interviews of students have been used as a data collection method. Summarizing the students opinion gave an indication of what is required by the system in terms of functionality and the user interface. The project also describes the working methods that have been used. The project resulted in a prototype for the booking system, where users can see all the available study rooms, make a booking, confirm the booking and remove their bookings. The prototype uses a database that is fully modified. The result from an evaluation of the prototype indicates what aspects that needs to be improved in future work. / I dagsläget är öppna kontorslandskap vanligt förekommande hos företag. Det finns avskilda platser i form av grupp- och mötesrum, dessa är dock allt som oftast begränsade till antal. Att inte kunna boka dessa rum vid behov leder till svårigheter att planera till exempel kundmöten. Problemet att kunna boka ett avskilt rum vid behov finns även inom skolvärlden. På Kungliga Tekniska Högskolan (KTH) i Kista, skolan för information och kommuniktionsteknik, finns det ett antal grupprum där inga av dem är bokningsbara. Det har tidigare funnits bokningsbara grupprum i biblioteket och i andra delar av skolan men idag saknas ett sådant system på grund av nya lokaler. Detta resulterar i att studenter inte kan planera sina studier på ett effektivt sätt då de inte vet om de har en lämplig studieplats mellan föreläsningar. Därför finns det ett stort behov av ett system där studenterna kan boka grupprummen. Uppsatsen dokumenterar utvecklingen av en prototyp ett bokningssystem för grupprum som gjorts med hjälp av HTML, PHP, PostgreSQL, JavaScript och Ajax. Arbetet beskriver även de arbetsmetoder som använts under arbetets gång. Uppsatsen inkluderar en undersökning av bokningssystem som finns idag. Som datainsamlingsmetod har även intervjuer av studenter använts. Utvärderingen av bokningssystemen som finns idag tillsammans med resultatet av intervjuerna gav en indikation om vad som krävs av bokningssystemets användargränssnitt och funktionalitet. Arbetet resulterade i en prototyp av bokningssystemet där användaren kan se vilka grupprum som är lediga, boka grupprum, kvittera bokningar och ta bort bokningar. Prototypen använder en databas som modellerats och implementerats. En evaluering av prototypen resulterade i vad som kan förbättras i ett framtida arbete.

Databases are all around us, and ensuring their efficiency is of great importance. Database optimisation has many parts and many methods, two of these parts are database tuning and database optimisation. These can then further be split into methods such as indexing. These indexing techniques have been studied and compared between Database Management Systems (DBMSs) to see how much they can improve the execution time for queries. And many guides have been written on how to implement query optimisation and indexes. In this thesis, the question "How does indexing and query optimisation affect response time in PostgreSQL?" is posed, and was answered by investigating these previous studies and theory to find different optimisation techniques and compare them to each other. The purpose of this research was to provide more information about how optimisation techniques can be implemented and map out when what method should be used. This was partly done to provide learning material for students, but also people who are starting to learn PostgreSQL. This was done through a literature study, and an experiment performed on a database with different table sizes to see how the optimisation scales to larger systems. What was found was that there are many use cases to optimisation that mainly depend on the query performed and the type of data. From both the literature study and the experiment, the main take-away points are that indexes can vastly improve performance, but if used incorrectly can also slow it. The main use cases for indexes are for short queries and also for queries using spatio-temporal data - although spatio-temporal data should be researched more. Using the DBMS optimiser did not show any difference in execution time for queries, while correctly implemented query tuning techniques also vastly improved execution time. The main use cases for query tuning are for long queries and nested queries. Although, most systems benefit from some sort of query tuning, as it does not have to cost much in terms of memory or CPU cycles, in comparison to how indexes add additional overhead and need some memory. Implementing proper optimisation techniques could improve both costs, and help with environmental sustainability by more effectively utilising resources. / Databaser finns överallt omkring oss, och att ha effektiva databaser är mycket viktigt. Databasoptimering har många olika delar, varav två av dem är databasjustering och SQL optimering. Dessa två delar kan även delas upp i flera metoder, så som indexering. Indexeringsmetoder har studerats tidigare, och även jämförts mellan DBMS (Database Management System), för att se hur mycket ett index kan förbättra prestanda. Det har även skrivits många böcker om hur man kan implementera index och SQL optimering. I denna kandidatuppsats ställs frågan "Hur påverkar indexering och SQL optimering prestanda i PostgreSQL?". Detta besvaras genom att undersöka tidigare experiment och böcker, för att hitta olika optimeringstekniker och jämföra dem med varandra. Syftet med detta arbete var att implementera och kartlägga var och när dessa metoder kan användas, för att hjälpa studenter och folk som vill lära sig om PostgreSQL. Detta gjordes genom att utföra en litteraturstudie och ett experiment på en databas med olika tabell storlekar, för att kunna se hur dessa metoder skalas till större system. Resultatet visar att det finns många olika användingsområden för optimering, som beror på SQL-frågor och datatypen i databasen. Från både litteraturstudien och experimentet visade resultatet att indexering kan förbättra prestanda till olika grader, i vissa fall väldigt mycket. Men om de implementeras fel kan prestandan bli värre. De huvudsakliga användingsområdena för indexering är för korta SQL-frågor och för databaser som använder tid- och rum-data - dock bör tid- och rum-data undersökas mer. Att använda databassystemets optimerare visade ingen förbättring eller försämring, medan en korrekt omskrivning av en SQL fråga kunde förbättra prestandan mycket. The huvudsakliga användingsområdet för omskriving av SQL-frågor är för långa SQL-frågor och för nestlade SQL-frågor. Dock så kan många system ha nytta av att skriva om SQL-frågor för prestanda, eftersom att det kan kosta väldigt lite när det kommer till minne och CPU. Till skillnad från indexering som behöver mer minne och skapar så-kallad överhead". Att implementera optimeringstekniker kan förbättra både driftkostnad och hjälpa med hållbarhetsutveckling, genom att mer effektivt använda resuser.

Time series data refers to data recorded over time, often periodically, and can rapidly accumulate into vast quantities. To effectively present, analyse, or conduct research on such data it must be stored in an accessible manner. For convenient storage, database management systems (DBMSs) are employed. There are numerous types of such systems, each with their own advantages and disadvantages, making different trade-offs between desired qualities. In this study we conduct a performance comparison between two contrasting DBMSs for time series data. The first system evaluated is PostgreSQL, a popular relational DBMS, equipped with the time series-specific extension TimescaleDB. The second comparand is MongoDB, one of the most well-known and widely used NoSQL systems, with out-of-the-box time series tailoring. We address the question of which out of these DBMSs is better suited for time series data by comparing their query execution times. This involves setting up two databases populated with sample time series data — in our case, publicly available weather data from the Swedish Meteorological and Hydrological Institute. Subsequently, a set of trial queries designed to mimic real-world use cases are executed against each database, while measuring their runtimes. The benchmark results are compared and analysed query-by-query, to identify relative performance differences. Our study finds considerable variation in the relative performance of the two systems, with PostgreSQL outperforming MongoDB in some queries (by up to more than two orders of magnitude) and MongoDB resulting in faster execution in others (by a factor of over 30 in one case). Based on these findings, we conclude that certain queries, and their corresponding real-world use cases, may be better suited for one of the two DBMSs due to the alignment between query structure and the strengths of that system. We further explore other possible explanations for our results, elaborating on factors impacting the efficiency with which each DBMS can execute the provided queries, and consider potential improvements. / I takt med att mängden data världen över växer exponentiellt, ökar också behovet av effektiva lagringsmetoder. En ofta förekommande typ av data är tidsseriedata, där varje värde är associerat med en tidpunkt. Det kan till exempel vara något som mäts en gång om dagen, en gång i timmen, eller med någon annan periodicitet. Ett exempel på sådan data är klimat- och väderdata. Sveriges meteorologiska och hydrologiska institut samlar varje minut in mätvärden från tusentals mätstationer runt om i landet, så som lufttemperatur, vindhastighet och nederbördsmängd. Det leder snabbt till oerhört stora datamängder, som måste lagras för att effektivt kunna analyseras, förmedlas vidare, och bevaras för eftervärlden. Sådan lagring sker i databaser. Det finns många olika typer av databaser, där de vanligaste är relationella databaser och så kallande NoSQL-databaser. I den här uppsatsen undersöker vi två olika databashanteringssystem, och deras lämplighet för lagring av tidsseriedata. Specifikt jämför vi prestandan för det relationella databashanteringssystemet PostgreSQL, utökat med tillägget TimescaleDB som optimerar systemet för användande med tidsseriedata, och NoSQL-systemet MongoDB som har inbyggd tidsserieanpassning. Vi utför jämförelsen genom att implementera två databasinstanser, en per komparand, fyllda med SMHI:s väderdata och därefter mäta exekveringstiderna för ett antal utvalda uppgifter som relaterar till behandling av tidsseriedata. Studien konstaterar att inget av systemen genomgående överträffar det andra, utan det varierar beroende på uppgift. Resultaten indikerar att TimescaleDB är bättre på komplexa uppgifter och uppgifter som involverar att plocka ut all data inom ett visst tidsintervall, emedan MongoDB presterar bättre när endast data från en delmängd av mätstationerna efterfrågas.

Det finns en stor mängd databaser som används inom många olika sorters användningsområden. Bland dessa finns det sådana som har funktion för att behandla spatiala data. Problemet som detta medför är att välja en databas som kan hantera en viss tänkt typ av spatiala data med bäst prestanda. Denna rapport presenterar en utredning för detta utifrån ett dataset som erhållits från Norconsult Digital. Bland de databaser som valts finns tre SQL databaser (PostgreSQL, MySQL och SQLite) och en NoSQL databas (MongoDB). Dessa databaser genomgick fem likvärdiga operationer/tester som resulterade i att PostgreSQL med dess GiST/SP-GiST index och MongoDB presterade på en nivå långt över resterande databaser som testades. Utifrån detta arbete kan det konstateras att fler utförliga prestandatester bör utföras, där större och mer komplexa dataset, samt fler alternativ till databaser och spatiala index bör finnas med. Detta för att ge en bättre bild över vilka databaser, med stöd för spatiala data, som presterar bättre. / There are a large number of databases that are used in many different areas. Among these, some have a function for processing spatial data. The problem that this entails is the choice of a database that can handle a certain type of spatial data with the best possible performance. This report presents an analysis of this based on a dataset obtained from Norconsult Digital. Among the chosen databases are three SQL databases (PostgreSQL, MySQL and SQLite) and one NoSQL database (MongoDB). These databases underwent five identical operations/tests resulting in PostgreSQL with its GiST/SP-GiST index and MongoDB performing at a level well above the rest of the databases tested. Based on this work, it can be concluded that more detailed performance tests should be carried out, where larger and more complex datasets, as well as more alternatives to databases and spatial indexes, should be included. This is to give a better picture of which databases, with support for spatial data, perform better.

This report investigates the viability of bitwise operations on non-scarce attribute based data structures in PostgreSQL. For applications where computation can’t be avoided, it most probably can be optimized. In an attempt of bringing the computation closer to hardware and the underlying data, operations directly on the database system are explored, taking inspiration from the research field of comparative genomics. With the case-study of an online job platform in mind, where possible matchings between candidate and job descriptions are calculated by a matching engine, a binary encoding is proposed and the computational components identified. The ultimate goal was to evaluate the scalability of the bitwise strategy with respect to the current matching engine. Through an iterative approach, this report conducts quantitative experiments on the presented components. Most notably, an implementation of the population count in the form of a C extension was introduced. It was found, that even for large sequence lengths, the operation is highly efficient. Among the chosen algorithms Lookup Table, Hamming Weight, Intrinsic functions and Unrolled Inline Assembly, the 64 bit intrinsic function displayed the best performance. Benchmarks determined, that the proposed bitwise approach is an excellent strategy for the outlined use-case. Despite the tradeoff of additional complexity in the encoding and decoding of data, the speedup is so significant, that the targeted user base of 100000 can easily be managed and allows for the deprecation of caching mechanisms. / Denna rapport undersöker gångbarheten för bitwise-operationer på icke-knappa attributbaserade datastrukturer i PostgreSQL. För applikationer där komputationen inte kan undvikas, kan den högst troligen optimeras. I ett försök att föra beräkningen närmare hårdvaran och den underliggande datan, undersöks operationer direkt på databasen med inspiration från forskningsområdet inom komparativ genomik. Med fallstudien av en online rekryteringsplattform i åtanke, där möjliga matchningar mellan kandidatoch arbetsbeskrivningar beräknas av en matchningsmotor, föreslås en binär kodning och komputationskomponenterna identifieras. Det slutgiltiga målet var att utvärdera skalbarheten hos bitwise-strategin med avseende till den aktuella matchningsmotorn. Genom ett iterativ tillvägagångssätt utför denna rapport kvantitativa experiment på de presenterade komponenterna. Framför allt infördes en implementering av population count i form av ett C-tillägg i databasen. Det visade sig att även för större sekvenslängder är operationen mycket effektiv. Bland de utvalda algoritmerna Lookup Table, Hamming Weight, Intrinsic-funktioner och Unrolled Inline Assembly, visade 64-bitars Intrisicfunktionen den bästa prestandan. Experimenten fastställde att det föreslagna bitwisetillvägagångssättet är en utmärkt strategi för den valda fallstudien. Trots avvägningen med ytterligare komplexitet vid kodning och avkodning av data är hastigheten så signifikant att ett användarantal på 100000 enkelt kan hanteras och möjliggör uteslutning av cache-mekanismer.