| dc.description.abstract | Qs er en eksisterende webapplikasjon for å godkjenne øvinger/gi hjelp til studenter ved NTNU. Dette er et produkt som har blitt utviklet i samarbeid med 3D Motion Technologies. 3D Motion Technologies har et ønske om å kommersialisere sitt produkt, og det må derfor være skalerbart. Per i dag er brukergruppen av en størrelse som systemet håndterer greit, men hva skjer med veldig store klasser med mange elever? Stresstesting av dagens system har vist at systemet lider av begrensninger av ytelse ved store grupper av studenter. Det mistenkes at dette skyldes det relativt gamle rammeverket som har blitt brukt som er AngularJS. Videre bruker dagens system Node.js med Express.js som tjener. For å sikre skalerbarhet har systemet blitt reimplementert både på backend og på frontend. Backend har nå blitt byttet ut med en server skrevet i Java som bruker rammeverket Jersey, og som kjører på Tomcat 9. Frontend har blitt byttet ut med React.
Vår gruppe har under bachelorperioden prøvd å besvare problemstillingen “Vil en erstatning av teknologier føre til et mer effektivt system?”. Med effektivitet menes det at det skal kunne behandles flere forespørsler om gangen og i tillegg prøve å tette sikkerhetshull, både kjente og de som vi har støtt på underveis.
For å svare på dette har vi utført ytelsestester på systemet og sammenlignet med det gamle. Underveis har vi også måttet velge hvilke teknologier som skulle bli brukt i den nye implementasjonen. Disse valgene har blitt gjort på grunnlag av informasjonssøk og ytelsestester av teknologier. Vi har satt opp tre tester: Vi har testet et scenario for de tre mest populære rammeverkene for frontendutvikling: React, Angular og Vue. Testscenarioet er basert på hvor dagens system opplever ytelsesproblemer. Vi har også sammenlignet behandlingstiden av forespørsler for de to mest populære rammeverkene for REST-services i Java, og vi har gjort en sammenlikning av behandlingstid for det den gamle backenden kontra den nye.
Fra resultatene av den første testen av frontend-rammeverk kom React best ut. Det var dog veldig lite som skilte mellom rammeverkene, men dette bidrar til å forsterke valget av å bruke React som rammeverk, siden vår samarbeidsgruppe 067b valgte å bruke React i sin frontend. Når det kommer til sammenlikning av REST-service rammeverk for Java kom Jersey ut på topp og ga oss grunnlaget for valget i backendutviklingen. I den siste testen hvor vi prøvde å besvare problemstillingen for oppgaven, ble behandlingstiden av 1000 forespørsler med relativt stor nyttelast sammenlignet mellom den gamle og den nye serverløsningen. Forsøket ble gjort både sekvensielt og ved å ta i bruk flere samtidige tråder. Resultatet viste at vår backend var 4 ganger så kjapp som den gamle backenden når den fikk ta i bruk sine multithread-egenskaper, mens den gamle backenden brukte ¼ av tiden vår brukte per forespørsel. Dette tyder på at systemet kan bli enda kjappere om vi får kuttet ned behandlingstiden per forespørsel.
Frontenden som er implementert i React av gruppe 067b, har ikke hatt mulighet til å bli brukertestet pga. virusutbrudd under bachelorperioden. Dette hadde vært ønskelig å gjennomføre for å teste både front- og backend sammen i en reell setting. Brukertester er uvurderlige i den form av at de ofte avdekker interaksjon utviklerne selv ikke har mulighet til å oppdage. | |
| dc.description.abstract | Qs is an already existing web application used for approving exercises/providing help to students attending NTNU. This is a product that has been developed in cooperation with 3D Motion Technologies. 3D Motion Technologies sees a commercial application for this product, and therefore wants to make the product scalable. The current iteration of the system can handle the current size of its user group, but what happens if this size were to increase greatly? Performance tests of the current iteration of the system has revealed that the systems performance drops when used by a large group of students. The suspected culprit is the framework AngularJS that was used for developing the front end. This is a relatively old framework that is destined for Long Term Support, which means it will not be updated. In addition to the chosen framework, the backend was implemented with a Node JS with Express server, which has not been implemented with scalability in mind. To ensure the systems scalability, the systems back- and frontend has been reimplemented. The backend has been reimplemented in Java with the framework Jersey and runs on top of a Tomcat 9 server. The frontend has been reimplemented in React.
With this thesis, our group has tried to answer the question: “Will replacing technologies lead to a more effective system?”. In the question we tried to answer, effective has been synonymous with faster and more secure. This means we have tried to cut down time used on requests and tried to fix security flaws that were already known to the group and flaws we have discovered while developing the system.
To answer this question, we have performed performance tests and compared our version of the system with the old version. When choosing new technologies to use, we have researched the potential choices, and performed tests to put them up against each other to find the best suited candidate. Early in the project period, it was planned that our group also would be reimplementing the front end of the system. This made it necessary to research suitable frameworks to use and we performed a performance test on the three biggest frameworks for frontend development, React, Angular and Vue. In this test we have recreated a scenario in which the current version of the system performs poorly. We also performed a test to compare the most popular frameworks for backend development in Java. This was a simple test that compared the time it took for each framework to respond to a request.
When testing the frameworks for frontend development, React performed the best although it was very close between all the frameworks. The result was remarkably close, but it still is a metric that defends the choice to use React as a framework. The result of the second test made the decision for the group to use Java Jersey instead of Spring. In the last test where we compared our system with the old iteration, we did two tests: We tested the response time for when we sent 1000 sequential requests to the different backends and we did the same tests but with 1000 concurrent requests. The tests revealed two interesting things: The old backend spends ¼ of the time our backend uses per request, but our backend has multithreading capabilities, so it uses ¼ of the total time the old backend uses when receiving concurrent requests. This implies that although our backend is faster in a more realistic setting, there is still room for improvement.
The frontend that has been implemented in React by group 067B, has not been user tested due to the covid-19 pandemic, which rendered it impossible to perform these tests. User tests on a system is priceless and will often reveal bugs the developers will not be able to discover themselves. | en |