PRESTANDA ANALYS AV ORM- RAMVERK
En jämförelsestudie mellan Doctrine och Eloquent
PERFORMANCE ANALYSIS OF ORM FRAMEWORKS
A comparative study between Doctrine and Eloquent
Examensarbete inom huvudområdet Informationsteknologi Grundnivå 30 högskolepoäng
Vårtermin 2020 Roberth Evaldsson
Handledare: András Márki Examinator: Henrik Gustavsson
Sammanfattning
Allt eftersom webbapplikationer blir mer komplexa och svårare att underhålla samt behöver kopplas med databaser utvecklas MVC-ramverk. En objektrelationell impedansmatchningen uppstår när relationell data behöver uttryckas som objekt inom en applikation, lösningen på problemet är framtagandet av ORM-ramverk. Det finns flertalet av ORM-ramverk att välja mellan, vilket gör det svårt för utvecklare att välja då man måste ta hänsyn till aspekter såsom användbarhet och prestanda.
Studien genomför ett tekniskt experiment där ORM-ramverk jämförs med avseende på prestandan i form av exekveringstid av grundläggande databasoperationer samt dess minnesanvändning.
Ramverken som jämförs väljs ut utifrån ett antal kriterier och de ramverk som möter dem är Eloquent och Doctrine. Resultatet av experimentet indikerar på att Doctrine presterar bättre i förhållande till exekveringstid och Eloquent i förhållande till minnesanvändning.
Mätningarna visar även hur prestandan på ramverken förhåller sig till varandra när datamängden ökas.
Nyckelord: MVC, ORM, Prestanda, Eloquent, Doctrine
Innehållsförteckning
1 Introduktion ... 1
2 Bakgrund ... 2
2.1 PHP ... 2
2.1.1 Composer ... 2
2.2 Ramverk ... 2
2.3 Designmönster ... 3
2.4 MVC ... 3
2.5 ORM ... 5
2.6 CRUD ... 6
2.7 Postman ... 6
3 Problemformulering ... 7
3.1 Syfte och Frågeställningar ... 7
3.2 Hypotes ... 7
3.3 Delmål ... 8
4 Metod ... 9
4.1 Alternativa metoder ... 9
4.2 Relaterad forskning ... 9
4.3 Tillvägagångssätt ... 10
4.4 Etik ... 11
5 Genomförande ... 13
5.1 Litteratursökning ... 13
5.1.1 Sökstrategi ... 13
5.1.2 Upphittad Litteratur ... 13
5.1.3 Sökresultat ... 14
5.1.4 Urval av ramverk ... 14
5.2 Utveckling av webbapplikation med Laravel ... 16
5.3 Utveckling av webbapplikation med Symfony ... 17
5.4 Progression... 17
5.5 Pilotstudie ... 18
5.5.1 Tillvägagångssätt ... 18
5.5.2 Resultat för skapandet av en resurs ... 19
5.5.3 Resultat för inläsning av enskild resurs... 21
5.5.4 Resultat för uppdatering av resurs ... 23
5.5.5 Resultat för borttagning av en resurs ... 25
5.5.6 Resultat för inläsning av flera resurser ... 27
6 Utvärdering... 28
6.1 Tillvägagångssätt ... 28
6.2 Analys ... 29
6.2.1 Skapandet av resurs ... 29
6.2.2 Hämtning av enskild resurs ... 30
6.2.3 Uppdateringen av resurs ... 31
6.2.4 Borttagning av resurs ... 32
6.2.5 Hur förhåller sig ramverken till varandra? ... 33
6.3 Slutsatser ... 33
7 Avslutande diskussion ... 35
7.1 Sammanfattning ... 35
7.2 Diskussion ... 35
7.2.1 Etik ... 35
7.2.2 Relaterade Arbeten ... 36
7.2.3 Samhällsnytta & Risker ... 37
7.3 Framtida arbete ... 37
Referenser ... 39
1
1 Introduktion
Komplexa webbapplikationer ökar behovet att kunna återanvända funktionalitet vilket kan lösas genom ramverk som möjliggör återanvändning av programkod (Lancor & Katha, 2013;
Salas-Zárate et al., 2015). Utveckling med ramverk ger flera fördelar. Ramverk minskar utvecklingstiden då funktioner som normalt tar hundratals rader kod oftast kan skrivas med hjälp utav ett ramverks inbyggda funktioner (Prokofyeva & Boltunova, 2016).
Webbapplikationer som använder sig utav flera teknologier minskar underhållbarheten på programkoden (Pop & Altar, 2014). Designmönster föreslås som en lösning på underhållbarheten.
Designmönster är återanvändbara och upprepningsbara lösningar som löser liknande designproblem inom utvecklingsprocessen (Thung et al., 2010) (Garzotto et al., 1999).
Utvecklingsmässigt ökar designmönster underhållbarheten av en applikation medans användarmässigt förbättrats användbarheten av en webbapplikation (Thung et al., 2010).
Model-view-controller (MVC) är ett vanligt designmönster att använda vid utvecklandet av interaktiva system (Riehle, 1997; Leff & Rayfield, 2001).
MVC möjliggör en tydlig separation av komponenter för gränssnittet. Huvudidén ligger i att separera användargränssnittet från den underliggande data som representerar gränssnittet (Leff & Rayfield, 2001). MVC separerar applikationsdomänen (Modellen) från det grafiska gränssnittet (Vyn) och användarinteraktionen (Kontrollern) (Syromiatnikov & Weyns, 2014).
Ramverk byggda på MVC integreras med ett databashanteringssystem och object-relational mapping föreslås som en lösning (Pop & Altar, 2014).
Object-relational mapping (ORM) möjliggör för objekt-orienterade system att lagra data i en databas på ett säkert sätt (O’Neil, 2008). ORM-ramverk används för att korrelera data från ett relationellt till ett objektorienterat system. Korrelationen behövs för att motverka problemet med den objekt-relationella impedansmatchinigen som uppstår när relationell strukturerad data ska uttryckas som objekt i en applikation. Eftersom flertalet av ORM-ramverk existerar kvarstår frågan vilka av ORM-ramverken är lämpligast att använda sig utav.
Undersökningsmetoden som genomförs är ett tekniskt inriktat experiment där två ORM- ramverk jämförs prestandamässigt i form av exekveringstid vid grundläggande databasoperationer och dess minnesanvändning. ORM-ramverken Eloquent och Doctrine som undersöks togs fram genom uppsatta användbarhetskriterier och funktionsekvivalenta applikationer i deras respektive MVC-ramverk utvecklas.
2
2 Bakgrund
2.1 PHP
PHP är ett skriptspråk som utvecklades av Rasmus Lerdorf och fokuserar på utveckling emot serversidan (Hills et al. 2013). PHP är flexibelt och har intuitiva funktioner, öppen källkod, effektiv exekvering samtidigt stöd för SQL (Laaziri et al., 2019). PHP används för att skapa dynamiska webbapplikationer och genom utveckling av PHP blir affärslogiken blandad med presentationslagret och databasförfrågningar, vilket påverkar underhållet och skalbarheten av en applikation (Laaziri et al. 2019). En lösning på problemet med underhåll kan tänkas vara användandet pakethanteraren Composer för att hantera färdigutvecklade komponenter.
2.1.1 Composer
Composer är en pakethanterare som ligger i grunden för modern PHP-utveckling (Stauffer, 2019). Vidare tillåter Composer utvecklaren att ladda ner olika tillägg/bibliotek som kan användas i sitt projekt och hanterar dem åt en (getComposer.org). Composer är även grunden för testning, installeringen av skript etc. (Stauffer, 2019). Eftersom det är ett verktyg som tillåter utvecklaren att hämta färdigutvecklade komponenter för att lösa specifika problem minskas även utvecklingsprocessen. Gemenskapen inom PHP har gjort ramverk tillgängliga att hämta genom Composer.
2.2 Ramverk
Ramverk möjliggör för återanvändning av programkod i form av generisk logik och grundfunktioner inom en specifik domän (Salas-Zárate et al. 2015). Grundfunktioner som databasintegrering, sessions hantering och säkerhet underlättar vid utveckling och testning av webbapplikationer (Lancor & Katha, 2013). Ramverk underlättar hållbarheten av applikationer genom att stödja organiseringen av mappar och filstruktur (Lancor & Katha, 2013). Ramverk finns tillgängliga för flertalet programmeringsspråk såsom Ruby, Groovy och Php (Salas-Zárate et al. 2015).
Utveckling med ramverk ger flera fördelar. Ramverk minskar utvecklingstiden då funktioner som normalt tar hundratals rader kod oftast kan skrivas med hjälp utav ett ramverks inbyggda funktioner (Prokofyeva & Boltunova, 2016). Likt Prokofyeva & Boltunova förklarar Lazziri et al (2019) att ramverk minskar utvecklingstiden samt bidrar till att uppfylla kodningsstandarder. Vidare har ramverk en säkerhetsfördel då dess användare blir testare för ramverket (Prokofyeva & Boltunova, 2016), Ramverk hjälper även utvecklare genom att de ofta har en form av gemenskap och dokumentation vilket underlättar för utvecklare som söker svar (Prokofyeva & Boltunova, 2016).
Webben har utvecklat i sett sådant tempo att utvecklare numera använder flertalet olika teknologier för att skapa en enskild applikation (Pop & Altar, 2014). Flera olika teknologier minskar underhållbarhet och korrigerbarhet på programkoden (Pop & Altar, 2014). Eftersom flertalet av komplexa applikationer utvecklas lär den minskande underhållbarheten och korrigerbarheten eskalera i takt med den ökande komplexiteten hos applikationerna. Pop &
Altar (2014) förklarar att det finns ett behov för att separera användargränssnittet från datalagringen och föreslår användandet av designmönster som en lösning.
3
2.3 Designmönster
Designmönster är återanvändbara och upprepningsbara lösningar som löser designproblem inom utvecklingsprocessen (Thung et al., 2010; Garzotto et al., 1999; Gamma et al., 1995).
Garzotto et al. förklarar trots potentialen och populariteten av designmönster har endast ett fåtal användbara och effektiva designmönster tagits fram till webben (1999). Vidare förklarar Garzotto et al (1999) att bristen på designmönster inom webbdomänen är en nackdel då designmönster är som mest användbara när de kan delas inom en gemenskap. Tillskillnad från Garzotto et al. (1999) menar Thung et al. (2010) att flertalet olika designmönster existerar och har lösningar för specifika problem.
De främsta fördelarna med en bredare användning av designmönster inom webben enligt Garzotto et al. (1999) är följande:
• Kvalitet av design: Återanvändning av beprövade designmönster tillåter oerfarna att producera en bättre design gentemot att modellera från grunden.
• Tid och kostnad av design: Liknande menar de att oerfarna som använder flertalet av designmönster skulle slutföra sin design på kortare tid med lägre kostnad än vad som annars krävts.
• Tid och kostnad vid implementation: Användning av beprövade designmönster förväntas även att minska utvecklingstiden gentemot att implementera en applikation designad från grunden.
Likt fördelarna anser Thung et al. (2010) att utvecklingsmässigt ökar designmönster underhållbarheten av en applikation medans användarmässigt förbättrats användbarheten av en webbapplikation.
Att välja det lämpligaste designmönstret för en webb-applikation är inte enkelt (Chang et al., 2006; Morales-Cahparro et al., 2007). Thung et al. (2010) hävdar att de flesta utvecklare saknar kunskap om befintliga designmönster. Däremot erhåller de existerande och beprövade designmönstren dem nödvändiga lösningarna till designproblemen (Thung et al., 2010;
Garzotto et al., 1999).
Användandet av designmönster bör ta hänsyn till aspekter såsom kontext, struktur samt designmönstrets konsekvenser (Thung et al., 2010). Thung et al. (2010) utförde en fallstudie där bland annat det designmönstret model-view-controller (MVC) analyserades på de ovannämnda aspekterna.
2.4 MVC
Model-view-controller designmönstret är ett användbart sätt att utveckla interaktiva-system, där huvudidén ligger i att separera användargränssnittet från den underliggande data som representerar gränssnittet (Leff & Rayfield, 2001). Likt Leff & Rayfield (2001) skriver Thung et al. (2010) att webbapplikationer som är skapta med designmönstret MVC har både ökad underhållbarhet samt skalbarhet. MVC tillåter att vy-komponenten förändras utan att det påverkar modellen genom skapandet av en dynamisk vy (Thung et al., 2010). Däremot förklarar Thung et al. (2010) att det är nödvändigt för utvecklarna att besitta bra programmerings samt planeringsförmåga för att separera komponenterna.
4
MVC designmönstret delar in applikationsansvaret i tre huvuddelar, modellen som är en form av domän-specifik implementation av en applikations struktur, Vyn som är användargränssnittet som hämtar och visar data från modellen och kontrollern, ett gränssnitt som skickar meddelanden mellan modellen och vyn (Krasner & Pope, ,1998). Figur 1 och 2 nedan illustrerar designmönstret samt kodexempel på hur kontrollern kan användas i en applikation.
Figur 1
Illustrerar MVC-designmönstretFigur 2 Exempel på en controller i Laravel
MVC-ramverk finns både på server- och klientsidan. Exempel på MVC-ramverk på klientsidan är AngularJS och BackboneJS (Ocariza et al., 2015). Fördelen med MVC-ramverk på serversidan är att det endast existerar en modell, en vy och en controller, vilket ökar underhållbarheten vid att upprätthålla modellens integritet (Morales-Chapparo et al., 2007).
Exempel på MVC-ramverk på serversidan är följande:
• Cake är ett ramverk ämnat för snabb utveckling som använder kända designmönster som MVC, samtidigt som det är licenserat under MIT (Github, 2020). Cake har som mål att tillhandhålla ett strukturerat ramverk för att utveckla robusta webbapplikationer utan brist på flexibilitet (Github, 2020).
• CodeIgniter är skapat för applikationsutveckling där målet underlätta utveckling genom att tillhandhålla flertalet av bibliotek för vanliga uppgifter, Biblioteken får tillgång genom ett enkelt gränssnitt och logisk struktur. CodeIgniter är distribuerat enligt MIT licensen (Github, 2020a).
public function show($id) {
$airport = Airport::find($id);
return view('NameOfView', compact($airport));
}
5
• Laravel är ett webbapplikations ramverk skapat av Taylor Otwell och är licenserat under MIT (Github, 2020b). Laravel är ämnat att underlätta vanliga uppgifter som används inom många webbprojekt (Github, 2020b).
• Phalcon är skapt för webben och levereras som en C-extension för PHP vilket tillhandhåller låg resurskonsumtion och hög prestanda. Phalcon är distribuerat under BSD-3 licensen (Github, 2020c).
• Symfony är skapat för webb och konsolapplikationer men även som en samling av återanvändbara komponenter. Symfony är distribuerad enligt MIT licensen och används av flertalet olika PHP projekt (Github, 2020d).
• Yii är ett komponent baserat PHP ramverk som är licenserat under BSD-3 (Github, 2020e).
Ett MVC ramverk måste ge utvecklare möjligheten att integrera med ett databashanteringssystem för att lagra och hämta data (Pop & Altar, 2014). Pop & Altar skriver att i de flesta fall använder MVC-ramverken ett ORM-ramverk som en lösning på integrationen (2014).
2.5 ORM
Object-relational mapping (ORM) är ett verktyg som möjliggör för objekt-orienterade system att lagra data i en databas på ett säkert sätt, men kan vid behov uttryckas som objekt inom en applikation (O’Neil, 2008). Vilket möjliggör vid kodnivå att integrera med objekt som representerar domänmodellen separat från den relationella databasens struktur. ORM- ramverk underlättar för utvecklaren då den inte behöver veta databasstrukturen eller databasschemat (Pop & Altar, 2014). Ett mål med ORM är att isolera utvecklaren från behovet av att förstå SQL språket (Ireland et al., 2019). ORM-ramverk används för att korrelera den relationella datan med ett objekt orienterat system (Pop & Altar 2014).
Exempel på en integration med ett ORM-ramverk illustreras i figur 2 där Eloquent ifrån Laravel används för att hämta en specifik flygplats. Liknande kodexempel illustreras i figur 3 där Doctrine används för att hämta en specifik flygplats.
Figur 3 Exempel på hämtning av en resurs med ORM-ramverket Doctrine.
ORM-ramverk tillåter utvecklare att integrera med en databas, däremot är det värt att notera att en ORM inte kan uttrycka allt inom nativ SQL. Exempelvis är det svårt för ORM-ramverk att uttrycka nativa SQL-funktioner, men även utförandet av underfrågor och mer komplicerade frågor. Chen at al. (2016) skriver att ORM inte helt kan inkapsla de underliggande databasåtkomsterna, vilket kan göra den svårare att underhålla gentemot vanlig programkod. Troligen är underhållbarheten samt bristen på att uttrycka nativa SQL
public function show($id) {
$airport = $this->getDoctrine() ->getRepository(Airport::class) ->find($id);
/**/
}
6
funktioner en anledning att de flesta ORM-ramverken tillåter utvecklare att även skriva nativ SQL. ORM-ramverk kan exempelvis användas för att uttrycka CRUD operationer.
2.6 CRUD
De fyra grundläggande funktionerna inom lagring är CRUD (create, read, update, delete), CRUD är en engelsk akronym för skapande, hämtning, uppdatering och borttagning av resurser (Heller, 2007). De fyra operationerna mappar till de följande grundläggande inom databasteori:
• Insättning: Skapandet av en resurs
• Selektion: Hämtning av en eller flera resurser
• Uppdatering: Uppdatering av en resurs
• Borttagning: Borttagning av en resurs
SQL:2003 är en standard som antagits av ISO och för att följa den behöver databashanterare stödja de fyra grundläggande operationerna (McCarthy & Risch, 2005; Oracle, 2020;
PostgreSQL, 2020). CRUD operationer existerar inom webbdomänen där HTTP verben Post, Get, Put, Patch och Delete används för att reglera vilken metod som används (Ranga & Soni, 2019). CRUD-operationer har varit fokus i flertalet av forskningsartiklar exempelvis Li et al., (2019), Das & Saika (2016), Procaccianti et al. (2016) och Ranga & Soni (2019). Ranga & Soni (2019) forskade kring responstid vid utförandet av CRUD-operationer, deras implementerade artefakter utförde sina mätningar genom verktyget Postman.
2.7 Postman
Postman är ett verktyg för API utveckling som kan används för att testa, utveckla samt modifiera API:er (Ranga & Soni, 2019). Postman används för att skicka nätverksförfrågningar (Get, Post, Put, Patch, Delete) till applikationer (Ranga & Soni, 2019). Postman stödjer gruppering av liknande nätverksförfrågningar i kollektioner. En kollektion är en samling av nätverksförfrågningar som kan köras tillsammans som en serie av förfrågningar efter varandra vilket är nödvändigt vid automatiserade tester (Postman, 2020). Kollektioner har ett inbyggt stöd för datafiler vilket underlättar när data ska skickas i sina nätverksförfrågningar för att spegla ett verkligt användarfall.
7
3 Problemformulering
Det primära problemet ligger i den objektrelationella impedansmatchningen som uppstår vid konverteringen av relationell strukturerad data till domänobjekt som användas inom en applikation. ORM-ramverk togs fram som en lösning på integrationen mellan det objekt- orienterade och relationella paradigmet för att underlätta utvecklingen (van Zyl et al., 2006).
Det finns flera olika ORM-ramverk att använda sig utav. Vilket gör det problematiskt för utvecklare att välja. Aspekter som bör tas hänsyn till är exempelvis prestanda och hur ORM- ramverk underlättar utvecklingen (van Zyl et al., 2006). Dessa aspekter ligger i linje med den användbarhetsmodell som framtagits av Abran et al. (2003), vilket leder till att användbarheten hos ett ORM-ramverk inte bara definieras av exekveringstid utan även andra aspekter såsom lärbarhet och tillfredställelse.
3.1 Syfte och Frågeställningar
Syftet med undersökningen är att jämföra olika ORM-ramverk med avseende på prestanda på grundläggande databasoperationer samt användbarheten. Målet är att avgöra det lämpligaste samt användbara ORM-ramverket i hopp om att lättare kunna välja ORM-ramverk i framtiden.
Undersökningen kommer besvara följande frågeställningar:
• Vilket ORM-ramverk presterar bäst med avseende på grundläggande databasoperationer?
• Vilka två ORM-ramverk är mest användbara i förhållande till de framtagna kriterierna?
• Existerar det en skillnad i exekveringstid vid hämtning av resurser vid stora respektive små datamängder?
3.2 Hypotes
1. Det finns ingen statistiskt signifikant skillnad i prestandan vid uppdatering av en resurs mellan PHP ORM-ramverken.
2. Det finns en statistiskt signifikant skillnad i prestandan vid uppdatering av en resurs mellan PHP ORM-ramverken.
3. Det finns ingen statistiskt signifikant skillnad i prestandan vid skapandet av en resurs mellan PHP ORM-ramverken.
4. Det finns en statistiskt signifikant skillnad i prestandan vid skapandet av en resurs mellan PHP ORM-ramverken.
5. Det finns ingen statistiskt signifikant skillnad i prestandan vid borttagning av en resurs mellan PHP ORM-ramverken.
6. Det finns en statistiskt signifikant skillnad i prestandan vid borttagning av en resurs mellan PHP ORM-ramverken.
8
7. Det finns ingen statistiskt signifikant skillnad i prestandan vid hämtning av resurser mellan PHP ORM-ramverken.
8. Det finns en statistiskt signifikant skillnad i prestandan vid hämtning av resurser mellan PHP ORM-ramverken.
3.3 Delmål
Delmål sätts upp för att följa experimentet och hjälper till med att komma fram till mål och ge svar till frågeställningarna:
1. Identifiera ORM-ramverk som kommer att användas i undersökningen.
2. Välja ut ORM-ramverk baserat på framtagna användbarhetskriterier.
3. Identifiera dataset som kommer resultera i undersökningens data.
4. Utveckla den applikation som kommer användas med respektive ramverk.
5. Utföra mätningar och lagra mätvärden
6. Besvara frågeställningar genom analys och utvärdering av slutresultatet.
9
4 Metod
Metoden som huvudsakligen används för att besvara frågeställningen kommer vara en empirisk metod i form av ett tekniskt inriktat experiment. Experiment används när man vill ha mer kontroll över studien och manipulera vissa beteenden på ett precist och systematiskt sätt (Wohlin et al., 2012). Ett tekniskt inriktat experiment är mer kontrollerat än de mänskliga då människor tenderar till att agera olika vid olika tillfällen, medans verktyg oftast agerar likadant (Wohlin et al., 2012). Wohlin et al. (2012) skriver också att kontrollen som experiment tillgodoser möjligheten att dra mer övergripande slutsatser och möjliggör för användandet av statistiska analyser.
Vidare utförs en litteraturstudie för att evaluera vilka ORM-ramverk som kommer användas till experimentet då tiden inte finns att utföra intervjuer eller möjligheten att nå ut till tillräckligt många människor med relevant kunskap eftersom inga omfattande kretsar med utvecklare identifierats. Ramverken som väljs ut kommer därefter evalueras baserat på de kriterier som tagits fram av Abran et al. (2013) för att välja ut de lämpligaste att använda i experimentet.
4.1 Alternativa metoder
Människoinriktade experiment i form av enkätundersökning skulle kunna tänkas användas i denna studien. Däremot är dessa inte lämpliga i denna typ av undersökning då Wohlin et al.
(2012) skriver att undersökningar inte erhåller kontroll över utförandet eller mätningen.
Vidare bör inte enkätundersökning användas för denna typ av prestandamätning då användarnas upplevelse av prestanda inte ger lika exakta mätvärden som benchmarking, samt att människor kan ha olika uppfattningar på vad som kan anses vara en längre eller kortare svarstid. Däremot är människoinriktade experiment mer lämpade till att svara på frågor kring användbarhet och användarupplevelse, vilket kan vara aspekter värda att analysera då minimala skillnader mellan exakta mätvärden möjligtvis inte uppfattas av användare.
Ytterligare en möjlig metod är fallstudie. Fallstudie undersöker en entitet eller ett fenomen i förhållande tills dess verkliga kontext (Wohlin et al., 2012). Tillskillnad från experiment väljs de variabler som typiskt representerar situationen. Enligt Wohlin et al. (2012) är resultaten från fallstudier svårare att tolka och generalisera än ett experiment vilket kan tänkas leda till att resultaten inte blir lika exakta som vid ett experiment. Vidare eftersom studien riktar sig emot att mäta CRUD granularitet erhåller inte fallstudien den mängd kontroll som är nödvändig för att utföra mätningarna. Ytterligare behövs även en verklig kontext som exempelvis ett företag vilket leder till att en fallstudie inte är genomförbar för denna studie eftersom inga företag med ett riktigt fall har identifierats.
4.2 Relaterad forskning
Utvärdering av prestandan på ORM-ramverk har gjorts i tidigare studier. Ramverket hibernate jämfördes med en objekt-orienterad databas db4o i olika databasoperationer av van Zyl et al (2006). Resultatet visade att db4o presterar bättre än hibernate.
Vidare jämfördes Entity framework och Nhibernate i tre av de grundläggande CRUD operationerna (Cvetkovic & Jankovic, 2010). Resultatet visade att Entity Framework presterade bättre i majoriteten av testfallen. De redovisar för valt dataset, testmiljöns
10
mjukvara samt vilka databasoperationer de använder vilket underlättar replikering. Däremot utvecklades den inte med öppen källkod.
Procaccianti et al. (2016) utförde ett empiriskt experiment där de intresserade sig utav energiförbrukning och exekveringstid mellan ORM-ramverken Propel och TinyQueries vid utförandet av CRUD operationer på varierande datamängd. Resultaten visade att ORM- ramverken hade en betydande inverkan på både energiförbrukningen och prestandan.
Procaccianti et al. (2016) redovisar för storlek på de varierande dataset, miljöns hårdvara samt vilka databasoperationer som används för experimentet, vilket underlättar replikeringen.
Hoxmeiers och DiCesares (2000) forskning resulterade i att användare var som mest nöjda när svarstiden understeg tre sekunder. Vidare nämner Rajamony & Elnozahy att ifall en användare som upplever en längre fördröjning utan respons tenderar till att byta till en konkurrents webbplats som har lägre responstid (2001). Författarna nämner även att responstid är ett nyckelmått när det kommer till slutanvändarens tillfredsställelse. Utöver detta skriver Apte, Hansen och Reeser (2003) att det ofta är servern bearbetning som står för den största fördröjningen.
4.3 Tillvägagångssätt
Studien inleds genom att utföra en litteratursökning och därefter välja ut två ramverk baserat på de användbarhets kriterier som tagits fram som baseras på Abran et al. (2003) samt med hänsyn till de etiska och studiespecifika aspekterna. Litteratursökningen kommer grunda sig på ett tillvägagångsätt inom systematisk litteraturöversikt nämligen databassökningar (Jalali
& Wohlin, 2012).
Databassökningar kommer genomföras i olika databaser baserat på nyckelord som identifierats inom undersökningsområdet. Därefter kommer de funna artiklarna att bedömas genom en stegvis bedömning av kvalité. Bedömningen av artiklarna sker stegvis och ligger i linje med det som beskrivs av Jalali & Wohlin (2012) kan se ut på följande vis:
• Innehåller titeln nyckelord som fanns i söksträngen?
• Är abstract relevant?
• Är introduktionen samt slutsatsen relevant?
• Är hela artikeln relevant?
Om en artikel passar de ovannämnda villkoren sparas den och läggs till i litteratursökningen.
Efter litteratursökningen utvecklas två funktionsekvivalenta applikationer med respektive ramverk, där variabeln som är av intresse är svarstid. Svarstid kan exempelvis delas in i följande delar
• Tiden det tar för servern att bearbeta förfrågan
• Tiden det tar för nätverket att skicka över datan
• Tiden det tar för klienten att rendera vyn
Eftersom frågeställningen främst är inriktad emot serversidan medför det att det är väsentligt att utesluta svarstid som beror på andra faktorer exempelvis tiden det tar att rendera vyn och skicka data via nätverket. Den svarstid som kommer att mätas i detta arbete är utförandet av CRUD operationer i de olika ramverken. Vilket ligger i linje med det som Li, Karnan och Chisti
11
utförde 2017. Vidare kommer även mängden data förändras mellan experimenten för att se vilket av ramverken som är mest skalbart i förhållande till experimentdomänen.
4.4 Etik
Vid forskning bör hänsyn föras till olika former av etiska aspekter, dessa gäller inte endast vid användarstudier utan även under tekniskt inriktade experiment. Därför är det nödvändigt att se över och diskutera möjliga etiska implikationer som kan uppstå vid genomförandet av experiment
En aspekt att ha i åtanke är kring den datan som används utav applikationerna. Om datamängden är fiktiv eller riktig, då riktig data exempelvis kan vara konfidentiella eller ha andra former av restriktioner vilket gör att den måste behandlas vaksamt (El-Hajj et al., 2016).
Däremot är det väsentligt att använda så verklighetstrogen data som möjligt då experimentet kan förlora relevans.
Vidare är det även nödvändigt att samla in en tillräcklig mängd data för att kunna dra valida slutsatser då en låg datamängd medför svårigheter att se mönster i datan (Wohlin et al., 2012).
Detta uppnås genom att automatisera och göra mätningarna upprepningsbara. Ytterligare kommer den insamlade datan att analyseras genom diagram och om det är nödvändigt, användandet av statistiska metoder exempelvis analys av varians. Wohlin et al (2012) uttrycker att analys av varians används för att kontrollera ifall ett urval av data har samma medelvärde.
Ytterligare är det intressant att reflektera kring hur datan som genereras av applikationen hanteras. Att göra rådatan samt den statistiska koden som används att utföra analysen tillgänglig är fördelaktigt för alla och ger möjligheten att bekräfta resultaten (Shamseer &
Roberts, 2016). Vidare är det väsentligt att göra den transparent då det bidrar till vetenskapliga framsteg i form av ansvarighet, effektivitet och replikerbarhet (Knotterus &
Tugwell, 2016).
Utöver detta är det viktigt att arbetet är replikerbart, på grund av att det är enklare att lita på resultatet. Om ett arbete utförs men även dokumenteras korrekt kommer en replikering av arbetet att leda till liknande resultat (Wohlin et al., 2012). Detta görs genom utveckling med öppen källkod samt publicering av de dataset som används. Vidare är det viktigt att redovisa möjliga faktorer som kan påverka prestandan på applikationerna exempelvis hårdvara och mjukvaruversioner för att uppnå en tydligare transparens. Ytterligare redovisas även de framtagna sökorden samt omfånget av den sökning som utförs i litteraturstudien, vilket vidare ökar studiens replikerbarhet.
Vidare är det nödvändigt att applikationerna byggs så funktionsekvivalenta som möjligt för att öka tillförligtligheten. Wohlin et al. beskriver detta som tillförlitlighet i genomförandet av behandlingen (2012). Enligt Wohlin et al. ska behandlingen vilket i detta fallet är den programkod som utför mätningarna vara standardiserad i mellan artefakterna (2012). Detta säkerställs genom att placera den kod som utför mätningarna på samma del i de utvecklade artefakterna, vilket leder till att mätningarna utförs på samma vis oavsett vilken artefakt som körs. Ytterligare kan det uppnås genom att inte inkludera exempelvis validering i en av artefakterna men inte den andra, då valideringen tar prestanda och därmed förlänger responstiden.
12
Ytterligare är det av intresse att utesluta slumpmässiga faktorer i den experimentella miljön (Wohlin et al., 2012). I experimentets fall skulle detta exempelvis kunna vara nätverks fördröjningar som kan uppstå vid utförandet av mätningar i applikationen, vilket skulle leda till en felaktig slutsats. Detta motverkas genom att använda en lokal webbserver så att applikationen inte är beroende av nätverkstillgång då även den påverkar resultatet av mätningarna.
13
5 Genomförande
5.1 Litteratursökning
5.1.1 Sökstrategi
Sökprocessen påbörjades genom manuella sökningar i kända databaser inom undersökningsområdet. Studien inkluderande några av databaserna som användes utav Doğan et al. (2014) i deras systematiska litteraturstudie. De inkluderade databaserna visas nedan.
• Sciencedirect
• IEE Xplore
• ACM Digital Library
• Google Scholar
Söktermerna som används vid tas fram genom att bryta ned frågeställningarna till nyckelord som föreslås av Kitchenham et al. (2009). De söktermer som togs fram visas nedan. Vidare för att begränsa mängden artiklar att utvärdera utförs sökningen från år 2015 dessutom utvärderas endast de 200 första artiklarna.
• Object relational mapping AND Performance
• Object relational mapping AND Performance AND PHP
• Object relational mapping AND FRAMEWORK AND PHP
• PHP AND framework AND comparison
• Persistent AND Comparative AND WEB
• ORM AND Comparative AND WEB
5.1.2 Upphittad Litteratur
Ramverken Laravel och Codeigniter med procedurell php i utförandet av CRUD-operationer och minnesanvändning (Das & Saika, 2016). Resultatet visade att Laravel presterade bäst utav de testade teknikerna. Vidare studerades även Laravel, Codeigniter och CakePHP med avseende på CRUD-operationer och andra aspekter såsom inläsning av komplex data (Li et al., 2017). Resultatet visade att CodeIgniter generellt presterade bättre än de andra ramverken följt utav Laravel (Li et al., 2017). Däremot redovisar inte författarna de dataset som användes för utförande av experimenten vilket gör replikering problematiskt, däremot verkar det som att produkt-data användes av (Li et al., 2017) och egengenererad blogg-data från (Das & Saika, 2016).
Ramverken Symfony, Codeigniter, Phalcon, Yii och CakePHP är kandidater som ställs emot diverse kriterier där Symfony och Phalcon väljs ut för vidare undersökning (Prokofyeva &
Boltunova, 2016). Ramverken jämfördes med avseende på antal förfrågningar per sekund samt tiden det tar att skicka en förfrågan (Prokofyeva & Boltunova, 2016).
Codeigniter, Symfony, CakePHP och Laravel jämfördes med avseende på prestanda i form av responstid, minnesanvändning och antal förfrågningar per sekund (Olanrewaju et al., 2015).
Resultaten visar att Laravel generellt sett presterar bättre än de andra ramverken följt utav Codeigniter.
14
Flygplansdata är en typ av data som använts i tidigare studier. Roopak et al. (2013), använde flygplansdata från American Statistical Association när de jämförde prestandan mellan db4o och mysql i diverse databasoperationer exempelvis borttagning och insättning. Vilket leder till att ett lämpligt dataset för artefakten kan tänkas vara flygplansdata.
Det dataset som används i experimentet liknar Roopak et al. (2013) i den mån att det är flygplansdata. Flygplansdatan kompilerades av OpenFlights.org och är distubrerad under ODbl (Open Database License). Källdatan till OpenFlight genererades exempelvis från databasen Digital Aeronautical Flight Information File som hanteras av National Geospatial- Intelligence Agency samt ourairports (OpenFlight, 2020).
5.1.3 Sökresultat
Ramverken och deras respektive ORM som identifierades inom den ovanstående litteraturen listas nedan. De ramverk som inte har namngivit sin ORM får sitt ramverks namn i tabellen.
Tabell 1 Ramverk som identifierats med deras respektive ORM-ramverk
Ramverk ORM
Laravel Eloquent
CodeIgniter CodeIgniter
Symfony Doctrine
CakePHP CakePHP
Phalcon Phalcon
Yii Yii
5.1.4 Urval av ramverk
De funna ramverken ställs emot etiska, studiespecifika samt användbarhets kriterier för att evaluera vilka ramverk som kommer undersökas i experimentet. Selektionen av ramverk är strikt vilket betyder att så fort de inte matchar ett kriterie jämförs det inte vidare. Resultaten syns i tabell 2.
15
Tabell 2 Etiska samt studiespecifika kriterier
Ramverk Open-Source Gratis att använda i
fullversion
Använder
composer som pakethanterare
Laravel Ja Ja Ja
CodeIgniter Ja Ja Ja
Symfony Ja Ja Ja
CakePHP Ja Ja Ja
Phalcon Ja Ja Nej
Yii Ja Ja Ja
Därefter ställs de återstående ramverken emot diverse användbarhets kriterier. Kriterierna är följande och är baserade på Abran et al 2013.
• Lärbarhet: Tiden det tar att lära sig ramverket, finns officiella video-genomgångar samt en bra och korrekt dokumentation.
• Tillfredställelse: Möts den förväntande nivån av tillfredsställelse vid uppsättning av en applikation med grundläggande koppling till en databas. upplevdes mycket frustration vid uppsättning genom att följa den officiella dokumentationen.
• Effektivitet: Finns möjlighet för generering av programkod som minskar utvecklingstiden för utvecklaren?
Laravel ställs först emot lärbarhetskriteriet som möts då webbplatsen Laracasts (2020) omnämns som resurs i dokumentationen. Tillfredsställelse kriterier möts då uppsättningen av en applikation med grundläggande koppling till databas inte upplevdes som frustrerande då ändringar utfördes i en enkel konfigurations-fil som hanterar databasuppkopplingen samt dokumentation var utförlig och uppdaterad. Effektivitetskriteriet möts då Laravel stödjer generering av programkod genom Artisan (Laravel, 2020).
CodeIgniter möter inte lärbarhetskriteriet då ingen officiell webbplats för video-genomgångar nämns i dokumentationen eller dess forum (CodeIgniter, 2020).
Symfony möter lärbarhetskriteriet då den officiella webbplatsen omnämner Symfonycasts (2020) och även ett officiellt träningsprogram för ramverket. Tillfredsställelsen möts av ramverket då uppsättningen av applikationen genom att följa den officiella dokumentationen var smidig, för att uppnå en koppling med den databas ändras en rad i en konfigurationsfil där raden tydligt indikerar vad som ska fyllas i. Effektivitetskriteriet nås då Symfony stödjer kodgenerering officiellt genom ”The Symfony MakerBundle” (Symfony, 2020)
CakePHP ställs emot och möter lärbarhetskriteriet då de har video-genomgångar i dokumentationen. Däremot möts ej tillfredsställelsekriteriet då dokumentationen för
16
konfigurering inte matchade de filer som genererades av ramverket. Vidare är det inte korrekt konfigureringsfil som man ombes att förändra då den skrivs över av en ytterligare genererad konfigureringsfil vilket skapade irritation (Cake, 2020).
Yii möter inte lärbarhetskriteriet då ingen officiell webbplats för video-genomgångar omnämns i dokumentationen eller forumet. Däremot verkar ramverket ha en uppdaterad och korrekt dokumentation (Yii, 2020).
Tabell 3 Användbarhetskriterier
Ramverk Lärbarhet Tillfredställelse Effektivitet
Laravel Ja Ja Ja
CodeIgniter Nej - -
Symfony Ja Ja Ja
CakePHP Ja Nej -
Yii Nej - -
Identifieringen av de ramverk som utvärderades emot varandra i ovanstående tabeller, samt framtagandet av användbarhetskriterier och identifiering av dataset som ska användas till artefakterna leder till att vi besvarar delmål 1,2 samt 3.
5.2 Utveckling av webbapplikation med Laravel
Installationen av Laravel utförs genom att följa den officiella dokumentationen för ramverket.
Därefter påbörjades konfigurering av ramverket och implementation av CRUD operationerna.
Laravel utför antagandet att varje resurs har två separata fält som erhåller en tidsstämpel när resursen blev uppdaterad samt när resursen skapades. Det dataset som används har inte de kolumnerna naturligt i sig vilket gjorde att konfigurationen för resursen behövdes ändras så tidsstämplar inte används1. Detta var en av de två viktiga konfigurationerna som utfördes på applikationen och illustreras i figur 4.
Figur 4 Implementation som tar bort tidsstämplar på Laravels modeller.
För att utföra testerna behövdes ytterligare konfigurering att göras, Då Laravel filtrerar bort varje nätverksförfrågning som manipulerar en resurs som inte skickar med en CSRF-token, för att öka säkerheten på applikationen. För att underlätta testning och replikering av arbetet
1 https://github.com/b17robev/ExamensArbeteLaravel/commit/191b327 class Airport extends Model
{
public $timestamps = false;
// ... further code
17
behövde verifieringen stängas av2. Eftersom experimentet endast tar hänsyn till ORM- ramverkens prestanda blir detta därmed inte en faktor som kan påverka experimentets validitet och underlättar replikering av undersökningen.
5.3 Utveckling av webbapplikation med Symfony
Installationen av Symfony utförs genom att följa den officiella dokumentationen. Därefter påbörjades konfigurering och implementation.
Implementationen med att hämta en specifik mängd resurser från databasen var inte inbyggd i Doctrine och behövdes läggas till3. Repository lagret utökades med en metod som hämtar ett specifikt antal resurser. Lösningen baserades på Doctrines officiella dokumentation och illusterar i figur 5.
Figur 5 Implementation av metod som hämtar specifikt antal resurser
Hantering av automatisk ökade värden på primär-nycklar på resurser i databasen hanteras i Doctrine med hjälp utav dekoratorn “GeneratedValue”, som enligt den officiella dokumentationen oftast används för primära nycklar i databaser4.
5.4 Progression
Syftet med experimentet från början var att genom benchmarking jämföra ramverken i deras exekveringstid av CRUD-operationer. Studien utökades genom att även jämföra minnesanvändning av respektive databasoperation då implementationen visade sig vara relativt enkel.
Implementationen som mäter minnesanvändning använde sig först utav den inbyggda php funktionen ”memory_get_peak_usage” men vid pilotstudien visade det sig att den inte var lämplig då den funktionen erhåller den högsta minnesanvändningen som skriptet har nått fram tills den punkten. Vilket nödvändigtvis inte är helt korrekt då applikationen kan ha nått det i ett tidigare stadie innan operationen genomförts. Därefter implementerades mätningen med ”memory_get_usage”.
Hämtnings-operationen som genomförs var först tänkt att endast ta hänsyn till hämtningen av en resurs, men eftersom implementation var smidig valdes det att utöka studien genom att hämta 10, 50, 100, 500 och 1000 resurser för att undersöka ifall det finns linjära samband mellan ORM-ramverken när de hämtar olika mängd resurser56.
2 https://github.com/b17robev/ExamensArbeteLaravel/commit/17f8bd5
3 https://github.com/b17robev/ExamensArbeteSymfony/commit/fc58f12
4 https://github.com/b17robev/ExamensArbeteSymfony/commit/c16c559
5 https://github.com/b17robev/ExamensArbeteLaravel/commit/671c10b
6 https://github.com/b17robev/ExamensArbeteSymfony/commit/0a6d03e
public function take($amount) {
return $this->createQueryBuilder('a') ->setMaxResults($amount) ->getQuery()
->getResult();
}
18
Uppdaterings samt insättnings-operationerna som först implementerades använde sig endast utav tre kolumner på respektive resurs. Detta korrigerades därefter så att alla fält används på varje resurs, då det ger verkligare representation av ORM-ramverkets prestanda78.
Validering påbörjades att implementeras grundläggande i artefakterna. Det beslutades dock att ta bort den tillagda valideringen för att artefakterna ska förbli så funktionsekvivalenta som möjligt91011.
Experimentet utförs med hjälp utav postman för att simulera nätverksförfrågnigar till artefakterna. Samlingar används för att gruppera databasoperationerna samt för att underlätta benchmarking på grund av stödet för datafiler. Först var tanken att utveckla ett klient-skript som körs i browsern för att simulera nätverksförfrågningar med formulär data, vilket kräver en visuell representation av applikationen. Eftersom mätningarna endast sker på serversidan kan det betraktas som betydelselöst att ha en visuell representation endast för att simulera nätverksförfrågningar. Därför beslöts det att utföra testerna med verktyget Postman.
5.5 Pilotstudie
Pilotstudien agerar som en förberedelse inför den riktiga mätningen och ska tänkas indikera huruvida det är möjligt att utföra den planerade mätningen. I förstudien kommer mätserien vara betydligt kortare än i experimentet.
5.5.1 Tillvägagångssätt
I förstudien och det fullskaliga experimentet kommer mätningen att utföras på en lokal webbserver där dess mjukvara samt hårdvara är listad nedan.
Tabell 4 Mjuk – och hårvarukonfiguration
Operativsystem Windows 10 Pro
PHP-version 7.2.11
Databas 5.7.24
Postman 7.2.11
CPU Intel Core i7-6700k 4.00GHz
RAM 16Gb @2133MHz
GPU NVIDIA GeForce GTX 1060 6GB
Laravel / Eloquent-version 7.0
Symfony / Doctrine-version 4.4.6 / 2.7.1
7 https://github.com/b17robev/ExamensArbeteLaravel/commit/7f0d8b2
8 https://github.com/b17robev/ExamensArbeteSymfony/commit/1d0ecc2
9 https://github.com/b17robev/ExamensArbeteLaravel/commit/475fb1b
10 https://github.com/b17robev/ExamensArbeteSymfony/commit/dd77a54
11 https://github.com/b17robev/ExamensArbeteSymfony/commit/f761dbb
19 Mätningen sker på följande sätt:
• 100 mätningar kommer att utföras på varje CRUD-operation, vilket ger en total serie på 400 mätningar. Mängden ger en bra uppfattning om mätningarna utförs korrekt samt ökar chansen att se eventuella problem som spikar i mätvärdena.
• Mätningen på exekveringstiden för CRUD-operationerna samt minneanvändningen sker endast på serversidan direkt innan operationen genomförs och avslutas därefter.
• Simulering av nätverks-förfrågningar sker genom Postman med hjälp utav Postman Collection Runner.
Det finns en mängd olika faktorer som kan påverka mätresultaten som erhålls i denna förstudie och för att minimera risken att dessa inträffar finns vissa steg som görs innan varje ny mätning. Det som har utförts innan varje mätserie är följande:
• Ingen körning av bakgrundsprocesser som inte är väsentliga vid utförandet av mätningarna.
• Uppkoppling mot internet har inaktiverats under mätningens gång.
• Databaserna har tömts och innehållet genereras på nytt inför varje mätserie för att minimera effekten av indexering.
5.5.2 Resultat för skapandet av en resurs
Figur 6 Mätserie med exekveringstid för skapandet av en resurs
Figur 6 visar ett linjediagram över de erhållna mätvärdena för exekveringstiden för skapandet av en resurs för de båda orm-ramverken. Mätserien visar inte på några större problem med spikar.
20
Figur 7 visar ett stapeldiagram över medelvärdet för exekveringstid tillsammans med standardavvikelse i respektive ramverk.
Figur 7 Medelvärde för exekveringstid vid skapandet av en resurs med standardavvikelse
Figur 8 visar ett linjediagram över de erhållna mätvärdena för minnesanvändningen vid skapandet av en resurs för de båda orm-ramverken. Mätserien visar inte på några spikar och håller ett konstant värde igenom hela mätningen.
Figur 8 Mätserie för minnesanvändning
21
Figur 9 visar ett stapeldiagram med medelvärde och standardavvikelse på samma mätserie som representeras i figuren ovan.
Figur 9 Mätserie för medelvärdet vid skapandet av en resurs
5.5.3 Resultat för inläsning av enskild resurs
Figur 10 visar på en mätserie för exekveringstiden för hämtningen av en resurs med respektive ramverk. Mätserien indikerar återigen inte på några större spikar.
Figur 10 Mätserie med exekveringstiden för hämtning av en resurs
Figur 11 visar ett stapeldiagram övermedelvärdet av exekveringstiden med tillhörande standardavvikelse.
22
Figur 11 Medelvärde för exekveringstid vid hämtningen av en resurs med standardavvikelse
Figur 12 och 13 visar på minnesanvändningen av respektive ramverk vid hämtningen av en enskild resurs
Figur 12 Mätserie som visar minnesanvändningen
23
Figur 13 Mätserie som visar medelvärde med standardavvikelse
5.5.4 Resultat för uppdatering av resurs
Figur 14 visar en mätserie på exekveringstiden vid uppdateringen av en resurs. Serien indikerar inte några tydliga spikar.
Figur 14 Mätserie för exekveringstiden vid uppdateringen av en resurs
24
Figur 15 visar medelvärde på exekveringstiden med standardavvikelse för uppdatering av en resurs.
Figur 15 Medelvärde med standardavvikelse för uppdateringen av en resurs Figur 16 och 17 visar ett linje respektive stapeldiagram för minnesanvändningen vid uppdateringen av en resurs.
Figur 16 Minnesanvändning vid uppdatering av en resurs
25
Figur 17 Medelvärde med standardavvikelse för minnesanvändningen vid uppdatering av en resurs
5.5.5 Resultat för borttagning av en resurs
Figur 18 visar på mätserien på exekveringstiden vid borttagning av en resurs. Inga tydliga indikationer på spikvärden.
Figur 18 Mätserie för exekveringstiden vid borttagning av en resurs
Figur 19 visar med hjälp utav ett stapeldiagram på medelvärde med tillhörande standardavvikelse för mätserien.
26
Figur 19 Mätserie med medelvärde och standardavvikelse för exekveringstiden vid borttagning av en resurs
Figur 20 och 21 visar linje med tillhörande stapeldiagram med standardavvikelse för mätserier på minnesanvändnigen för operationen.
Figur 20 Mätserie för minnesanvändningen vid borttagning av en resurs med respektive orm
27
Figur 21 Medelvärde för minnesanvändningen med standardavvikelse för borttagning av en resurs.
5.5.6 Resultat för inläsning av flera resurser
Figur 22 visar på en mätserie vid inläsning av 10,50,100,500 och 1000 resurser för respektive ramverk. Ramverken pekar på linjära samband vilket gör det intressant att undersöka vidare då det möjligen tillåter att räkna ut en genomsnittlig svarstid baserat på en mängd resurser.
Figur 22 Inläsning av 10, 50, 100, 500 och 1000 resurser med respektive ORM- ramverk
28
6 Utvärdering
6.1 Tillvägagångssätt
Tillvägagångsättet liknar pilotstudien i den mån att samma faktorer tas hänsyn till vid varje mätserie. Dessutom läggs dessa ytterligare faktorer till:
• Applikationerna ställs in på att köra i produktionsläge, detta utförs genom varje ramverks officiella dokumentation.
• En virtuell dator skapas och är värden för mätningarna. Artefakterna hämtas ifrån Github, Composer, PHP samt Mysql laddas ned till den virtuella maskinen för att kunna köra applikationerna.
Den virtuella maskinen skapas genom Windows inbyggda funktion Hyper-v som skapar upp virtuella maskiner (Microsoft, 2020). Den virtuella maskinens minne allokeras dynamiskt och får endast tillgång till 4 kärnor av processorn. Tabell 5 nedan listar specifikationerna på den virtuella maskinen som skiljer sig gentemot pilotstudiens tillvägagångssätt.
Tabell 5 Mjukvara specifikationer
Operativsystem Windows Enterprise Evaluation
PHP 7.4.5
Mysql 5.7.18
Postman 7.24.0
Mätserien utökas ifrån pilotstudiens 100 mätpunkter per operation till 600 punkter per operation vilket innebär mer tillförlitliga resultat. Ökningen tillåter även att med mer säkerhet dra slutsatser kring prestandan med hjälp utav statistiska metoder. Mätprocessen har strukturerats på följande vis för respektive ramverk:
• Fyll databasen med erhållna data från dataset.
• Mät prestandan för respektive CRUD operation.
• Skapa upp databasen på nytt.
Vidare tillskillnad från pilotstudien formateras de erhållna värdena i applikationerna innan de skrivs in i respektive CSV-fil.
29
6.2 Analys
6.2.1 Skapandet av resurs
Baserat på diagrammen i Appendix B samt figur 23 och 24 konstateras det att ORM ramverket Doctrine är signifikant snabbare än Eloquent att skapa en resurs. Dessutom är minnesanvändingen signifikant lägre än Eloquent.
Figur 23 Skapandet av en resurs med konfidensintervall.
Figur 24 Minnesanvändning vid skapandet av en resurs
30
6.2.2 Hämtning av enskild resurs
Baserat på diagrammen i Appendix A men även figur 25 och 26 visar på att Eloquent statistiskt signikant skiljer sig gentemot Doctrine i tiden det tar att hämta en specifik resurs ur databasen samt mängden minne som operationen använder.
Figur 25 Hämtning av enskild specifik resurs.
Figur 26 Minnesanvändning vid hämtning av enskild resurs.
31
6.2.3 Uppdateringen av resurs
Diagram 27 och 28 är baserade på diagrammen i Appendix C och skapas för att förtydliga förhållandet av resultaten.
Figur 27 Uppdatering av en resurs med konfidensintervall.
Figur 28 Uppdatering av en resurs med konfidensintervall.
Figurerna ovan visar att Doctrine presterar bättre än Eloquent i förhållande till tiden det tar att uppdatera en resurs (Figur 27) däremot är Eloquent signifikant bättre att bevara sitt minne (Figur 28).
32
6.2.4 Borttagning av resurs
Figur 29 och 30 är baserade på diagrammen i Appendix D och skapas för att förtydliga resultatet.
Figur 29 Borttagning av resurs med konfidensintervall.
Figur 30 Minnesanvändning vid borttagning av resurs med konfidensintervall.
Figur 29 visar att Doctrine presterar signifikant bättre än Eloquent i förhållande till att utföra en borttagnings operation. Däremot visar Eloquent på att den knappt använde något minne alls vid utförandet av operationen. Det kan vara så att sättet som används för att mäta minnesanvändningen inte är helt korrekt.
33
6.2.5 Hur förhåller sig ramverken till varandra?
Figur 31 visar förhållandet mellan ramverken när de hämtar olika datamängd. Hämtningen utförs upptill 6000 resurser för att undersöka utvecklingen av tidsaspekten med hänsyn på resurser. Vilket är viktigt för att se hur dem olika ramverken skalar med avseende på antalet resurser. Figur 31 tyder på att Eloquent skalar bättre än Doctrine.
Figur 31 Hämtning av 10, 100, 500, 1000, 3000 och 6000 resurser med respektive ORM-ramverk
6.3 Slutsatser
Tabell 6 används för att svara på första frågeställningen. I detta fallet är lägst erhållet värde bättre.
• Vilket ORM-ramverk presterar bäst med avseende på grundläggande databasoperationer?
• Vilka två ORM-ramverk är mest användbara i förhållande till de framtagna kriterierna?
• Existerar det en skillnad i exekveringstid av databasoperationer mellan stora respektive små datamängder?
34
Tabell 6 Resultat av första frågeställningen
Variabel Skapandet av
resurs
Hämtning av enskild resurs
Uppdatering av enskild resurs
Borttagning av enskild resurs
Exekveringstid Doctrine Eloquent Doctrine Doctrine
Minnesanvändning Doctrine Eloquent Eloquent Eloquent
Tabell 6 bekräftar att Doctrine presterar bättre i form av exekveringstid för tre av de grundläggande databasoperationerna medans Eloquent är bättre på att bevara sitt minne.
Svaret på den första frågeställningen blir därmed att Doctrine presterar bättre med avseende på grundläggande databasoperationer.
Tabell 3 besvarar på den andra frågeställningen. Där de ställs emot de framtagna användbarhetskriterierna kring lärbarhet, tillfredställelse samt effektivitet.
Figur 31 bekräftar även att de existerar en skillnad av prestanda mellan stora respektive små datamängder. Eloquent verkar prestera bättre på alla operationer som har med hämtning av data att göra. Eloquent verkar även vara mer lämpad till större datamängder när det kommer till hämtning av data.
Eftersom resultaten är beräknade med ett konfidensintervall på 95% är det möjligt att dra slutsatserna att vid alla operationer är det en statistiskt signifikant skillnad på de testade databasoperationerna. Vilket leder till att hypoteserna 2,4,6,8 bevisas för denna studie.
Det är viktigt att nämna att i studien har endast respektive MVC med tillhörande ORM vart de variablerna som kontrollerats. Det är möjligt att de resultat som utvunnits inte tillhör ORM- ramverket utan härstammar från andra delar av MVC abstraktionen. Därför är nödvändigt att även mäta på respektive MVC utan ORM för att säkerställa skillnaden mellan Doctrine och Eloquent.
35
7 Avslutande diskussion
7.1 Sammanfattning
Studiens huvudmål har varit att identifiera vilket av två utvalda ORM-ramverk som presterar bäst med avseende på CRUD operationer. För att svara frågeställningarna har delmål satts upp som besvarats under studiens gång.
Delmål 1, ”Identifiera ORM-ramverk som kommer att använda i undersökningen”, uppfylldes genom att lista aktuella ORM-ramverk som används inom forskning, tabell 1 svarar på delmålet.
Delmål 2, ”Välja ut ORM-ramverk baserat på framtagna användbarhetskriterier”, uppfylls genom resultatet av tabell 2,3. De ORM-ramverk som utsågs vara Eloquent och Doctrine.
Delmål 3, ”Identifiera dataset som kommer resultera i undersökningens data”, delmålet uppfylls genom litteraturstudien som identifierade att flygplansdata har använts inom liknande forskning. Därefter identifierades ett öppet dataset från OpenFlights(2020).
Delmål 4, ”Utveckla den applikation som kommer användas med respektive ramverk”, besvaras genom genomförandet, progression och utvecklingen av öppen källkod med git.
Delmål 5, ”Utföra mätningar och lagra mätvärden”, uppfylls på samma sätt som delmål 4 samt pilotstudie och utvärderings kapitlen.
Delmål 6, ”Besvara frågeställningar genom analys och utvärdering av slutresultatet”, uppfylls genom att analysera och utvärdera resultatet i tabeller och diagram från den insamlade datan i delmål 5, som svarar på experimentets frågeställningar, ”Vilket ORM- ramverk presterar bäst med avseende på grundläggande databasoperationer?”, ”Vilka två ORM-ramverk är mest användbara i förhållande till de framtagna kriterierna?”, ”Existerar det en skillnad i exekveringstid vid hämtning av resurser vid stora respektive små datamängder?”.
Resultaten som erhålls vid tabell 6 indikerar att Doctrine presterar bäst i form av exekveringstid och Eloquent med minnesanvänding vid utförandet av CRUD-operationer.
Analysen indikerar även att större datamängder påverkar båda ORM-ramverkens prestanda.
Tabell 3 visar att de två ramverk som är mest användbara i förhållande till de framtagna kriterierna är Eloquent och Doctrine.
7.2 Diskussion
7.2.1 Etik
Det finns ett antal faktorer som kan ha påverkat undersökningen, dessa anses som viktiga att diskutera ifall de har en avgörande roll för att på ett korrekt sett kunna besvara frågeställningarna.
Användandet av en virtuell maskin kan påverkat experimentets resultat då den inte får full tillgång till processorn eller minnet. En virtuell maskin tillhandhåller däremot mer kontroll över experimentet då den säkerhetsställer att endast de väsentliga processerna för experimentet körs.
36
I och med den tidsram som existerar för undersökningen har gjort att det inte har varit möjligt att utföra experimentet på flertalet olika mjuk- och hårdvara konfigurationer. Vilket är ett hot mot undersökningens externa validitet samt dess generaliserbarhet då de resultat som utvunnits nödvändigtvis inte överensstämmer när andra faktorer förändras exempelvis version på ORM, PHP samt Mysql. Förändring av hårdvaran kan även ge upphov till annorlunda resultat vilket verkar visas av pilotstudien gentemot experimentet i förhållandet till spikdata och standardavvikelserna på datamängderna.
En ytterligare faktor som kan ha påverkat experimentet är att jag personligen har arbetat med ramverken. De flesta av mina lösningar är baserade på den officiella dokumentationen för respektive ramverk. Det är möjligt att dokumentationen för ramverken inte visar på den bästa praxisen med respektive ORM vilket kan ha påverkat resultatet. Vidare är det möjligt att den lösningen som togs fram inte nödvändigtvis är den mest effektiva. Arbetet har dokumenterats men det går däremot inte att helt utesluta fel. De möjliga felen är dock inte avsiktliga.
Användbarhetskriteriet tillfredställelse som togs fram vid urvalet av ramverken är framtaget och evaluerat av författaren själv, vilket innebär att ifall en annan människa skulle ställa de framtagna ramverken emot varandra kan resultatet av kriteriet förändras. Däremot kan denna form av evaluering vara fördelaktig exempelvis om en fallstudie utförs på ett utvecklingsinriktat företag. Då tillgången finns att nå ut till flertalet av olika utvecklare för att evaluera kriteriet.
Experimentet utfördes utan människor och restriktiv data vilket gör att man inte behöver ta hänsyn till att data lagrats eller på något sätt publicerats på ett sätt som skapar etiska konsekvenser. Utöver detta har referenser har angivits där text använts som information till studiens bakgrund samt utförande, för att tydligt förankra till forskning och ge ära till de personer som utfört arbetet.
7.2.2 Relaterade Arbeten
Inspiration till studien uppkom ifrån exempelvis Li et al (2019) där de jämförde MVC ramverken Laravel, CakePHP och Codeigniter vid utförandet av CRUD-operationer.
Resultatet visade att Laravel skapar data på 150, uppdaterar på 27 samt tar bort data på 14 millisekunder. Ställs dessa resultat gentemot de framtagna i denna studie noteras det att resultaten ligger i linje med varandra att skapandet tar längst tid följt utav uppdatering och borttagning. Li et al. (2019) visar på längre exekveringstid jämfört med denna studie, däremot förklaras skillnaden genom att datan är större och mer komplex.
Ramverken Laravel, Symfony och Codeigniter jämfördes utav Laaziri et al (2019) med avseende på responstid, minneanvändning samt mängden nätverksförfrågningar per sekund.
De använde sig utav Apache benchmark som testverktyg och resultaten visade att Symfony hade högst minnesanvändning och Laravel lägst. Responstiden visade Laravel på 4 och Symfony på 14 millisekunder. Vilket verkar tyda på att ingen databasuppkoppling används då svarstiderna är så pass låga. Liknande studie genomfördes tidigare av Olanrewaju et al. (2015) med ett tillägg på ett ytterligare ramverk. Olanrewaju et al. (2015) liknar det resultatet som Laaziri et al (2019) erhöll i den mån att minnesanvändingen var högre för Symfony gentemot Laravel samt att responstiden ligger på 4 för Larvel och 13 millisekunder för Symfony.
Tidigare forskning har ställt MVC ramverk emot varandra i liknande kriterier där Li et al.
(2019) fokuserade på exekveringstider av CRUD operationer och Laaziri et al. (2019) samt Olanrewaju et al. (2015) fokuserade på responstid samt minnesanvädning. Tillskillnad från de
