Conclusie
Op het moment van schrijven heb ik al geen toegang meer tot mijn leen servers van Leaseweb. Even snel nog wat testen zit er niet meer in. Na te beseffen dat ik een suffe fout had gemaakt bij mijn nulmeting waren mijn geschreven teksten redelijk nutteloos en hebben jullie weinig meer van mij gehoord. Nu dan eindelijk toch mijn conclusie, wat heb ik geleerd.
We begonnen dit traject om te onderzoeken of het voor een MKB web applicatie bouwer rendabel is om een CDN van Leaseweb aan te schaffen. Het idee hierachter was dat de CDN de druk van Apache af zou halen en deze op zijn beurt meer ruimte zou hebben om API calls af te handelen. Als bijkomend voordeel zouden klanten minder lang hoeven te wachten tot hun bestanden gedownload waren. Dit vanwege het betere netwerk van de CDN.
In dit proces was het de bedoeling om benchmarks van een kleine VPS te vergelijken met die van de CDN. De fout die hierin werd gemaakt is dat ik geen rekening hield met de kracht van het netwerk intern. De benchmarks voerde ik uit met een CLI tool genaamd Siege. Door gebruik te maken van `fallocate` kon ik snel bestanden aanmaken op de VPS. Deze bestanden simuleerden een webapplicatie en varieerden in grootte van 3KB (afbeelding) tot 20MB (Flash file). Na de namen op te slaan in een text file (leaseweb_siege.txt) ging via het volgende commando Siege voor mij aan de slag.
code:
1
| siege -t30M -c50 -f leaseweb_siege.txt |
De t option geeft aan dat we voor 30 minuten gaan testen. Vervolgens stelt de c option in dat er 50 gebruikers tegelijk moeten worden gesimuleerd. En f verteld Siege de text file te gebruiken om te bepalen welke URLs moeten worden aangeroepen. Ook nuttige opties zijn `-b` voor daadwerkelijk te benchmarken (normaal zit er een delay tussen calls) en `-i` om willekeurig om te springen met de URLs in het tekst bestand. Dit laatste zou een meer realistische weergave van het gedrag van gebruikers moeten weergeven. In mijn geval kreeg ik de volgende resultaten:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
| Lifting the server siege... done.
Transactions: 24579 hits
Availability: 100.00 %
Elapsed time: 1799.66 secs
Data transferred: 12734.56 MB
Response time: 3.11 secs
Transaction rate: 13.66 trans/sec
Throughput: 7.08 MB/sec
Concurrency: 42.49
Successful transactions: 24579
Failed transactions: 0
Longest transaction: 20.83
Shortest transaction: 0.06 |
Zoals je kan zien is de throughput 7.08 MB/sec wat neerkomt op ongeveer 57 Mb/s wat logisch te verklaren is gezien mijn download snelheid gelimiteerd is tot 60 Mb/s. Dat dit weinig vroeg van de server is ook goed terug te zien in het dashboard van New Relic. Zelfs de VPS kon deze requests met gemak aan.
Wat ik hieruit wel kan concluderen is dat het serveren van bestanden bijna geen belasting heeft op de server. Het geheugen, CPU en disk verbruik is verwaarloosbaar gestegen. De eerste bottleneck die we tegen lijken te komen is de bandwidth. Stel dat elke speler mijn netwerk aansluiting heeft en tijdens het gamen daar continu de volledige belasting van gebruikt. Dan kunnen theoretisch 16 man tegelijk spelen (1000 / 60 afgerond naar beneden). Om dit toch te testen heb ik op een rustig moment één van onze productie servers getest (ditmaal vanaf een andere VPS). Uit deze test kon ik concluderen de 60 Mb/s redelijk uit komt. Wel opvallend is dat de CPU load hard omhoog gaat, zelfs wanneer de request een 404 terug geeft. Dit doet vermoeden dat Apache een redelijk grote overhead heeft wanneer deze files moet serveren. Hetgeen wat een probleem kan zijn als er tegelijk rekenkracht nodig is voor PHP en MySQL.
Interface
Het eerste wat opvalt is dat de CDN een compleet eigen beheer omgeving heeft. Waar de VPSen en Bare metal servers te beheren zijn vanaf
https://secure.leaseweb.nl moet je voor de CDN naar
https://secure.leasewebcdn.com gaan. De inloginterface is gelukkig hetzelfde en vervolgens is het systeem zelf in dezelfde style als de andere beheer omgeving. Hiermee voelen we ons gelijk thuis. Het is ook mogelijk om wel naar secure.leaseweb.nl te gaan en daar vervolgens de CDN optie te kiezen uit de dropdown lijst. Dit stuurt je door naar secure.leasewebcdn.com.
Direct na het inloggen kom je op het dashboard. Hier kunnen account instellingen worden aangepast; Tickets aangemaakt; Factureren worden ingezien en kan een chat worden gestart met een medewerker van Leaseweb.
Het echte controle paneel van de CDN zit echter achter de dropdown van het CDN knopje in de bovenste balk van de interface. Na een klik op de dropdown klik je vervolgens op ‘control panel’. Dit brengt je naar een pagina die informatie geeft over de control panel waarbij vervolgens nogmaals op een knop moet worden gedrukt om daadwerkelijk bij het controle paneel te komen. Voor dit controle paneel moet opnieuw worden ingelogd. Dit had van mij wel wat meer geïntegreerder mogen zijn met het generieke controle paneel. Het is trouwens wel mogelijk om via een link direct naar de goede pagina te gaan. De URL hiervan is:
https://my.leasewebcdn.com
Vanaf dit punt kwam ik erachter hoe weinig ik eigenlijk nog wist van CDNs (of is het CDNen?). Waar mijn eerdere beeld was dat het gewoon een simpele server was met veel bandbreedte, is het in werkelijk een veel ingewikkelder systeem. Volgens de expert van Leaseweb is zowel de hardware als software afgestemd om snel bestanden te kunnen vinden, lezen en serveren. Een infrastructuur van aan elkaar geknoopte SSDs moeten ervoor zorgen dat de servers snel bij de bestanden kunnen.
Dat de software speciaal is ingesteld merk je als beheerder ook. Bij het opzetten van een zogenaamde 'zone' moet je kiezen wat voor type CDN je wilt opzetten. Je kan hierbij kiezen voor 3 opties: kleine bestanden, grote bestanden of streaming (video en audio). Elke optie kiest ervoor om het gekozen bestandstype zo snel mogelijk te serveren. Al met al toch aardig wat meer dan gewoon een servertje met veel bandwidth.
Implementatie
Dit, voorlaatste, stuk van de review is theoretisch en gaat in op hoe de CDN van Leaseweb kan bijdragen aan een bedrijf in de MKB sector.
Het probleem was dat we een enkele server gebruiken voor al het webverkeer voor een enkele webapplicatie. Dit is een probleem doordat resource zware operaties, zoals schrijven naar de database, invloed hebben op het serveren van statische content als HTML, JS, CSS en afbeeldingen. Lange wachttijden zonder feedback zijn irritatie opwekkers en hebben een grote kans de gebruiker weg te jagen.
Als bijkomend probleem kan je niet een server met weinig resources maar veel bandwidth aanschaffen. Een tweede server neerzetten voor het zelf serveren van bestanden is een slechte optie omdat dan potentieel veel processor kracht en RAM geheugen ongebruikt blijft (waar dus wel extra voor wordt betaald).
Als oplossing hiervoor zou men een CDN kunnen gebruiken om alle statische content zo te serveren. Het voordeel hieraan zou zijn dat de CDN toegewijd is aan het serveren van deze content en dus niet vertraagd kan worden door ander rekenwerk. Als bijkomend voordeel zijn deze servers verder geoptimaliseerd om statische content zo snel mogelijk bij de gebruiker af te leveren. Iets wat een hoop werk kan opleveren wil je het zelf opzetten.
De keerzijde van de medaille is dat er een prijskaartje hangt aan een CDN. Als MKB bedrijf slaan we de 'enterprise' optie maar gelijk over en gaan rechtstreeks naar de 'pay-as-you-go' optie. De meest minimale optie kost €49,- en geeft je: 2TB dataverkeer, 2GB opslag en 0 - 20 M HTTP requests.
Bij één van onze laatste games geeft een niet geoptimaliseerde versie: 30MB over 300 calls. Daarmee kan de game in totaal 66.667 keer gedownload worden per maand. Dit delen we dan wel over meerdere games maar in combinatie met caching is dit meer dan genoeg. Over de bandwidth wordt niet gesproken, daarmee neem ik aan dat Leaseweb alles inzet om de bestanden te serveren en de connectie van de gebruiker altijd de beperkende factor zal zijn.
Een alternatief is om een infrastructuur neer te zetten die de load kan delen. Nu hebben wij onze werkwijze al omgezet naar een uitgebreidere infrastructuur t.o.v. losse VPSen waarmee dit voor ons een makkelijkere stap is. Wat is er nodig voor een dergelijke opzet: load-balancers, dns servers, applicatie servers en wat Linux kennis. Een basis opzet hiervan zou je voor $30,- in elkaar moeten kunnen zetten. Dan heb je zo'n 2TB dataverkeer, 20GB opslag en oneindig aantal requests.
Eindconclusie
De CDN van Leaseweb is een mooie en betaalbare optie. Zoals het op de website wordt beloofd is het snel op te zetten en bied het opties voor ieder wat wils. Op de vraag, kan de CDN ervoor zorgen dat statische content snel bij de gebruiker komen desondanks de rekentaken op de applicatie servers? Kunnen we gemakkelijk 'ja' zeggen.
Is het de ideale optie voor iedereen? Dat is af te vragen en naar mijn mening afhankelijk van de situatie. Is er weinig server beheer kennis in huis, dan bied de GUI van de CDN veel gemak. Met weinig leeswerk kan bijna iedereen het systeem opzetten en ervoor zorgen dat de bestanden netjes worden opgehaald. Als er wel beheer kennis in huis is echter. Zeker als er ook al een infrastructuur bestaat. Dan kan er op kosten worden bespaard door meer rekenkracht voor de load-balancers aan te schaffen.
Het resultaat zal niet helemaal hetzelfde zijn. Daar waar Leaseweb er alles op alles voor inzet om de CDN te optimaliseren. Maar wachttijden zonder feedback horen hoe dan ook tot het verleden. Het blijft een afweging tussen kosten en gebruikersgemak.