SVENSK TITEL
Http-anrop till Epost-API:er i Asp Net Core och PHP
Examensarbete inom huvudområdet Informationsteknologi Grundnivå 30 högskolepoäng
Vårtermin 2019 Robin Eskilsson
Handledare: Johan Bjurén
Examinator: Henrik Gustavsson
Sammanfattning
Asp Net Core är en uppföljare Asp Net som är ett ramverk utvecklat av Microsoft. Vid skapandet av Asp Net Core gjordes förändringar i den http-pipeline som fanns i Asp Net, där egenskaper som ansågs onödiga togs bort vilket skulle resultera i förbättrad prestanda för Asp Net Core. Forskning som inspirerat detta arbete har visat att PHP var mer tidseffektivt än Asp Net på att hämta, lägga till och ta bort data. Frågan är om förändringen av http-pipeline kan bidra till att Asp Net Core är mer tidseffektivt än PHP vid utförandet av http-förfrågningar.
Genom att utveckla ett epost-API i Asp Net Core och jämföra svarstider för utförandet av http- förfrågningar med ett redan existerande epost-API skrivet i PHP, kommer det vara möjligt att genomföra ett tekniskt inriktat experiment, där resultaten kan analyseras och slutsatser kan dras.
Resultaten i detta arbete visar att Asp Net Core är mer tidseffektivt än PHP vid utförandet av 10 000 http-förfrågningar. Det kan i framtiden vara intressant att undersöka hur storleken på post-anropen kan påverka svarstiden för Asp Net Core och PHP.
Nyckelord: Asp Net Core, PHP, Epost-API, Http-anrop.
Innehåll
1 Introduktion ... 1
2 Bakgrund ... 2
2.1 Webb-API ... 3
2.2 PHP ... 5
2.3 C# ... 5
2.4 ASP.NET Core ... 6
2.5 Postman ... 6
2.5.1 API-anrop från Postman ... 6
3 Problemformulering ... 8
3.1 Syfte, fokus & hypotes ... 8
4 Metod ... 10
4.1 Vetenskaplig metod ... 10
4.2 Etiska aspekter ... 11
5 Genomförande ... 12
5.1 Litteraturstudie ... 12
5.2 Pilotstudie ... 13
5.2.1 Pilotstudie resultat ... 13
5.3 Progression... 16
5.3.1 Modellklass ... 16
5.3.2 Databaskoppling ... 17
5.3.3 Epostservice ... 17
5.3.4 Controller... 18
5.3.5 Pixeltrackning ... 18
5.3.6 Batchkörning ... 19
6 Utvärdering ... 20
6.1 Hård- och Mjukvaruspecifikation ... 20
6.2 Presentation av undersökning ... 21
6.2.1 Testfall 1 – 10 000 get-förfrågan ... 21
6.2.2 Testfall 2 – 10 000 put-förfrågan ... 22
6.2.3 Testfall 2 – 10 000 post-förfrågan ... 24
6.3 Analys ... 25
6.4 Slutsats ... 26
7 Avslutande diskussion ... 27
7.1 Sammanfattning ... 27
7.2 Diskussion ... 27
7.3 Etik... 29
7.4 Framtida arbete... 29
Referenser ... 31
1
1 Introduktion
Neves, Paiva, Durães, (2013) skrev i sin studie att skillnaden mellan två programmeringsspråk kan ha en mätbar påverkan i flera nyckelaspekter av den resulterande applikationen. Att använda ett passande programmeringsspråk för vad som ska skapas är därför en intressant fråga. Beroende på vilken teknik och programmeringsspråk som används för att utveckla en applikation kan det finnas mätbara skillnader i flera nyckelaspekter av applikationen.
Ett exempel på att programmeringsspråk skiljer sig åt i mer än syntax och semantik är resultatet av experimentet utfört av (Neves, Paiva, Durães, 2013), där det efter en jämförelse av Java och PHP visade sig att Java kunde hantera ett större antal samtidiga förfrågningar snabbare än vad PHP kunde.
Ett annat exempel på att svarstider skiljer sig åt beroende på vilket programmeringsspråk och teknik en applikation är utvecklad med visade resultatet i studien utförd av Bounnady, Phantavong, Pathoumvanh & Sihalath (2016), där PHP var snabbare på datahantering än vad Asp Net var. Vemula, R (2017) undersökte .NET i förhållande till .NET Core, som är en utveckling av .NET. Några förbättringar som gjorts vid utvecklandet av .NET Core i förhållande till .NET är att .NET Core har en http-förfrågnings pipeline som är mer lättviktig, där onödiga egenskaper tagits bort. Det är intressant att se om förändringen av http-pipeline i Asp Net Core kan bidra till ändrade förhållanden i svarstider än de som presenterades vid en jämförelse mellan Asp Net och PHP. För att jämföra Asp Net Core och PHP skapas det ett epost-API skrivet i Asp Net Core som jämförs med ett redan existerande epost-API skrivet i PHP.
Den vetenskapliga metod som används i denna studie är ett teknikorienterat experiment. Syftet med studien är att utreda vilket av Asp Net Core och PHP som kan bidra med snabbast svarstider för http-metoderna get, put & post. Valet av att välja experiment som vetenskaplig metod för denna studie beror på att svarstider för API-anrop handlar om millisekunder, vilket gör det svårt att uppfatta större skillnader med blotta ögat. Experimentet går till genom att en klient gör 10 000 anrop av http-metoderna get, put & post, vilket sammanlagt blir 30 000 anrop för Asp Net Core och samma antal för PHP.
Resultaten av experimentet kommer att redovisas i diagram och med förklarande text, där varje
typ av http-metod är uppdelad i tre olika testfall. För samtliga testfall har det utförts ett anova-
test, där p-värdet visar om skillnaden på mätserierna är statistiskt signifikant eller ej. Resultaten
kommer att utvärderas för att se om någon av Asp Net Core och PHP är att föredra ur en
svarstidssynpunkt vid anrop av epost-API:er.
2
2 Bakgrund
Den datavetenskapliga disciplinen har en komplicerad historia med programmeringsspråk.
Programmeringsspråk skapas för olika anledningar, där ett språk till exempel kan förenkla domänspecifika problem medan ett annat kan skapas i politiska syften. Konsekvensen av den datavetenskapliga disciplinens komplicerade historia är att modern mjukvaruindustri nu har en uppsättning av inkompatibla programmeringsspråk, där språk har unika syntax, semantik, verktyg och innehåller även egna standardbibliotek (Stefik & Hanenberg 2014). Neves, Paiva, Durães, (2013) skrev i sin studie att skillnaden mellan två programmeringsspråk kan ha en mätbar påverkan i flera nyckelaspekter av den resulterande applikationen. Att använda ett passande programmeringsspråk respektive tillämpning är därför en intressant fråga.
Hird (2002) skrev i sin studie att kommersialiseringen av Internet har lett till att massutskick av e-post har nått epidemiska höjder då fler använder massutskick av e-post i marknadsföringssyfte. Medan marknadsförare strävar efter att nå ut till en större publik vill konsumenterna hitta sätt att undvika att bli måltavlor för massutskick. I studien belyste även Hird (2002) att företag är skeptiska till att skicka ut epost till kunder på grund av att det kan uppfattas som spam. Förutom de direkta kostnaderna som genereras av konsumtionen av resurser som bandbredd, bearbetning och lagringsutrymme finns det indirekta kostnader.
Vidare skrev Hird (2002) att massutskick av e-post faktiskt betraktas som ett missbruk av resurser, med tanke på att det är så pass resurskrävande.
Två exempel på att programmeringsspråk skiljer sig åt i mer än syntax och semantik är först ett experiment där en jämförelse mellan Java och PHP visade att Java hade snabbare minneshantering och kunde även hantera större antal samtidiga förfrågningar än PHP (Neves, Paiva, Durães, 2013), vilket tyder på att Java passar för webbapplikationer med hög trafik och där många samtidiga förfrågningar till servern görs. En annan studie utförd av Hericko et al.
Jämförde serialisering av objekt i Java samt .NET, där .NET jämfört med Java hade 65% - 80%
lägre svarstider för serialisering av objekt.
I ett experiment utfört av Bounnady, Phantavong, Pathoumvanh & Sihalath (2016) jämfördes PHP och ASP.NET i ett antal områden, där ett av områdena var att läsa/skriva data till externa filer. Experimentet gick till genom att webbsidor läste av data från filer innehållande 1.000.000 rader, och efter det skrevs det över till andra filer på servern. Samma studie visade även skillnaden mellan PHP och ASP.NET i databashantering, där tre olika operationer utfördes, Delete, Insert och Select, där 10.000 sparade objekt i databasen skulle tas bort, läggas in och hämtas.
Resultatet i studien utförd av Bounnady, Phantavong, Pathoumvanh & Sihalath (2016) visade
att ASP.NET utförde borttagning av data från databasen dubbelt så snabbt som PHP. Gällande
att införa data i databasen var PHP snabbare än ASP.NET och gällande att hämta data från
databasen var PHP även snabbare än ASP.NET där. Det kan vara värt att belysa att PHP
jämfördes med ASP.NET med två olika webbservrar, där den ena var IIS (Internet information
service) och den andra var Apache, medan ASP.NET endast använde IIS, vilket kan påverka
resultatet. Kombinationen PHP-Apache var i samtliga fall gällande databashantering snabbare
3
eller identiska med PHP-IIS. Asp Net var betydligt snabbare än bägge kombinationer PHP på att utföra hämtning/tilläggning av data, Asp Net utförde på 2 sekunder medan PHP- kombinationerna låg på dryga 4.5 sekunder. Gällande uppladdning av filer var bägge kombinationerna PHP snabbare än ASP.NET, där det skiljde allt från 1 tiondels sekund vid filer under 10 MB upp till dryga 2 sekunder vid filer över 100MB. Resultatet i studien av Bounnady et al (2016) visade att ASP.NET-IIS sammanlagt var snabbare än både PHP-IIS och PHP-Apache på utförandet av de uppgifterna nämnda tidigare i stycket.
Vemula, R (2017) undersökte .NET i förhållande till .NET Core, som är en utveckling av .NET.
Några förbättringar som gjorts vid utvecklandet av .NET Core i förhållande till .NET är att .NET Core har en http-förfrågnings pipeline som är mer lättviktig, där onödiga egenskaper tagits bort. På grund av ändringen av pipeline har .NET Core förbättrad prestanda jämfört med .NET. Med tanke på att syftet med detta arbete är att hitta vilken teknologi som är mest tidseffektiv är det därför rimligt att testa ASP.NET Core, istället för ASP.NET.
Denna studie har för avsikt att jämföra ASP.NET Core och PHP i avseende att använda dessa som ett epost-API. De aspekterna som kommer analyseras är svarstider för att skicka e-post utan bilagor, hämta epost med en specifik ID och uppdatera epost med en ID. För att kunna skicka e-post till flera mottagare samtidigt måste det vara möjligt för dessa e-post-API:er att hämta data från och lägga till data i en databas, genom http-metoder. Att under utvecklingens gång testa att utföra olika anrop är viktigt för att säkerställa att epost-API:et fungerar som förväntat, vilket kan göras genom Postman-applikationen. Postman beskrivs mer ingående senare i bakgrundskapitlet.
Experimentet kommer utföras hos företaget WinLas, med Winlas utrustning. Ett existerande e-post-API skrivet i PHP kommer att jämföras med Asp Net Core, som är ett annat programmeringsspråk som kan bidra till förbättrade svarstider för http-metoderna get, put &
post.
2.1 Webb-API
Webb-API benämns i denna studie som epost-API på grund av att det används för hantering
av e-post över webben. Ett epost-API tar emot en förfrågan av en klient, utför behandlingar
och returnerar ett svar till klienten, ofta beskrivet i JSON eller XML. Http bidrar med en enkel
applikationsmodell för utbyte av information mellan server och klient. Den vanligaste metoden
är att använda http för att leverera webbsidor för presentation av en webbläsare. Webb-API:er
exponeras för en stor mängd klienter som körs på många olika enheter, där varje klient har
olika förmågor. Http är väl anpassat för att hantera stora mängder klienter som körs på olika
enheter på grund av att det tillåter olika klienter att ta emot olika representationer för att möta
klientens behov. Det finns även fördelar med skalbarhet och utvecklingsbarhet för system som
direkt använder http. På grund av fördelarna med http är webb-API:er ett attraktivt val för
många system som byggs idag. På grund av att http ökar i popularitet och fler komponenter
använder det för att exponera sin funktionalitet är det även viktigt för komponenter inom
samma applikationsdomän att kunna kommunicera (Nielsen, Block, Tombaugh, Cain, Ge,
Corradini, 2011). Det epost-API som kommer skapas för detta arbete kommer att hantera
utskick av e-post, där olika http-metoder kommer att användas för att hantera resurser och på
så sätt även hantera data. POST kommer användas för att skicka förfrågning till webbserver
4
om att ta emot data, GET användas för att läsa/hämta och PUT till att uppdatera databasen.
Epost-API:et som ska skapas kan fungera som i figur 1. Klienten anropar API-Server, som verifierar nyckeln för att säkerställa att nyckeln är godkänd till att komma åt epost-API:et. Är nyckeln inte godkänd skickas felmeddelande till klienten, är nyckeln godkänd verifieras innehållet i data som ska skickas. En validering av innehållet sker och vid ej godkänd validering skickas felmeddelande till klienten, är valideringen godkänd görs ett försök att skicka eposten.
Epost skickas i sin tur genom en epostklient. Valet av epostklient till detta arbete är inte av högsta vikt på grund av att syftet med arbetet är att utreda vilket av programmeringsspråken som lämpar sig bäst ur en svarstidssynpunkt för ett epost-API, inte att hitta kombinationen av all teknologi som ger lägsta möjliga svarstider. En sista validering, denna gång av eposten, kolla om eposten kan skickas eller inte, då eposten inte kan skickas får klienten ett felmeddelande och vid lyckad sändning av epost returneras epostens ID.
Figur 1. Flödesdiagram över hur epost-API:et fungerar
5
2.2 PHP
PHP är ett skriptspråk på serversidan som skapades av Rasmus Lerdof år 1995 som en samling av Common Gateway Interface (GCI) Perlskript (Neves et al, 2013). Istället för att ett PHP- program körs på en persondator för att en person ska använda det, körs det vanligtvis på en webbserver där personer som använder webbläsare kan komma åt programmet. När en webbserverdator läser ett PHP-program, som är instruktioner skrivna i PHP, följer PHP-motorn instruktionerna. PHP är gratis att använda, plattformsoberoende och gömmer dess komplexitet.
Användaren kan tillexempel kan skapa kraftfulla e-handelsmotorer som hanterar miljontals kunder eller små webbsidor med lite funktionalitet. När PHP används för mindre projekt bryr PHP sig inte om att påpeka för användaren om saker som endast är relevanta i stora system.
Behöves cachning, bibliotek eller dynamisk bildgenerering till ett projekt finns det tillgängligt, behövs det inte till projektet behöver användaren inte bry sig om det. PHP finns idag på över 200 miljoner webbsidor, där till exempel. Facebook, Wikipedia och Yahoo är några av dessa (Sklar, 2016). PHP kommer att användas i denna studie till ett av de två e-post-API:er som ska skapas, där koden skriven i PHP kommer att utföra olika förfrågningar till server om att hantera resurser och data. En sådan hantering av data kan vara att hämta data från databasen, exempelvis hämta all epost. En sådan funktion visas i figur 1 nedan.
public function mail() {
$allMail = $this->mail_model->getAllMail();
echo json_encode($allMail) }
Figur 1. Get-funktion för att hämta all epost lagrad i databasen.
2.3 C#
C# är ett objektorienterat programmeringsspråk där programmerare kan utveckla olika typer av säkra och robusta applikationer som körs genom .NET ramverket. Det går till exempel att skapa Windows klient-applikationer, XML-webbtjänster, distribuerade komponenter, klient- serverapplikationer, och mycket mer (Proksch, Amann, Nadi, Mezini, 2016). C# körs på .NET- ramverket med .NET Common Language Runtime, som är en komponentbaserad miljö. C#
designades för att göra komponentskapande enklare. Det är ett komponentcentrerat språk där alla objekt skrivs som komponenter, och komponenterna är i centrum av alla händelser.
Komponentkoncept som egenskaper, metoder och events är så kallade förstaklassinvånare i
språket och i exekveringsomgivningen. I en komponentbaserad värld är det viktigt att skapa
mjukvara som är robust och hållbar (Gunnerson, 2001). C# kommer att användas i denna studie
för skapandet av ett e-post-API som kommer hantera resurser och data genom att använda http-
metoder som GET, POST & PUT.
6
2.4 ASP.NET Core
ASP.NET Core är ett nytt plattformsoberoende ramverk med öppen källkod som är till för att skapa moderna molnbaserade applikationer, som webbapplikationer, Internet of Things- applikationer och mobil backend. ASP.NET Core körs på .NET Core-ramverket men även på .NET-ramverket. Operativsystemen som är kompatibla att köra en ASP.NET Core-applikation är Windows, Linux och macOS. Användaren kan skapa http-tjänster med full support för innehållsförhandling genom att använda inbyggda formatterare som JSON, XML och RESTful-tjänster. ASP.NET kombinerar de främsta egenskaperna hos ASP.NET MVC och Web API tillsammans i ett enda ramverk. Innan ASP.NET MVC och Web API kombinerades till ett ramverk behövde användarna arbeta med flera ramverk och koncept samtidigt, vilket kunde skapa förvirring (Oliveira & Bruchet, 2017). ASP.NET Core kommer att användas i denna studie som ramverk för C# för att skapa ett e-post-API och utföra http-metoder för att hantera resurser och data. Http-metoden GET kan med C# i ASP.NET Core-ramverket se ut enligt figur 2 nedan.
[HttpGet]
public async Task<IActionResult> Get() {
var mails = _service.GetAllMails();
return Ok(mails);
}
Figur 2. GET-metod i ASP.NET Core som hämtar all epost som finns lagrad i databasen.
2.5 Postman
Postman är ett verktyg för API:er och används för att testa, utveckla och modifiera API:er.
Http-förfrågningar som POST, GET & PUT kan göras genom postman och även integrationstester kan skapas för att säkerställa att ett API fungerar som förväntat och returnerar responstider när en API-förfrågan görs (Ranga & Soni, 2019). Postman används i detta arbete som testverktyg i utvecklingsfasen av det epost-API som ska skapas. Processen för att skicka en epost genom postman kan ske genom att då en epost skickas från Postman gör Postman ett API-anrop till epost-API:et som i sin tur skickar eposten via en epostklient, exempelvis Amazon Simple Email Service. En mätning av svarstider där API-anrop görs av postman sker från klienten där svarstider för utfört anrop presenteras i Postman-applikationen. Problemet med att mäta från klient, genom exempelvis Postman, är att ping spelar roll. Ping är beroende av nätverksavståndet mellan klient och server, vilket ökar då en mätning sker från klient och inte från en server och kan skapa en varians i resultaten. Mätning från klienten är en enkel process att beskriva och återskapa och är därför passande för experimentet. För att minska varians i resultaten kommer tusentals anrop utföras.
2.5.1 API-anrop från Postman
Ett anrop till ett API från Postman går till genom att skriva in korrekt URL till API:et och
välja en lämplig metod, exempelvis ”POST”, se figur 3.
7
Figur 3. Post-anrop med angiven URL som kan utföras för utskick av epost i Postman.
Ett POST-anrop kan exempelvis behöva en avsändare och en mottagare angivet, därefter kan epost-API:et skicka epost via en epostklient, som exempelvis Amazon Simple Email Service.
Under fliken ”Body” väljs ”raw” samt ”JSON”, därefter skrivs avsändare och mottagare in i JSON-format, se figur 4.
Figur 4. Postman-anrop med angiven avsändare och mottagare.
När metod, korrekt URL till API och avsändare samt mottagare är angivna korrekt, är det dags att skicka anropet genom att trycka på ”SEND”, se figur 3. Det API som anropas från Postman med ”POST” som vald metod, kommer exekvera postmetoden i API:et. En sådan metod kan se ut som i figur 5.
Figur 5. Post-metod med validering skriven i ASP.NET Core för utskick av epost.
Resultatet av anropet syns i figur 6, där status visas som ”200 OK”, vilket betyder att anropet gick igenom, responstiden för anropet som var 836ms och storleken 183B. I postmans body representerar ”5” den id som skickad epost har.
Figur 6. Resultat av ett get-anrop på en epost med angiven id i Postman.
8
3 Problemformulering
I Bounnady, Phantavong, Pathoumvanh & Sihalath (2016) studie jämfördes tidsåtgången för en rad olika utföranden mellan PHP och ASP.NET, där ASP.NET sammanlagt hade lägre svarstider än PHP vid utförandet av specifika uppgifter, oavsett om PHP använde IIS eller Apache som webbserver. Några av mätningarna i studien visade att ASP.NET var snabbare i form av mindre tidsåtgång jämfört med PHP vid borttagning av data från en databas, medan PHP var snabbare än ASP.NET på att hämta och föra in data i databasen. Hantering av data genom införande, hämtning och borttagning kan utföras genom http-metoder, där GET, PUT, POST och DELETE används för hantering av data. Studien utförd av Bounnady et al (2016) går därför att efterliknas i denna studie, genom att använda dessa http-metoder för att hantera data. Vi kommer att jämföra två e-post-API:er som utför dessa http-metoder och där tidsåtgången för dessa kommer mätas.
I boken skriven av Vemula (2017) belystes förbättringar som gjorts vid utvecklandet av ASP.NET Core jämfört med ASP.NET, där ASP.NET Core hade en rad förbättringar vilket resulterar i att det är snabbare än ASP.NET. Med tanke på förbättrade prestandan som Vemula (2016) beskrev plus att ASP.NET Core släpptes 2016 och studier rörande ramverket är inte omfattande, är det mer rimligt att testa ASP.NET Core än ASP.NET i denna studie.
Hird (2002) skrev i sin studie att massutskick är resurskrävande och benämnde det som missbruk av resurser. Problemet är att massutskick av e-post är en tidskrävande process där, med tanke på att många e-postadresser ska hämtas genom förfrågningar från klient som används för att få en resurs från servern, som sedan letar efter efterfrågade data och returnerar den, detta genom en GET-metod. Resultatet av jämförelsen av PHP och Asp.NET i studierna utförda av Neves, et al. (2013), Bounnady et al. (2016) samt Herick et al. (2003) visar på att det finns en skillnad mellan språken och med denna studie kommer denna studie att testa vilket av ASP.NET Core och PHP som kan ge mest tidseffektiva resultat. Detta kommer att göras genom att ta fram två lösningar (API:er) som är identiska i funktionalitet och mäta dessa i identisk omgivning.
Denna studie kommer undersöka vilket av ASP.NET Core och PHP som är det mest tidseffektiva för ett e-post-API och kommer därför använda samma webbserver för bägge två, då två olika webbservrar kan påverka resultaten. Eftersom C# .NET med IIS webbserver visade sig vara den mest tidseffektiva teknologin i Bounnady et al. (2016)’s kommer denna studie även använda IIS webbserver, detta för att undersöka om det samma gäller för ASP.NET Core.
Tidsåtgången för http-metoder som get, put & post, utskick av enskilda e-post utan bilagor, kommer att mätas.
3.1 Syfte, fokus & hypotes
Syftet med detta arbete är att utreda vilket programmeringsspråk av PHP och ASP.NET Core
som är mest lämplig utifrån de mål som satts upp. Vilket språk som är mest lämplig utifrån de
mål som satts upp syftar på vilket av Asp Net Core och PHP som kan utföra http-metoderna
get, put & post mest tidseffektivt.
9
Anledningen till att arbetet kommer fokusera på svarstider är för att syftet med det API som ska skapas är att analysera prestanda vid utförande av http-metoderna get, put & post. Tiden det tar att utföra http-metoderna get, put & post kommer att mätas, då svarstiden på dessa visar hur lång tid det tar att hämta e-postadresser från databasen, lägga till e-postadresser och skicka epost.
Hypotesen är att ASP.NET Core kommer vara mer tidseffektivt vid utförandet av http-
metoderna get, put & post. Med tanke på ändringen i http-pipeline som Vemula (2017) beskrev
om i sin bok, är ASP.NET Core mer tidseffektivt än föregångaren ASP.NET. I studien utförd
av Bounnady et al (2016) var PHP mer tidseffektivt än ASP.NET vid införande av data samt
på att hämta data, förändringen i http-pipeline bör ändra detta förhållande till fördel för
ASP.NET Core.
10
4 Metod
Ett experiment är en empirisk undersökning och kan vara teknikorienterat eller fokusera på mänskliga faktorer. Ett teknikorienterat experiment fokuserar på tekniken istället för mänskliga faktorer (Wohlin et al. 2012). Experiment med fokus på människor kan orsaka problem som att en människas beteende inte är konstant vid ett specifikt tillfälle, vilket orsakar en förlust av kontroll på experimentet. Två epost-API:er ska skapas i denna studie och målet är att undersöka vilket av de utvalda programmeringsspråken som kan bidra till kortast tidsåtgång för utförda uppgifter, och då resultatet av en utförd uppgift kan vara en tiondels sekund är det svårt för användare att uppfatta möjliga skillnader. Experiment används för att testa en hypotes, möjliggöra slutsatser och skapa kontroll över specifika situationer. Det är inte enkelt att genomföra experiment, och det behövs därför förberedas, utföras och analyseras ordentligt.
Fördelar med experiment är att det går att kontrollera objekt, subjekt och instrumentering, exempelvis att kontrollera vad för hårdvara experimentet körs på, riktlinjer och mätinstrument.
Genom att organisera händelser i ett laboratorium kan en simulering av funktionen i en verklig situation skapas som resulterar i kontroll.
Experiment har använts i studier utförda av Neves, et al. (2013), Bounnady et al. (2016) samt Herick et al. (2003) där jämförelser av svarstider för olika programmeringsspråk har varit i fokus. Arbetet går ut på att jämföra svarstider för två olika programmeringsspråk, vilket gör experiment lämpligt för arbetet.
Det hade varit möjligt att kombinera experimentet med en användarstudie, som är ett sätt att samla information om användarbeteenden, från användare (Wohlin et al. 2012). Att kombinera experiment och användarstudie kan ge en förståelse kring vilket programmeringsspråk som upplevs som det mest lämpliga alternativet enligt användare, men med tanke på tidsramen kommer det endast utföras experiment. I ett experiment studeras resultatet av att ändra en eller flera variabler i en process, antingen är variablerna oberoende eller beroende av varandra (Wohlin et al. 2012). Experimentet som kommer utföras har en beroende variabel i form av svarstider för utförda anrop beskrivna i millisekunder och oberoende variabler i form av programmeringsspråk och ramverk.
En annan metod är en fallstudie. Fallstudier undersöker vissa delar av ett projekt under en viss tid. Ett problem med fallstudier är att det är svårt att repetera en undersökning eftersom det endast är applicerbart för ett visst fall (Wohlin et al. 2012). Kontroll av exempelvis programvara och hårdvara är nödvändigt för arbetet och på grund av det är svårt att kontrollera dessa inom en fallstudie är det inte lämpligt för arbetet.
4.1 Vetenskaplig metod
Den vetenskapliga metod som kommer användas är experiment, som kommer vara teknikorienterat. Anledningen till att experimentet är teknikorienterat är på grund av att mätningarna ska bidra till att klargöra vilket av programmeringsspråken som lämpar sig bäst ur en svarstidssynpunkt för ett epost-API, inte användares synpunkter och upplevelser av dessa två epost-API:er.
Ett redan existerande e-post-API skrivet i PHP används som baseline och variabeln som ändras
är språket, från PHP till ASP.NET Core. Arbetet kommer undersöka svarstider för Get, Put och
Post-anrop på Asp Net Core och PHP-API:et.
11
Tidsåtgången för olika http-metoder kommer att mätas, dessa är POST, GET & PUT, där den totala total svarstiden för hela anropet mäts, vilket innebär att Postman anropar epost-API:et som i sin tur skickar eposten via Amazon Simple Email Service. Lika många anrop kommer utföras på respektive epost-API och medelvärdet av anropen kommer presenteras i grafer och tabeller.
En möjlig faktor som kan påverka svarstiden för utskick av epost samt hantering av anrop av server är meddelandets storlek och omfång samt om meddelandet innehåller bilder eller inte.
Exempelvis skulle PHP kunna hantera små meddelanden bättre än ASP.NET Core ur en svarstidssynpunkt. Detta arbete kommer inte ta meddelandes storlek i beaktning. Utskick av enskilda e-post kommer att mätas, där två epost-API:er i skrivna i olika programmeringsspråk möjligtvis hanterar dessa olika bra ur en svarstidssynpunkt.
Ett experiment är en empirisk undersökning och kan bl.a. användas för att testa en hypotes, möjliggöra slutsatser och skapa kontroll över specifika situationer. Det är inte enkelt att experimentera, och det behövs därför förberedas, utföras och analyseras ordentligt. Fördelar med experiment är att det går att kontrollera objekt, subjekt och instrumentering, till exempel att kontrollera vad för hårdvara experimentet körs på, riktlinjer och mätinstrument. Genom att organisera händelser i ett laboratorium kan en simulering av funktionen i en verklig situation skapas som resulterar i kontroll. I ett experiment studeras resultatet av att ändra en eller flera variabler i en process, antingen är variablerna oberoende eller beroende av varandra (Wohlin et al. 2012). Experimentet som kommer utföras har en beroende variabel i form av svarstider, som definieras av tidsåtgången för utförandet av givna http-metoder samt tidsåtgången för massutskick av e-post utan bilagor. Oberoende variabler är programmeringsspråk och ramverk.
För att mätningarna ska ske under så lika former som möjligt kommer optimeringen ske genom att koden skrivs på ett så likt sätt som är möjligt, där funktionaliteten samt omgivningen kommer vara identisk, då en skillnad på dessa hade påverkat resultaten av mätningarna.
4.2 Etiska aspekter
Det är viktigt att experimentet går att replikera, därför kommer all nödvändig information om
vilka steg som krävs för att utföra experimentet att belysas, detta inkluderar källkod, hård och
mjukvara. All dokumentation rörande experimentet kommer att publiceras på GitHub. Hela
projektet kommer att dokumenteras för att säkerställa replikerbarhet. Det är viktigt med
replikerbarhet för att finna nytta i arbetet i framtiden (Wohlin et al. 2012). På grund av att
projektet innehåller utvecklandet av ett API för e-post där det bland annat görs massutskick av
e-post, finns det vissa etiska aspekter som är värda att ta i beaktning. En av dessa aspekter är
att massutskick av e-post tidigare varit ett problem på internet, där phishing-attacker genomförs
genom att skicka e-post till många mottagare och lurar dessa att det är ett autentiskt e-post från
ett välkänt företag (Suriyal, Saravanan, Thangavelu, 2009), där offren kan bli lurade att ge ut
sina bankuppgifter. Att publicera källkoden på GitHub blir i detta projekts fall en svaghet,
eftersom det utgör en risk, istället för i många andra fall där öppen källkod ofta är en styrka.
12
5 Genomförande
I detta kapitel beskrivs hur genomförandet går till samt vilka metoder som valts och hur dessa ska användas. För att gå vidare till planering och utveckling av den tekniska artefakten behövs det sökas efter relaterad litteratur. Den relaterade litteraturen står som grund för arbetet, då utvecklandet av epost-API:er kan gå till på olika sätt är det viktigt att lista litteraturen som används i utvecklingsprocessen för att underlätta för andra personer att replikera experimentet.
5.1 Litteraturstudie
Innan experimentet kan utföras är det nödvändigt att utföra en litteraturstudie. Litteraturstudien ska samla in kunskap och bidra med inspiration i syfte att skapa en förståelse och en plan kring utförandet och genomförandet av experimentet. Mängden studier som behandlar jämförandet av epost-API:er skrivna i olika programmeringsspråk är liten, trots detta kan liknande studier bidra med nyttig information. Hemsidor används som komplement till studier vid implementation av kod gällande experimentet.
För att skapa en fungerande teknisk artefakt i Asp Net Core är det viktigt att förstå grunderna i C#, som är programmeringsspråket som används för att skapa den tekniska artefakten i detta arbete. Troelsen, J & Japikse, P (2017) bok ”Pro C# 7” belyser viktiga aspekter inom objektorienterad programmering och har använts som hjälpmedel för utveckling av den tekniska artefakten.
L, Richardson & S, Ruby (2007) ger i sin bok ”Restful Web Services” nyttig information kring hur ett REST-API fungerar, vilket bidrog till en förståelse för hur utvecklingen av epost-API:et kunde gå till. L, Richardson & S, Ruby (2007) inleder med att skriva om hur webben fungerar, vilket var väldigt bra att förstå innan skapandet av epost-API:et.
PHP och ASP.NET Core berördes i flera olika studier som presenterades i bakgrundskapitlet.
Studien skriven av Bounnady et al. (2016) jämförde bägge språken gällande datahantering och information kring vilka typer av metoder som finns för att hantera data hämtas från denna studie, vilka är GET, PUT och POST. För att mäta svarstider för http-metoder som hämtar, lägger till och uppdaterar objekt för att sedan spara till databasen krävs det att epost-API:et har en databaskoppling. Databaskopplingen gjordes genom att ta del av information från Microsoft(docs.microsoft.com), då Microsoft är utvecklarna av ASP.NET Core finns mycket information gällande utveckling med deras produkter på Microsofts hemsida(docs.microsoft.com).
Utöver databaskoppling behövs även funktionalitet för mappning mellan objekt i mjukvaran
till tabeller och kolumner i en databas, detta gjordes med hjälp av Entity Framework Core(EF
Core), där dokumentation om EF Core hämtades på EF Cores
hemsida(entityframeworkcore.com) samt i Joshi, B (2019) bok ”Asp Net Core Web API”, som
ger konkreta exempel på hur Entity Framework interagerar med databasen. För att hämta, lägga
in och uppdatera objekt till och från databasen krävs det att mjukvaran har beskrivna http-
metoder, även här användes dokumentationen från Microsoft(docs.microsoft.com) som hjälp
till att utforma dessa på ett korrekt sätt.
13
5.2 Pilotstudie
För att möjliggöra om artefaktlösningen kan ge svar på hypotesen för studien gjordes en pilotstudie. Pilotstudien utfördes genom att utföra 100 anrop av Get, Post och Put. Anropen för ASP NET Core API:et utfördes med genom att skapa en ny klient som utför 100 anrop och skriva svarstiden av hela anropen till en textfil. Get-anropen utfördes genom att söka efter en epost med ett givet ID, Post-anropen utfördes genom att skicka en epost per iteration och Put- anropen gjordes genom att uppdatera en epost med en extern id.
5.2.1 Pilotstudie resultat
Figur 7. 100 Get-anrop för ASP.NET Core & PHP-API:et
Figur 8. 100 Put-anrop för ASP.NET Core & PHP-API:et
0 5 10 15 20 25 30
1 5 9 13 17 21 25 29 33 37 41 45 49 53 57 61 65 69 73 77 81 85 89 93 97
100 Get-anrop (ms)
Asp Net Core PHP
0 5 10 15 20 25 30
1 5 9 13 17 21 25 29 33 37 41 45 49 53 57 61 65 69 73 77 81 85 89 93 97
100 Put-anrop (ms)
Asp Net Core PHP
14
Figur 9. 100 Post-anrop för ASP.NET Core & PHP-API:et.
Figur 11. Medelvärdet för 100 Get-anrop med standardavvikelse
0 5 10 15 20 25 30
1 5 9 13 17 21 25 29 33 37 41 45 49 53 57 61 65 69 73 77 81 85 89 93 97
100 Post-anrop (ms)
Serie1 Serie2
0 1 2 3 4 5 6 7
Medelvärde Get-anrop med Standardavvikelse
Asp Net Core PHP
15
Figur 12. Medelvärdet för 100 Get-anrop med standardavvikelse
Figur 13. Medelvärdet för 100 Get-anrop med standardavvikelse
Resultatet visar att det är möjligt att genomföra mätningar både på den skapade artefakten samt det epost-API som tidigare är skrivet i PHP och används för jämförelse i detta arbete.
Mätningarna visar att alla tre metoder, Get, Put och Post har ett initialt större mätvärde vid första anropet än vad anrop till PHP-API:et har, trots det första värdet är medelvärdet för 100 mätpunkter lägre för Asp Net Core-API:et. Standardavvikelsen visar att det är större avvikelser i Asp Net Core-mätpunkterna än respektive i PHP. Alla svarstider i diagrammen är angivna i millisekunder. Eftersom mätningen för Get-anropen går till genom att söka efter en epost med en angiven id, som i samtliga fall är identiska, finns det en möjlighet att cashning skulle kunna påverka resultaten. Mätresultaten blir, på grund av att get-anropen sker på samma epost, individuella. Det skulle exempelvis efter några utförda anrop kunna påverka mätresultaten i
0 1 2 3 4 5 6 7
Medelvärde Put-anrop med Standardavvikelse
Asp Net Core PHP
0 1 2 3 4 5 6 7
1
Medelvärde Post-anrop med Standardavvikelse
Asp Net Core PHP
16
den grad att samtliga mätresultat nästan är identiska. För att säkerställa att cashning inte spelar någon roll och att mätresultaten inte är individuella, skulle det utföras en mätning som söker efter randomiserad epost eller där varje epost som ska hämtas endast kan hämtas en gång och ett randomiserat nummer avgör vilken epost som hämtas.
5.3 Progression
I detta kapitel beskrivs progressionen av artefakten som skapats för detta arbete. Artefakten består av tiotals filer och därför kommer endast vitala delar att beskrivas. Beskrivningen av källkod kommer att kompletteras med bilder för att förtydliga. Samtlig källkod finns tillgänglig på GitHub.
5.3.1 Modellklass
Det första som gjordes var att lägga till en modellklass. Modellklassens innehåll representerar data som API:et hanterar. Klasserna som skapats är relaterade till vad en epost innehåller, detta syns på figur 14 nedan.
public int Id { get; set; }
public string ExternalId { get; set; }
public MailStatus Status { get; set; } = MailStatus.Unsent;
public DateTime CreatedTime { get; set; } public DateTime? SentTime { get; set; } public string TrackerId { get; set; } public DateTime? OpenTime { get; set; } public string IPAddress { get; set; } public string Receiver { get; set; } public string Sender { get; set; } public string ReplyTo { get; set; } public string Subject { get; set; } public string Body { get; set; }
public string ErrorStatus { get; set; }
Figur 14. Modellklass innehållande metoder relaterade till e-post.
1Klassen innehåller även en valideringsmetod för att säkerställa att eposten uppfyller kraven för en epost, exempelvis att en epost måste innehålla ”@” och att det finns en sändare och en mottagare, se figur 15 nedan.
1
https://github.com/WinLas/Mail-API/commit/d96256d
17
public bool ValidateEmail(string emailAddress) {
try {
var mailAddress = new MailAddress(emailAddress);
}
catch (Exception ex) {
return false;
}
return true;
}
public bool IsValid() {
return !string.IsNullOrEmpty(Body) && ValidateEmail(Receiver) &&
ValidateEmail(Sender);
} }
Figur 15. Valideringsmetoder för epost-adresser.
5.3.2 Databaskoppling
Efter skapandet av en modellklass gjordes en databaskoppling. Databaskopplingen gjordes med ett ramverk för mappning av data som heter Entity Framework Core, se figur 16.
2public class MailDbContext : DbContext {
public MailDbContext(DbContextOptions<MailDbContext> options) : base(options)
{ } }
Figur 16. Databaskoppling med entity framework core.
5.3.3 Epostservice
När en databaskoppling och en modellklass skapats behövs även en klass innehållande metoder som utför handlingar i API:et. Dessa metoder skapades i en egen klass för att öka läsbarheten av koden, istället för att placera allt i controllern som hanterar http-metoderna. Figur 17 visar metoden för att lägga till en epost som är redo att skickas.
public Mail UpdateMail(Mail mail) {
var dbMail =
_context.Mails.FirstOrDefault(m =>
m.ExternalId.Equals(mail.ExternalId));
dbMail.Status = (MailStatus)2;
dbMail.ErrorStatus = mail.ErrorStatus;
_context.Mails.Update(dbMail);
_context.SaveChanges();
return dbMail;
}
Figur 17. Metod för att uppdatera en epost då en epost skickats.
2
https://github.com/WinLas/Mail-API/commit/37f8374
18 5.3.4 Controller
I detta arbete finns två controllers, en mail-controller och en track-controller. En controller i ett epost-API används för att hantera http-förfrågningar och bör namnges efter vad den utför, vilket är anledningen till namnet MailController.
// GET: api/Mail/1 [HttpGet("{id}")]
public async Task<IActionResult> Get(int id) {
var mailItem = _service.GetById(id);
if(mailItem == null) {
return NotFound("The email with given id could not be found.");
}
return Ok(mailItem);
}
Figur 18. Get-metod för att hämta en epost med en angiven id.
5.3.5 Pixeltrackning
En lösning för att kontrollera om en epost öppnats av mottagaren är att använda pixeltracking.
Det går till genom att varje skickad epost innehåller en genomskinlig bild eller gif, som registrerar att en epost öppnats då bilden eller gif:en exponeras för mottagaren. Därför skapades en till controller, kallad TrackController.
3Detta visas på figur 19 nedan.
[HttpGet("{trackingId}")]
public async Task<FileContentResult> getPixel(string trackingId) {
//get request parameters
var parameters = Request.Query.Keys.ToDictionary(k => k, k => Request.Query[k]);
//get request headers
var headers = Request.Headers.Keys.ToDictionary(k => k, k => Request.Query[k]);
await Task.Factory.StartNew((data) =>
{
var dataDictionary = data as IDictionary<string, StringValues>;
var dbMail = _context.Mails.FirstOrDefault (m => m.TrackerId.Equals(trackingId));
dbMail.OpenTime = DateTime.Now;
dbMail.Status = MailStatus.Opened;
_context.Mails.Update(dbMail);
_context.SaveChanges();
},
parameters.Union(headers).ToDictionary(k => k.Key, v => v.Value)).ConfigureAwait(false);
//return pixel return _pixelResponse;
}
Figur 19. Metoden tar emot variabeln trackingId och sätter den till att eposten öppnats när endpointen har anropats.
3
https://github.com/WinLas/Mail-API/commit/37f8374
19
För att pixeltrackningen ska fungera behöver varje epost innehålla en gif, koden syns på figur 20 nedan.
public void SetPixel(string url) {
string trackingId = Guid.NewGuid().ToString();
TrackerId = trackingId;
string imageHtml = "<img src='" + url + "/api/track/" + trackingId + "'>";
Body = Body + imageHtml;
}
Figur 20. Metoden tar emot en url som innehåller protokoll, domännamn och sökväg samt lägger till en gif i varje eposts body.
5.3.6 Batchkörning
Utskick av epost sker genom en batchkörning
4, en bakgrundstjänst som hela tiden letar efter epost med status ”unsent” och skickar iväg dessa till mottagaren. Bakgrundstjänsten består av två filer, där den ena filen letar efter epost som inte skickats, och den andra filen loggar händelser, exempelvis om bakgrundstjänsten är igång eller har misslyckats med att starta. För att bakgrundstjänsten ska komma åt databasen där epost sparas och genom detta skicka iväg epost skapades även en databaskoppling. Metoden för att skicka epost syns i figur 21 nedan.
protected override async Task ExecuteAsync(CancellationToken stoppingToken) {
while (!stoppingToken.IsCancellationRequested) {
try {
await _service.SendUnsentMail();
}
catch (Exception e) {
_logger.LogError(e, "Could not send email.");
}
await Task.Delay(15000, stoppingToken);
} }
Figur 21. Metod som utförs av bakgrundsprocessen.
4
https://github.com/WinLas/Mail-API/commit/a29d9ad
20
6 Utvärdering
Pilotstudien jämförde svarstider för API-anropen get, put och post och resultatet visade att Asp Net Core hade ett högre första mätvärde än PHP, trots detta var medelvärdet mindre för Asp Net Core än för PHP. Pilotstudien visade även att det var större skillnader på de olika mätvärdena för Asp Net Core än respektive för PHP, vilket resulterar i en större standardavvikelse. Det är intressant att undersöka om det fortsätter i samma trend när antal anrop ökas, från 100 till 10 000. I detta kapitel kommer all hård och mjukvara som använts för experimentet samt resultaten av mätningarna presenteras.
6.1 Hård- och Mjukvaruspecifikation
Hårdvara Version
Modell HP ProBook 450 G4
CPU Intel Core i7-7500U @ 2.7GHz
RAM 16gb 2133MHz DDR4
Hårddisk 256gb SSD
Server Version
CPU Intel Xeon E3-12xx v2 @ 2.4GHz (virtuell)
RAM 8gb
Hårddisk 250gb Non-SSD
Operativsystem Windows server 2016
MySQL 8
PHP 7.4
Asp Net Core 3
Entity framework core 3
21
6.2 Presentation av undersökning
En mätserie består av 10 000 mätpunkter och varje epost-API testas med tre olika typer av förfrågan, dessa är get, put och post. Sammanlagt utfördes således 30 000 anrop till respektive epost-API. Resultaten presenteras i linjediagram som beskriver varje enskild mätpunkt, stapeldiagram med medelvärdet av de 10 000 anrop som utförts med tillhörande standardavvikelse och slutligen anova-tester. Anova-test är till för att urskilja om skillnaden på mätserier är statistiskt signifikant eller inte, vilket avgörs med hjälp av p-värdet som anova- testet producerar. Då p-värdet är lägre än 0.05 går det med 95% säkerhet säga skillnaden på mätserierna är statistiskt signifikant.
6.2.1 Testfall 1 – 10 000 get-förfrågan
I Testfall 1 mäts svarstiden för varje enskilt get-anrop upp till 10 000 get-förfrågan.
Mätningarna genomförs genom att en klient skapas i respektive programmeringsspråk, Asp Net Core och PHP, där varje klient itererar 10 000 anrop och skriver dessa till en textfil. När 10 000 anrop är utförda avslutas metoden. I Figur 22, 23 & 24 nedan presenteras resultatet.
Figur 22. Resultat av 10 000 get-förfrågan där en epost med en specifik id hämtas.
0 5 10 15 20 25 30
1 335 669 1003 1337 1671 2005 2339 2673 3007 3341 3675 4009 4343 4677 5011 5345 5679 6013 6347 6681 7015 7349 7683 8017 8351 8685 9019 9353 9687
10 000 Get-anrop (ms)
Asp Net Core PHP
22
Figur 23. Resultat av 10 000 get-förfrågan där medelvärdet visas med standardavvikelse.
SAMMANFATTNING
Grupper Antal Summa Medelvärde Varians
Asp Net Core 10000 13419,22 1,34192233 0,937052888
PHP 10000 50007,37 5,000737 0,659295236
ANOVA
Variationsursprung KvS fg MKv F p-värde F-krit
Mellan grupper 66934,62395 1 66934,62395 83859,68312 0 3,841923866
Inom grupper 15961,8849 19998 0,798174062
Totalt 82896,50885 19999
Figur 24. Anovatest för get-anrop med p-värdet noll.
6.2.2 Testfall 2 – 10 000 put-förfrågan
I Testfall 2 mäts svarstiden för varje enskilt put-förfrågan upp till 10 000 put-förfrågan.
Mätningarna genomförs genom att en klient skapas i respektive programmeringsspråk, Asp Net Core och PHP, där varje klient itererar 10 000 anrop och skriver dessa till en textfil. Put- förfrågan utförs genom att uppdatera en epost med en extern id, och sparar det till databasen.
Resultatet av mätningarna syns på figur 25, 26 & 27. Det utförda anova-testet i figur 27 visar att medelvärdet hos Asp Net Core är mer än 5 gånger så litet som respektive hos PHP.
Variansen är nästan dubbelt så stor för anropen till PHP som för anropen till Asp Net Core- API:et. P-värdet är även för put-anropen noll, vilket betyder att skillnaden är signifikant.
0 1 2 3 4 5 6 7
Get-anrop medelvärde (ms)
Asp Net Core PHP
23
Figur 25. Resultat av 10 000 put-förfrågan där en epost uppdateras med en extern id.
Figur 26. Resultat av 10 000 put-förfrågan där medelvärdet visas med standardavvikelse.
SAMMANFATTNING
Grupper Antal Summa Medelvärde Varians
Asp Net Core 10000 10391,06 1,03910553 0,533277386
PHP 10000 52211,23 5,221123 0,984356024
ANOVA
Variationsursprung KvS fg MKv F p-värde F-krit
Mellan grupper 87446,3506 1 87446,3506 115240,4131 0 3,841923866
Inom grupper 15174,81647 19998 0,758816705
Totalt 102621,1671 19999
Figur 27. Anova-test för put-förfrågan med p-värdet noll.
0 5 10 15 20 25 30
1 335 669 1003 1337 1671 2005 2339 2673 3007 3341 3675 4009 4343 4677 5011 5345 5679 6013 6347 6681 7015 7349 7683 8017 8351 8685 9019 9353 9687
10 000 Put-anrop (ms)
Asp Net Core PHP
0 1 2 3 4 5 6 7
Put-anrop medelvärde (ms)
Asp Net Core PHP
24 6.2.3 Testfall 2 – 10 000 post-förfrågan
Sista typen av anrop som utförs i detta arbeta är post-anrop. Ett post-anrop går till genom att en epost med en avsändare, mottagare och body genereras och en genomskinlig gif läggs till i varje eposts body, med syftet att spåra om en epost blivit öppnad eller inte. Resultatet av post- anropen syns i figur 28,29 & 30. Anova-testet i figur 30 visar att medelvärdet för postanrop gjorda på Asp Net Core är drygt fem gånger så litet som respektive på PHP medan variansen är större för Asp Net Core. P-värdet är även här 0, vilket visar på att skillnaden är signifikant.
Figur 28. Resultat av 10 000 post-anrop där en epost genereras och skickas.
Figur 29. Resultat av 10 000 post-anrop där medelvärdet visas med standardavvikelse.
0 5 10 15 20 25 30
1 335 669 1003 1337 1671 2005 2339 2673 3007 3341 3675 4009 4343 4677 5011 5345 5679 6013 6347 6681 7015 7349 7683 8017 8351 8685 9019 9353 9687
10 000 Post-anrop (ms)
Asp Net Core PHP
0 1 2 3 4 5 6 7
Post-anrop medelvärde (ms)
Asp Net Core PHP
25 SAMMANFATTNING
Grupper Antal Summa Medelvärde Varians
Asp Net Core 10000 10445,24 1,04452398 1,011901858
PHP 10000 51595,58 5,159558 0,832298614
ANOVA
Variationsursprung KvS fg MKv F p-värde F-krit
Mellan grupper 84667,52493 1 84667,52493 91820,305 0 3,841923866
Inom grupper 18440,16052 19998 0,922100236
Totalt 103107,6855 19999
Figur 30. Anova-test för post-anrop med p-värdet noll.
6.3 Analys
Resultaten för testfallen som presenterats i föregående kapitel kommer nu att analyseras. De resultat som presenterades i testfall 1 visar att det finns en skillnad på svarstiderna för Asp Net Core och PHP. Asp Net Core hanterade hämtning av data snabbare än vad PHP gjorde, trots att Asp Net Core hade större varians i svarstiderna var medelvärdet nästan 4 gånger större för anropen till PHP-API:et. Resultaten var så ojämna att det tydligt gick att se att skillnaden var signifikant, för att säkerställa detta gjordes ett anova-test. Anova-test tar fram ett p-värde som visar om skillnaden mellan två mätserier är signifikant eller inte, då p-värdet är under 0,05 betyder det att skillnaden mellan mätserierna är signifikant. P-värdet för get-anrop var lika med noll, vilket visar att skillnaden var signifikant.
Resultaten som presenterades i testfall 2 visar att även skillnaden på mätserierna för put & post- anrop var signifikant. Medelvärdet för svarstiderna på put var 5 gånger lägre för Asp Net Core än medelvärdet för PHP. En skillnad mellan get och put-anropen var att PHP hade större varians gällande put-anropen, medan Asp Net Core hade större varians gällande get-anropen.
Resultatet av put-mätningarna visar att Asp Net Core-API:et både var mer stabilt gällande jämnare svarstider än vad epost-API:et skrivet i PHP var samt att det presterar 5 gånger snabbare än PHP-API:et då medelvärdet beräknats. Post-anropen utförda i testfall 3 visar att Asp Net Core även är betydligt snabbare på att skicka data till API-servern. Variansen för post- anrop var större för Asp Net Core än variansen för PHP, vilket visar att PHP-API:et hade jämnare svarstider än Asp Net Core. Samtliga resultat som presenterats för testfall 1, 2 & 3 visar tydliga resultat. Det var stora skillnader i medelvärde för samtliga testfall, och standardavvikelsen överlappade inte i något av testfallen, vilket betyder att det i teorin inte behövde göras något anova-test. Anova-tester gjordes ändå och p-värdet för samtliga testfall talade tydligt klarspråk, då p-värdet i samtliga fall var lika med noll.
För att jämföra hur epost-API:et skrivet i Asp Net Core förhåller sig till PHP-API:et syns på figur 31 ett stapeldiagram med samtliga medelvärden för http-metoderna get, put & post.
Medelvärdet ligger stadigt runt 1 för samtliga http-anrop utförda på Asp Net Core-API:et,
26
medan det ligger runt 5 för PHP-API:et. Medelvärdet för Asp Net Core skiljer sig 0,3 ms.
beroende på om det är get, put eller post-anrop som utförs, och medelvärdet för PHP skiljer sig 0,2 ms. Oberoende av vilken http-metod som utförs är medelvärdet betydligt lägre för Asp Net Core än för PHP, och medelvärdet för de två epost-API:er verkar inte skilja sig nämnvärt beroende på om det är en get, put eller postmetod som utförs.
Figur 31. Medelvärdet för get, post och put-anrop hos Asp Net Core och PHP.Slutsatser
6.4 Slutsats
Den hypotes som satts upp för arbetet är att Asp Net Core kommer att prestera bättre än PHP vid utförande av get, put och post-anrop ur en svarstidssynpunkt. Detta grundades på den ändring i http-pipeline som gjorts från föregångaren Asp Net vid utvecklandet av Asp Net Core som Vemula (2017) beskrev i sin bok, samt resultaten i studien utförd av Bounnady et al (2016), där Asp Net och PHP jämfördes.
Resultaten som presenterats och analyserats i arbetet visar att hypotesen kan bekräftas. Epost- API:et skrivet i Asp Net Core presterade ur en svarstidssynpunkt bättre än PHP i att hämta data från servern med get-anrop, att uppdatera data till servern med put-anrop samt att lägga till data till servern med post-anrop. Medelvärdet för de olika anropen låg för Asp Net Core mellan 1,03 - 1,3 ms och för PHP mellan 5,0 - 5,2 ms, vilket visar att varken Asp Net Core eller PHP verkar utföra en specifik http-metod bättre än någon annan.
Gällande varians i mätvärden hade PHP mindre varians i två av tre testfall, vilket visar att PHP hanterar varje anrop på en jämnare nivå utan större fluktuationer, medan svarstiderna för Asp Net Core är mer fluktuerande, men lägre.
0 1 2 3 4 5 6 7
