Hur jag ökade prestandan med 951% på Gymjakt.se

Webbprestanda blir viktigare för varje dag som går, särskilt med tanke på att mobila surfare kommer vara en majoritet om ett år. En bättre prestanda ger inte bara besökaren en bättre användarupplevelse, utan gör också att du kan ha fler besökare samtidigt.

Den här artikeln är en fallstudie av Sveriges största gymguide där jag ökade prestandan med 951%. Jag kommer berätta vad jag gjorde för något, varför jag gjorde det och vad de exakta resultaten över prestandan blev.

Anledningen till arbetet

Gymjakt.se växer och behövde utrymme för att växa ännu mer. Optimeringen gjordes i förebyggande syfte för just detta ändamål, så att varje besökare ska få en lika bra upplevelse — oavsett ifall det är en besökare eller tusen besökare inne på webbplatsen samtidigt.

Sajtens kodstruktur byggdes även om för att göra det enklare att underhålla och bygga vidare med nya funktioner.

De optimeringar som gjorts

Det är fler än en optimering som gjorts för att öka Gymjakt?s prestanda. Nedan kommer jag beskriva dem så enkelt men detaljerat som möjligt.

Byte av server

I samband med optimeringen av Gymjakt bytte jag server, men inom samma leverantör (Ipeer). Både nya och gamla servern har följande specifikationer:

• En dedikerad processorkärna hos en Intel® Xeon® CPU E5-2630 0 @ 2.30GHz
• SAS-hårddiskar i RAID 1
• Debian 6.0 x64 som operativsystem
• En dedikerad IP-adress
• 100Mbps nätverksanslutning
• Placerad i Karlstad

Det som skiljer dem åt är RAM-minnet, där gamla servern har 1024 MB medan nya servern bara har hälften så mycket: 512 MB.

Implementering av Nginx

Den välkända webbservern Apache drev gamla Gymjakt under ett års tid. Många tror att det är den enda webbservern som finns, men så är verkligen inte fallet.

För ett par veckor sedan skrev jag en introduktion till webbservern Nginx. Nginx driver självklart även nya Gymjakt och är den förändring som gjort störst påverkan för den ökade prestandan. Eftersom Nginx är väldigt resurssnål kunde jag halvera minnet på nya servern och därmed få den billigare i drift. Jag konfigurerade även Nginx för att trimma sajten lite ytterligare.

Implementering av MariaDB

Det finns även alternativ till den populära databasen MySQL, som gamla Gymjakt använde. MariaDB fungerar ungefär likadant men presterar kort sagt bättre, samtidigt som det finns stöd för fler funktioner. MariaDB var ett enkelt val för nya Gymjakt.

Förbättrad kodstruktur

Koden bakom nya Gymjakt har MVC-struktur och använder sig av så kallad “output buffering” (direktöversatt blir det utgångsbuffert). På så sätt blir koden mer strukturerad, lättläst, återanvändningsbar och även lite snabbare — mycket trevliga egenskaper.

Eftersom JavaScript-biblioteket jQuery var överflödigt för Gymjakt så plockades det bort, vilket gjorde sajten ca 80 kB lättare.

Prestandaanalys

För att kunna mäta och jämföra prestandan gjorde jag två olika sorters prestandaanalyser av startsidan på gamla och nya Gymjakt — ett enklare sidladdningstest och ett stresstest.

Sidladdningstest

I sidladdningstestet kontrollerar jag hur snabbt sidan laddar in alla resurser med webbläsarens cache avstängt. Testet körs tio gånger i följd och därefter räknas medeltalen ut. Testet sker från min dator (Stockholm, ca 25 mil från servern).

Stresstest

Det här testet går ut på att se hur många anrop webbplatsen klarar av att hantera. 200 anrop skickas i taget till webbplatsen i snabb följd tills de uppnått totalt 5000 anrop. Anropen sker från samma serverhall som webbplatsen. Tio sådana här tester körs i följd och därefter räknas medeltalen ut.

Viktigt att veta

Något som är viktigt att veta när man granskar resultaten är några skillnader i innehållet på startsidan.

• Gamla webbplatsen har 13 anrop på totalt 283 KB (varav 6,3 KB är HTML)
• Nya webbplatsen har 15 anrop på totalt 311 KB (varav 5,3 KB är HTML)

Det kan tyckas vara en obefintlig skillnad, men när man räknar millisekunder kan det påverka resultaten.

Resultat

Resultaten för båda testerna är ganska imponerande.

Sidladdningstest

De tio olika testen är presenterade i diagrammet nedan, där siffrorna är tid i millisekunder (lägre är bättre). “DOM” är när dokumentet laddat klart och “Totalt” är när allt laddat klart.

Genomsnittet för gamla och nya sajten är 216 ms respektive 177 ms för dokumentet och 464 ms respektive 387 ms totalt. Det innebär alltså en förbättring på ungefär 22% för dokumentet och ungefär 20% totalt, trots att det är 28 KB och två anrop extra. Inte illa!

Stresstest

Det är resultatet för stresstestet som är mest intressant — siffrorna är antalet anrop per sekund för de tio olika testen (högre är bättre).

Den gamla webbplatsen (med Apache) är det svarta strecket i botten och ser näst intill död ut i jämförelse med den nya webbplatsen (med Nginx). Även nedanstående diagram visar en enorm skillnad mellan resultaten, där staplarna i svart är gamla webbplatsen och oranget den nya.

Den gamla webbplatsen klarar av att hantera i snitt 171,10 anrop per sekund, medan nya webbplatsen klarar av 1627,27 anrop per sekund — en massiv ökning med 951%. Med en överföringshastighet på 1158 kbps respektive 1355 kbps skickas datan dessutom 17% snabbare från den nya webbplatsen. Det tog i snitt 29,25 sekunder att få svar från gamla webbplatsen på alla 5000 anrop, något som nya webbplatsen fixade på 3,11 sekunder — nästan en tiondel av tiden.

Om du vill ha alla exakta siffror av stresstestet kan du ladda ner dem här: Stresstest av Gymjakt.se (PDF)

Sammanfattning

• Webbplatsen laddar in cirka 20% snabbare
• Webbplatsen kan hantera 951% fler anrop med bara hälften av RAM-minnet
• Datan skickas med 17% högre hastighet
• Webbplatsen hanterar 5000 anrop på nästan 10% av den ursprungliga tiden

Slutord

Att optimera webbprestanda är ett jobb som jag verkligen tycker om. Resultatet blir ofta väldigt bra, och det finns många fördelar med att ha en snabb och välpresterande webbplats (kommer i en senare artikel).

Hur viktigt är webbprestanda för dig?