WebSocket eller Ajax i Webbapplikationer - Är WebSockets prestanda tillräcklig för att ersätta Ajax?

(1)

Examensarbete

Svensson Martin 2012-06-22

Ämne: Examensarbete i Datavetenskap Nivå: G1E

Kurskod: 1DV40E

(2)

Abstrakt

Denna rapport behandlar prestandaskillnader vid överföringar med Ajax och WebSocket, samt webbläsares kompabilitet med WebSocket.

Ämnet kändes relevant då fler och fler webbsidor börjar använda sig av dessa tekniker för att hämta och skicka data i realtid.

Undersökningen genomfördes genom att en testapplikation skapades där data kunde överföras med respektive teknik, varpå tidsåtgången för överföringen mättes och presenterades.

Resultatet visar att WebSocket har klara fördelar mot Ajax när små mängder data överförs, samtidigt som Ajax visade sig vara snabbare vid upprepade överföringar av större mängder data. Undersökningen visade även att stöd för WebSocket saknas i flera webbläsare, varför WebSocket ännu inte är redo att användas fullt ut.

Abstract

This report deals with differences in performance in transmissions with Ajax and WebSocket, and web browsers compatibility with WebSocket.

The subject felt relevant because more and more web sites are starting to use these technologies to send and receive data in real time.

The study was conducted by creating a test application where data could be transferred with respective technology, whereupon the transfer time was measured and presented.

(3)

Förord

Arbetet genomfördes som examensarbete inom Webbprogrammerar-utbildningen på Linnéuniversitetet i Kalmar, och pågick under 10 veckor.

Ämnet för arbetet valdes på grund av att det behandlade moderna tekniker och intressanta lösningar.

(4)

Innehållsförteckning

Innehåll

1. Bakgrund ... 1 1.1 Introduktion ... 1 1.2 Ajax ... 1 1.3 Push ... 2 1.3.1. Comet... 3 1.4 WebSocket ... 3 1.5 Problemformulering ... 5 1.6 Avgränsningar ... 5 1.7 Tidigare arbete ... 5 2. Metod ... 7 2.1 Ajax-Klient ... 7 2.2 Ajax-Server ... 8 2.3 WebSocket-Klient ... 9 2.4 WebSocket-Server ... 10 2.5 Tester ... 11 2.6 Metoddiskussion ... 11 3. Resultat ...13

3.1 1kB 20 gånger med 0 sekunders mellanrum ... 13

3.3 1kB 1’000 gånger med 0 sekunders mellanrum ... 14

3.6 100kB 1’000 gånger med 0 sekunders mellanrum ... 16

3.8 100kB 100 gånger med 5 sekunders mellanrum ... 17

3.9 100kB 1’000 gånger med 5 sekunders mellanrum ... 17

3.10 1MB 10 gånger med 0 sekunders mellanrum ... 18

3.11 1MB 100 gånger med 0 sekunders mellanrum ... 18

(5)

3.16 100 överföringar från klient till server i Chrome ... 21

3.17 100 överföringar från klient till server i Firefox ... 21

3.18 100 överföringar från server till klient i Chrome ... 22

3.19 100 överföringar från server till klient i Firefox ... 22

3.20 1’000 överföringar i Chrome från klient till server ... 23

3.21 1’000 överföringar i Chrome från server till klient ... 23

3.22 1’000 överföringar i Firefox från klient till server ... 24

3.23 1’000 överföringar i Firefox från server till klient ... 24

4. Slutsats ... 25

4.1 Överföringar från klient till server ... 25

4.2 Överföringar från server till klient ... 25

4.3 Webbläsarprestanda med WebSocket ... 26

4.4 Webbläsarprestanda med Ajax ... 26

4.5 Diskussion ... 26

4.6 Fortsatt arbete ... 27

4.7 Rekommendationer ... 27

5. Källförteckning... 28

(6)

1

1. Bakgrund

1.1 Introduktion

När en webbläsare efterfrågan en webbsida sker det genom att webbläsaren skickar en förfrågan till webbsidans server som returnerar efterfrågad data[1].

Denna överföringsmodell grundar sig i att HTTP-protokollet, som används för att överföra webbsidor på internet[1], bygger på överföringsmodellen request/response (”förfrågan/svar”), som innebär att klienten alltid måste skicka en förfrågan för att få data till svar[2], en princip även kallad pull (trycka)[3].

Servern behöver då inte hålla anslutningen mot klienten öppen, vilket gör att servern istället kan han hantera anslutningar från andra klienter. En ny anslutning måste dock upprättas varje gång en förfrågan ska ske, vilket tar upp tid och överföringskapacitet.

Bild 1.1 – Illustration över pull-modellen

Då klienten inte kan skicka förfrågningar konstant får klienten inte senaste data när det finns tillgängligt, utan först när en förfrågan sker.[4] På grund av att vissa typer av applikationer kräver uppdateringar med en väldigt låg tidsfördröjning, exempelvis finansapplikationer och

applikationer där exakt tidsmätning krävs, lämpar sig inte pull-tekniker för dessa applikationer. Detta eftersom att antalet förfrågningar då skulle behöva vara väldigt högt och då ta upp mycket bandbredd och processorkraft[5].

Ett exempel på hur pull-teknik fungerar i praktiken är en chattapplikation där klienten med ett visst tidsintervall måste kontrollera med servern ifall några nya meddelanden åt klienten finns, varpå servern måste skicka ett svar, oavsett om nya meddelanden till klienten finns eller inte.

1.2 Ajax

(7)

2 Ajax(Asynchronous JavaScript and XML) och används idag av bland annat Googles mail-tjänst Gmail och videotjänsten YouTube.[6].

Ajax används för HTTP-överföringar via XMLHttpRequest, ett API (Application programming

interface) implementerat i alla stora webbläsare, för att hämta data från en server[7].

API:t grundar sig i teknik utvecklad av Microsoft på slutet av 1990-talet och möjliggör för JavaScript-kod att hämta data från, och skicka data till, en webbserver utan att webbläsaren behöver ladda om hela sidan. Data som sedan används för att manipulera webbsidans struktur och innehåll med nytt innehåll[8].

Då XMLHttpRequest använder HTTP för dataöverföringar medföljer de problem som pull-modellen medför när den används i dataintensiva applikationer. Bland annat att klienten måste ofta måste göra förfrågningar för att få uppdaterad data vilket medför hög resursanvändning [Se 1.1].

1.3 Push

Under början av 2000-talet började nya sorters webbsidor dyka upp där besökaren presenterades med ny data kontinuerligt, utan att manuellt behöva uppdatera sidan. Nutida exempel på denna typ av sidor är Facebook, där användarna kontinuerligt kan chatta med, och få

statusuppdateringar från vänner, och Twitter, där besökare i realtid kan få utvalda användares meddelandes presenterade för sig.

Ökningen av, och populäriteten hos, webbapplikationer som förser besökarna med

direktuppdaterad data har gett upphov till fenomenet real-time web (realtidswebben) där data skickas och tas emot i realtid hos användare[9]. På grund av det ökade användandet av realtidswebben (mars 2012 hade Twitter 140 miljoner användare[10]) har också behovet av tekniker anpassade för realtidswebben ökat[9].

Webbplatser som använder Ajax för realtidsuppdateringar blir dock påverkade av de problem som kommer med användandet av HTTP gällande att data inte nödvändigtvis är helt ny och att förfrågningar måste göras ofta [3].

För att komma till rätta med dessa problem började tekniker utvecklas på slutet av 1990-talet, för att skicka data till klienter, genom att en anslutning upprättas varpå servern startar en överföring när ny data finns. På så sätt behöver inte klienten skicka förfrågningar för att servern ska kunna skicka data, en modell som kommit att kallas push (trycka)[3].

(8)

3 Ett exempel på hur en applikation som använder push-teknik är en chattapplikation, där klienten först ansluter till en server, som sedan skickar nya meddelanden till klienten när de blir tillgängliga, istället för att klienten ska behöva efterfråga dem själv, som i en pull-applikation.

1.3.1. Comet

Problemen som kommer med användandet av pull-modellen som HTTP implementerar kan dock lösas med användandet av en samling tekniker kallade Comet.

Comet är ett samlingsnamn för olika tekniker för att i webbapplikationer använda HTTP på ett sådant sätt så att webbläsaren inte konstant behöver göra nya förfrågningar efter uppdateringar, utan att servern istället pushar data när det behövs[11].

Comet kan använda sig av två olika sätt för att åstadkomma detta:

I HTTP 1.1 finns möjligheten att hålla den tcp-anslutning som används för överföringen öppen till dess att webbläsaren eller webbservern avbryter den, eller tills en förutbestämd tidsgräns passerat. Detta görs genom att ”Connection”-värdet i HTTP-headern sätts till ”keep-alive”, varpå någon part sätter värdet till ”Close” när anslutningen ska stängas[11]. På så sätt minskas den datamängd som behöver överföras varje gång, på grund av att ingen ny anslutning behöver upprättas, vilket även resulterar i att överföringstiden minskas[13].

På grund av att servern måste använda en instruktionssekvens (tråd[14]) per anslutning innebär det dock att servern snabbt kan blir upptagen med att hantera öppna anslutningar.

Det andra sättet är long-polling, vilket innebär att webbläsaren skapar en anslutning mot en webbserver och sedan håller anslutningen öppen till dess att servern har skickat data. Nackdelen med denna teknik är att HTTP-anslutningen som hålls öppen tar upp anslutningsplatser hos både webbläsare och server, vilket i sin tur kan försämra prestandan[4].

Comet-tekniker kan dock, beroende på teknik, vara omständiga att implementera och vara olämpliga att använda på grund av att mellanliggande mjukvara, exempelvis proxy-servrar, inte är konfigurerade för att tillåta denna typ av överföringar.[11]

1.4 WebSocket

För att göra det möjligt att på ett standardiserat sätt använda push-kommunikation mellan en webbläsare och en webbserver skapades tekniken WebSocket.

Tekniken skapades och utvecklas av IETF (Internet Engineering Task Force) 2007, och förväntas blir standardiserad av W3C (World Wide Web Consortium) som en del av HTML5-standarden[15]. WebSocket kommunicerar asynkront, vilket innebär att det kan skicka meddelanden i båda riktningar, oberoende av varandra.

Med WebSocket kan en klient och en server, efter att en anslutning har skapats, kommunicera med varandra via en enstaka TCP-anslutning helt utan att HTTP används, och undviker på så sätt den överflödiga datamängd som kommunikation med HTTP medför.[15]

(9)

4 Bild 1.3 – Handskakningsmeddelande från klient till server

Bild 1.4 – Handskakningsmeddelande från server till klient

För att göra det möjligt att använda WebSocket över nätverk som tillåter HTTP-trafik är WebSocket första meddelande från klienten utformat som ett HTTP-Upgrade-meddelande. HTTP-Upgrade-meddelandet är egentligen utvecklat för att i HTTP 1.1 informera den ena parten om att en annan version av HTTP ska använda. Den används dock i WebSocket för att mjukvara som hanterar överföringen, exempelvis proxy-servrar, ska kunna hantera meddelandet, och sedan låta WebSocket-trafiken gå över samma port som HTTP-trafik, vanligtvis port 80[15].

Bild 1.5 – Illustration över WebSocket-anslutning

(10)

5 Ett stort problem med WebSocket är att stödet för det idag är bristande, då flera stora webbläsare ännu inte har fullständigt stöd för det, bland annat webbläsaren Opera och den senaste stabila versionen av Internet Explorer.[17]

De webbläsare som (2012-05-17) har stöd för den senaste versionen av WebSocket, RFC6455, är:

 Internet Explorer 10.0.8250.0 (testversion)

 Mozilla Firefox 11.0

 Google Chrome 18.0.1025.162

 Safari 5.2 (testversion)

1.5 Problemformulering

Ajax används av flera webbplatser med höga användarantal[9] vilket medför de problem som kommer med att HTTP använder sig av pull-modellen. Exempel på dessa är långa svarstider och ett behov av att ofta göra nya förfrågningar, och Ajax är därför nödvändigtvis inte den mest lämpade tekniken för att överföra data i bakgrunden på webbsidor.

En möjlig lösning till dessa problem är att ersätta Ajax med WebSocket, som förväntas bli ett standardiserat protokoll som ska erbjuda bättre prestanda och lättare implementation.[15] Studier kommer därför göras där det undersöks om WebSocket har bättre prestanda än Ajax och om WebSocket därför är redo att ersätta Ajax.

1.6 Avgränsningar

Undersökningen kommer endast använda sig av det senaste utkastet av WebSocket, RFC6455, och inte jämföra skillnader mot tidigare versioner, vilket innebär att inga tester kommer göras med webbläsare som endast stödjer tidigare versioner av WebSocket.

Inga undersökningar kommer att göras angående hur data som ska överföras kan optimeras för att minska bandbreddsanvändning. På grund av att det då kan uppstå problem med att avgöra huruvida det är WebSocket eller andra optimeringar som är orsaken till eventuell förändring i överföringstiden.

Undersökningen kommer inte heller ta hänsyn till hur lång utvecklings- och inlärningstiden är mellan Ajax och WebSocket.

Endast en server per överföringsteknik kommer att testas då eventuella prestandaskillnader annars skulle kunna bero på skillnader mellan servermjukvaror och inte mellan tekniker.

1.7 Tidigare arbete

Mathieu Carbou (2011) visar att WebSocket kan lösa de problem som Comet-tekniker medför, så som problem med proxy-servrar och det faktum att Comet inte är en standardiserad teknik. Carbou påpekar att stödet för WebSocket i webbläsare och – servrar i dagsläget är ofullständigt, vilket innebär att utvecklaren i många fall måste förlita sig på externa lösningar. [15]

(11)

6 Baserat på resultatet från undersökningen uppskattar Bengtsson att WebSocket är 10-20%

snabbare än Ajax, men visar att resultatet varierar beroende på antal anslutningar som görs mot en server samtidigt där Ajax har en fördel mot WebSocket vid få anslutningar samtidigt som

(12)

7

2. Metod

För att undersöka eventuella prestandaskillnader med att överföra data i bakgrunden med Ajax respektive WebSocket, skapas en applikation där data kan föras över från klient till server och från server till klient.

Data kan sedan överföras ett godtyckligt antal gånger, och med ett valt tidsintervall mellan varje överföring.

Genom att både server och klient körs på samma maskin och därför har samma systemtid, används den för att beräkna överföringstiden. Anropet från klient till server, eller vice versa, innehåller utöver bestämd mängd data även systemtiden och applikationen kan därför, efter slutförd överföring, beräkna hur lång tid det tog att slutföra anropet. Överföringstiden presenteras då i applikationen.

I undersökningarna används den senaste versionen av webbläsaren Google

Chrome(18.0.1025.162 m) samt den senaste versionen av Mozilla Firefox(11.0), som båda har stöd för den senaste WebSocket-specifikationen.[19,20]. Två olika webbläsare används för att undersöka ifall tidsåtgången för dataöverföringar skiljer sig webbläsarna emellan.

2.1 Ajax-Klient

För att hantera Ajax-anslutningar i en webbläsare valdes JavaScript-ramverket jQuery, vilket underlättar utvecklingen av en testapplikation då ramverket erbjuder metoder för att arbeta med Ajax i alla vanligt förekommande webbläsare[17].

Genom att jQuery använder webbläsarens egen XMLHTTPRequest-implementation[21] sker ingen prestandaförlust jämfört med om egenskriven kod använts. Data som överförs formateras som JSON (JavaScript Object Notation) , ett dataformat baserat på notationen hos JavaScript[22].

(13)

8

Bild 2.2 - Klient-kod för Ajax-överföring från server till klient

2.2 Ajax-Server

För att svara på Ajax-anrop används på serversidan webbservern Apache, som har stöd för bl.a. språket PHP, vilket kommer att användas för att hantera dataöverföringarna på serversidan.[23]

Bild 2.3 – Serverkod som returnerar lokal tid i millisekunder

(14)

9

2.3 WebSocket-Klient

För att använda WebSocket i webbläsaren används webbläsarnas inbyggda stöd för WebSocket för att upprätta en WebSocket-anslutning som används för alla överföringarna.

Data överförs mellan klienten och servern, och sedan beräknas och presenteras tidsåtgången för överföringen.

Bild 2.5 – Klientkod som skickar WebSocket-meddelande

(15)

10

2.4 WebSocket-Server

Efter att flera WebSocket-servrar hade undersökts (se kapitel 2.6) och testats valdes den Python-baserade servern pywebsocket. En WebSocket-server som antingen kan användas som ett tillägg till Apache, eller användas helt fristående. Servern stödjer den senaste WebSocket-specifikationen, RFC 6455, vilket var en förutsättning för att den skulle kunna användas.

På grund av att servern är skriven i Python, kan den användas på alla plattformar som har stöd för Python-språket.[24]

Bild 2.7 – Serverkod för att returnera lokal tid efter att ett WebSocket-meddelande har tagits emot.

(16)

11

2.5 Tester

Testerna som används för att undersöka prestandan utformades för att mäta hur överföringstiden påverkades av datastorlek, tidsintervall, och upprepningar och är skapade för att återspegla hur överföring i webbapplikationer vanligtvis fungerar.

Datamängden varierar från 1kB till 1MB för att simulera de datamängder som överförs då webbsidor uppdateras med olika typer av innehåll. En chattapplikation överförs troligtvis små mängder data flera gånger samtidigt som en bildvisningsapplikation troligtvis för över en större mängd data. De fall där överföringarna sker utan tidsuppehåll utformades för att undersöka hur webbläsarna hanterar flera samtidiga överföringar.

Följande tester genomfördes

1. 1kB data skickas från klient till server med 0 sekunders mellanrum 20 gånger 2. 1kB data skickas från klient till server med 0 sekunders mellanrum 100 gånger 3. 1kB data skickas från klient till server med 0 sekunders mellanrum 1000 gånger 4. 100kB data skickas från klient till server med 0 sekunders mellanrum 20 gånger 5. 100kB data skickas från klient till server med 0 sekunders mellanrum 100 gånger 6. 100kB data skickas från klient till server med 0 sekunders mellanrum 1000 gånger 7. 100kB data skickas från klient till server med 5 sekunders mellanrum 20 gånger 8. 100kB data skickas från klient till server med 5 sekunders mellanrum 100 gånger 9. 100kB data skickas från klient till server med 5 sekunders mellanrum 1000 gånger 10. 1MB data skickas från klient till server med 0 sekunders mellanrum 10 gånger 11. 1MB data skickas från klient till server med 0 sekunders mellanrum 100 gånger 12. 1MB data skickas från klient till server med 0 sekunders mellanrum 1000 gånger 13. 1MB data skickas från klient till server med 5 sekunders mellanrum 10 gånger 14. 1MB data skickas från klient till server med 5 sekunders mellanrum 100 gånger 15. 1MB data skickas från klient till server med 20 sekunders mellanrum 10 gånger

Samma tester genomfördes sedan, där data istället skickades från servern till klienten.

2.6 Metoddiskussion

Valet av pywebsocket som WebSocket-server gjordes efter att flera olika WebSocket-servar hade övervägts. De servrar som undersöktes var:

 jWebSocket  WebSocket-for-Python  node.ws.js  Nugget  Socket.IO  WebSocket-Node  ws4py  pywebsocket

Först sorterades de servrar som inte hade stöd för det senaste WebSocket-protokollet bort, varpå de servrar som inte gick att använda som tillägg till Apache, eller inte gick att använda som fristående servrar. Valet föll därför på pywebsocket, då den hade stöd för RFC 6455, och gick att använda fristående från en webbserver.

(17)

12 De webbläsare som (2012-05-17) hade stöd för den senaste versionen av WebSocket, RFC6455, var:

 Internet Explorer 10.0.8250.0 (testversion)

 Mozilla Firefox 11.0

 Google Chrome 18.0.1025.162

 Safari 5.2 (testversion)

Då den senaste versionen av Internet Explorer 10 inte fanns tillgänglig för Windows 7, valdes Internet Explorer bort. Eftersom att endast testversion av webbläsaren Safari har stöd för RFC 6455 valdes den bort, då det var ett bättre alternativ att använda webbläsare som i stabila versioner har stöd för RFC 6455. Valet föll därför på de då senaste versionerna av Google Chrome och Mozilla Firefox.

Eftersom WebSocket-servern är skriven i python och Ajax-servern använder PHP kan detta eventuellt påverka prestandan hos servern, vilket är svårt att mäta. PHP valdes för Ajax-delen då kunskap om PHP-servern redan fanns.

Firefox och Chrome tillåter båda, med standardinställningar, att max 6 HTTP-anslutningar hålls öppna mot en och samma server[25], vilken kan tänkas påverka testresultatet.

(18)

13

3. Resultat

När alla tester genomförts skapades diagram för att på ett översiktligt sätt undersöka resultatet. Bild 3.1 – 3.15 visar den genomsnittliga överföringstiden per test och bild 3.16 – 3.23 visar den genomsnittliga överföringstiden per plattform och överföringsriktning.

3.1 1kB 20 gånger med 0 sekunders mellanrum

(19)

14

3.2 1kB 100 gånger med 0 sekunders mellanrum

Bild 3.2. - Genomsnittlig överföringstid, i millisekunder, då 1kB överförts 100 gånger med 0 sekunders mellanrum.

3.3 1kB 1’000 gånger med 0 sekunders mellanrum

(20)

15

3.4 100kB 20 gånger med 0 sekunders mellanrum

3.5 100kB 100 gånger med 0 sekunders mellanrum

(21)

16

3.6 100kB 1’000 gånger med 0 sekunders mellanrum

Bild 3.6. - Genomsnittlig överföringstid, i millisekunder, då 100kB överförts 1’000 gånger med 0 sekunders mellanrum.

3.7 100kB 20 gånger med 5 sekunders mellanrum

(22)

17

3.8 100kB 100 gånger med 5 sekunders mellanrum

3.9 100kB 1’000 gånger med 5 sekunders mellanrum

(23)

18

3.10 1MB 10 gånger med 0 sekunders mellanrum

Bild 3.10. - Genomsnittlig överföringstid, i millisekunder, då 1MB överförts 10 gånger med 0 sekunders mellanrum.

3.11 1MB 100 gånger med 0 sekunders mellanrum

(24)

19

3.12 1MB 1’000 gånger med 0 sekunders mellanrum

Bild 3.12. - Genomsnittlig överföringstid, i millisekunder, då 1MB överförts 1’000 gånger med 0 sekunders mellanrum. Server kraschade när Chrome skickade data från klient till server, varför stapeln för det saknas.

3.13 1MB 10 gånger med 5 sekunders mellanrum

(25)

20

3.14 1MB 100 gånger med 5 sekunders mellanrum

Bild 3.14. - Genomsnittlig överföringstid, i millisekunder, då 1MB överförts 100 gånger med 5 sekunders mellanrum.

3.15 1MB 10 gånger med 20 sekunders mellanrum

(26)

21

3.16 100 överföringar från klient till server i Chrome

Bild 3.16 - Trenddiagram över överföringstid vid 1’00 överföringar i Chrome

3.17 100 överföringar från klient till server i Firefox

(27)

22

3.18 100 överföringar från server till klient i Chrome

Bild 3.18 - Trenddiagram över överföringstid vid 100 överföringar i Chrome

3.19 100 överföringar från server till klient i Firefox

(28)

23

3.20 1’000 överföringar i Chrome från klient till server

Bild 3.20 – Trenddiagram över överföringstid vid 1’000 överföringar i Chrome. Server kraschade när Chrome skickade 1MB data från klient till server, varför värde för WebSocket saknas.

3.21 1’000 överföringar i Chrome från server till klient

(29)

24

3.22 1’000 överföringar i Firefox från klient till server

Bild 3.21 – Trenddiagram över överföringstid vid 1’000 överföringar i Firefox

3.23 1’000 överföringar i Firefox från server till klient

(30)

25

4. Slutsats

4.1 Överföringar från klient till server

Testresultaten visar tidigt att WebSocket presterar bättre än Ajax vid överföring av 1kB mängder data[Se Bild 3.20 – 3.23], samt när en paus görs mellan varje överföring[Se bild 3.7 – 3.9., 3.13 – 3.14]. WebSocket presterar dock sämre än Ajax vid situationer där 100kB data, eller mer överförs flera gånger utan någon paus mellan överföringarna[Se bild 3.4 – 3.6, 3.10 – 3.12].

I de testfall där 1’000 överföringar på 100kB och mer inleddes samtidigt var den genomsnittliga överföringstiden mellan 300 % och 764 %[Se bild 3.22] längre med WebSocket än med Ajax. Utifrån detta kan man dra slutsatsen att WebSocket uppnår kortare överföringstider där klienten inte behöver ha flera överföringar igång samtidigt under en längre tid då det medför att den genomsnittliga överföringstiden blir väsentligt längre än om Ajax används.

Detta var inte väntat, då den datamängd som överförs vid en WebSocket-överföring är mindre än datamängden vid en Ajax-överföring.

Utifrån resultaten kan man dra slutsatsen att applikationer som med korta mellanrum för över små mängder data kan dock dra nytta av att använda WebSocket istället för Ajax. Exempelvis chattapplikationer och webbsidor där endast delar av webbsidan uppdateras med ny data. Att överföringstiden med WebSocket gick upp till över 20’000ms [Se bild 3.12] visar dock på att WebSocket inte är redo att användas i situationer där stora mängder data ska föras över från klient till server, exempelvis videoapplikationer.

Att Chrome, vid överföring av 1MB, 1’000 gånger utan uppehåll, resulterade i att WebSocket-servern kraschade[Se bild 3.12], något som inte inträffade när Firefox användes för samma test, pekar även på att Chromes WebSocket-implementation inte är redo att användas fullt ut.

4.2 Överföringar från server till klient

Vid överföring av 1kB data med WebSocket från server till klient visar resultatet att skillnaden i tidsåtgång skiljer sig mellan Chrome och Firefox, där Chrome är mellan 184% och 1008% snabbare än Firefox[Se bild 3.1 – 3.3]. Skillnaden i tidsåtgång skiljer sig dock väldigt lite mellan PHP/Ajax i Firefox och PHP/Ajax i Chrome[Bild 3.21,3.23].

Skillnaden i överföringstid mellan WebSocket i Chrome och Ajax i Chrome kan bero på att WebSocket överför mindre data än Ajax, på grund av att Ajax vid varje överföring måste överföra HTTP-information. Detta förklarar dock inte varför WebSocket i Firefox är långsammare än Ajax i Firefox.

På grund av skillnaderna mellan Chrome och Firefox är det svårt att avgöra om WebSocket eller PHP/Ajax snabbast överför 1kB data. När istället 100kB överförs från server till klient visar testresultatet att WebSocket är 290-300% snabbare än PHP/Ajax, och sedan 285-350% snabbare när 1MB överförs[Se bild 3.21,3.23].

(31)

26

4.3 Webbläsarprestanda med WebSocket

Överföringstiden skiljer sig väldigt lite mellan Chrome och Firefox upp till och med att 1kB data överförs från webbläsaren till server 100 gånger med 0 sekunder mellanrum [Se bild 3.1 – 3.3] men ökar till Chromes fördel när data istället överförs från server till klient[Se 4.2]. När sedan 100kB förs över 1’000 gånger är den genomsnittliga överföringstiden mindre än hälften så lång i Firefox som i Chrome[Se bild 3.6]. Detta kan bero på att Chromes WebSocket-implementation arbetar långsammare än Firefox motsvarighet.

När data förs över från server till klient är Chrome till en början runt 10 gånger så snabbt som Firefox[Se bild 3.1 – 3.2], vilket tyder på att Chrome bättre hanterar överföringar med väldigt små datamängder, än Firefox. Överföringstiderna skiljer sig sedan väldigt lite mellan webbläsarna [Se bild 3.4 – 3.9].

Resultaten från tester där 1MB överförs från server till klient[Se bild 3.10 – 3.15] visar att Firefox, oavsett antal överföringar och pauser, har kortare överföringstider än Chrome.

4.4 Webbläsarprestanda med Ajax

Då Firefox och Chrome båda tillåter att max 6 HTTP-anslutningar hålls öppna mot en och samma server[24] beror skillnaderna i överföringstid[Se bild 3.13] troligtvis inte på att det

maximala antalet anslutningar nås snabbare i endera webbläsaren. Detta bör då inte heller påverka den genomsnittliga överföringstiden. Skillnaderna beror troligtvis istället på olikheter i hur respektive webbläsare hanterar testapplikationens JavaScript-kod.

4.5 Diskussion

Resultatet i undersökningen skiljer sig från resultatet i Bengtssons undersökning[18] där

WebSocket konstant presterar bättre än Ajax när både server och testapplikation körs på samma maskin.

Vid användning av en extern server är dock Ajax snabbare än WebSocket vid 10 överföringar samtidigt som skillnaderna vid 100 och 1’000 överföringar är mindre än vid användandet av en lokal server.

Detta tyder på att svarstiden har en tydlig påverkan på överföringstiden, och är troligtvis en av anledningarna till att resultaten från den egna undersökningen skiljer sig från resultatet i

Bengtssons undersökning i. Detta förklarar dock inte varför resultatet skiljer sig från Bengtssons resultat i de fall där lokal server använts.

(32)

27

4.6 Fortsatt arbete

För att ytterligare undersöka prestandan hos WebSocket kan tester göras där en WebSocket-server får hantera överföringar från flera klienter där ingen av klienterna körs på samma dator som WebSocket-servern. På så sätt skulle testresultaten även visa till vilken grad svarstid och klientantal påverkar överföringstiden.

Då endast en server-mjukvara användes i undersökningen, skulle det även vara intressant att genomföra tester med andra servrar, för att undersöka eventuella prestandaskillnader mellan dessa.

4.7 Rekommendationer

Resultaten från testerna visar att det finns situationer där överföringar med WebSocket går betydligt snabbare än med Ajax[Se bild 3.1 – 3.4] samtidigt som det i andra är tydligt att överföringarna går snabbare med Ajax[Se bild 3.6].

På grund av att resultaten tyder på att WebSocket snabbare överför små mängder data, flera gånger, än Ajax, kan det i applikationen som ofta skickar små mängder data vara lämpligt att ersätta Ajax med WebSocket. Detta kan innebära att WebSocket lämpar sig bättre i

webbapplikationer i realtidswebben då dessa oftast endast hämtar mindre data att uppdatera innehållet med och inte data för hela sidor.

Exempel på detta är chattapplikationer där användare ofta skickar mindre meddelanden, som då innehåller en mindre mängd data, och webbsidor där innehållet ofta uppdateras med ny data. Däremot kan Ajax vara mer lämpat att använda i applikationer där stora mängder data överförs från klient till server, exempelvis vid filöverföring.

Utvecklare måste därför undersöka vilken teknik som bäst lämpar sig för den applikation som ska utvecklas, samt ta hänsyn till att stöder för WebSocket fortfarande inte är fullständigt(Se kapitel 2.6).

(33)

28

5. Källförteckning

5.1 Elektroniska källor

[1] ” HTTP Made Really Easy” [Online]

Tillgänglig http://www.jmarshall.com/easy/http/ [Hämtad: 23:e maj, 2012]. [2] ” HTTP Operational Model and Client/Server Communication” [Online] Tillgänglig:

http://www.tcpipguide.com/free/t_HTTPOperationalModelandClientServerCommunication.ht m [Hämtad 23:e maj, 2012].

[3] J. Escobar,”Push Technology is the Core of the Real Time Web” [Online]

Tillgänglig: http://jungleg.com/2009/07/07/push-technology-is-the-core-of-the-real-time-web/

[Hämtad: 19:e april, 2012].

[4] S. Malik, ” Implement a real-time server push in Ajax applications using socket-based RIA technologies” [Online]

Tillgänglig: http://www.ibm.com/developerworks/web/library/wa-aj-socket/index.html

[Hämtad 15:e april, 2012].

[5] M. Carbou, ”Reverse Ajax, Part 2: WebSockets” [Online] Tillgänglig: http://www.ibm.com/developerworks/web/library/wa-reverseajax2/index.html?ca=drs- [Hämtad: 23:e april, 2012].

[6] ” AJAX Introduction” [Online]

Tillgänglig: http://www.w3schools.com/ajax/ajax_intro.asp [Hämtad: 12:e april, 2012]. [7] ” AJAX Browser Support ” [Online]

Tillgänglig: http://www.tutorialspoint.com/ajax/ajax_browser_support.htm [Hämtad: 31:a maj, 2012].

[8] ”XMLHttpRequest object ” [Online]

Tillgänglig: http://msdn.microsoft.com/en-us/library/ie/ms535874(v=vs.85).aspx [Hämtade: 23:e maj, 2012]

[9] K. Fromm, ”The Real-Time Web: A Primer, Part 1”[Online]

Tillgänglig http://www.readwriteweb.com/archives/the_real-time_web_a_primer_part_1.php

[Hämtad: 14:e april, 2012].

[10] ” Twitter Says It Has 140 Million Users” [Online]

Tillgänglig: http://mashable.com/2012/03/21/twitter-has-140-million-users/ [Hämtad: 23:e maj, 2012].

[11] E. Burckart, ” Comment lines: Erik Burckart: The allure of Comet” [Online] Tillgänglig:

http://www.ibm.com/developerworks/websphere/techjournal/0711_col_burckart/0711_col_bu rckart.html [Hämtad:16:e april, 2012].

[12] ”Hypertext Transfer Protocol -- HTTP/1.1 ” [Online]

(34)

29 [13] [Online] V. Sharovatov, ”HTTP persistent connections, pipelining and chunked encoding” Tillgänglig: http://sharovatov.wordpress.com/2009/11/05/http-persistent-connections-pipelining-and-chunked-encoding/ [Hämtad: 10:e maj, 2012].

[14] ” Processer och trådar” [Online]

Tillgänglig: http://web.it.kth.se/~leifl/artiklar/tradar/tradintro.html [Hämtad: 22:a juni, 2012]. [15] IETF, ”The WebSocket Protocol” [Online]

Tillgänglig: http://tools.ietf.org/html/rfc6455 [Hämtad: 15:e april, 2012].

[16] ”Understanding WebSocket handshake” [Online]

Tillgänglig: http://xebee.xebia.in/2010/12/30/understanding-websocket-handshake/ [Hämtad: 23:e maj, 2012]

[17] ”JQuery” [Online]

Tillgänglig: http://en.wikipedia.org/wiki/JQuery [Hämtad: 25:e april, 2012].

[18] P. Bengtsson, ”Are WebSockets faster than AJAX? ...with latency in mind?” [Online] Tillgänglig: http://www.peterbe.com/plog/are-websockets-faster-than-ajax [Hämtad: 28:e april, 2012].

[19] ” Web Platform Status”

Tillgänglig: http://www.chromium.org/developers/web-platform-status [20] ”WebSockets” [Online]

Tillgänglig: https://developer.mozilla.org/en/WebSockets [Hämtad: 23:e april, 2012]. [Hämtad: 21:a maj, 2012]

[21] “jQuery.ajax()” [Online]

Tillgänglig: http://api.jquery.com/jQuery.ajax/ [Hämtad: 17:e april, 2012]. [22] ” Introducing JSON” [Online]

Tillgänglig: http://www.json.org/ [Hämtad: 23:e maj, 2012] [23] ”Apache 2.x on Microsoft Windows” [Online]

Tillgänglig: http://www.php.net/manual/en/install.windows.apache2.php [Hämtad: 23:e maj, 2012].

[24] ”pywebsocket” [Online]

Tillgänglig: http://code.google.com/p/pywebsocket/ [Hämtad: 12:e april, 2012]. [25] ”Browserscope” [Online]