Steeds vaker wordt het serveren van static resources als GIFs, JPGs en stylesheets geoffload door een Content Delivery Network (CDN). Dit is een verstandige keuze omdat via een CDN je eigen webservers (origins) worden ontlast van veel verkeer. Vaak wordt aan mij tijdens een intake voor een performance test gevraagd of we ook de content moeten meenemen die gehost staan in een CDN. Mijn antwoord is altijd ja, omdat ik al diverse keren tijdens testen heb waargenomen dat performance issues werden veroorzaakt door resources die door het CDN worden geleverd. In deze blog bespreek ik enkele factoren die het belang van de CDN-test onderschrijven.
- Onjuiste cache-instellingen
Als het CDN niet op de juist wijze of te kort de resources in zijn cache bewaart, zorgt dit voor onnodig hoog verkeer tussen de origin en het CDN. Het is daarom verstandig om te kijken naar de http response headers van de resources die worden gedownload door de client. Wat ik vaak zie is dat de content voor vijf minuten gecached wordt door een CDN. Dit komt er in de praktijk op neer dat bij stabiele load om de paar seconde content wordt gedownload vanaf de origin. Dit kan dus om de paar seconden vanaf iedere edge node een piek in het verkeer veroorzaken naar het CDN wat bovenop het verkeer komt wat niet gecached kan worden door het CDN. - Meer edge nodes betekent meer downloads vanaf de origin
Hoe meer edge nodes actief zijn, hoe meer requests er plaatsvinden vanaf het CDN naar je eigen webserver. Als een resource vanuit een client wordt opgevraagd, bekijkt een edge node of deze resource beschikbaar is in zijn cache. Als dit niet het geval is haalt deze edge node van het CDN de resource op bij de origin. Dus hoe meer verschillende edge nodes geraakt worden, hoe meer requests op de origin. Het aantal requests vanuit het CDN naar je origin wordt dus, bij hoge belasting, vermenigvuldigd met het aantal edge nodes dat geraakt wordt. Een CDN-provider met een grote hoeveelheid edge nodes per geografische locatie, zoals Akamai, zorgt dus voor meer load op je eigen omgeving. - Onrealistische meting van de gebruikerservaring
Als de statische resources niet meegenomen worden in de performance test kan dit veel impact hebben op de gemeten responstijden en een onrealistisch beeld van de gebruikerservaring opleveren. De sites die ik test zijn vaak media gerelateerd, pagina groottes van 4 tot 5 MB zijn heel normaal. Meestal bestaat deze voor 95% uit statische resources. Als deze uit de test worden gehaald heeft dit uiteraard een flinke impact op de gemeten responstijd.
Testen video stream Formule 1
Een mooi voorbeeld zijn de performance issues die ik vorig jaar heb gevonden tijdens een performance test voor een video stream voor de Formule 1. Doordat er zoveel edge nodes actief waren die de videobestanden constant vanaf de origin moesten downloaden raakte de internetverbinding ‘vol’ van de origin. Hierdoor konden alle videofiles niet snel genoeg op alle edge nodes geplaatst worden wat in de clients een http 404 veroorzaakte. De klant heeft er daarom voor gekozen de capaciteit van de internetverbinding te verhogen van 1 naar 10 gigabit. Als we de volledige keten (inclusief CDN) nooit hadden getest hadden we dit probleem nooit ontdekt.
Tip voor representatieve CDN performance test
Nu ik het belang van het testen van een CDN heb beschreven kan ik ook nog 1 tip geven om de test uiteindelijk representatief uit te voeren. CDN’s maken gebruik van load balancing voor het verdelen van de load tussen de verschillende edge nodes. Dit gebeurt via DNS. Door een lage TTL mee te geven in het resultaat van de DNS-query voert de DNS-server na een relatief korte periode opnieuw een DNS-query uit. Hierdoor kan het resultaat een andere host (dus edge node) zijn waardoor het verkeer wordt omgeleid naar een andere host omdat host x aan het limiet zit.
Het is daarom aan te raden om lokaal op de load agent een DNS-server te draaien en niet de server van je eigen ISP te gebruiken, omdat die vaak het DNS-resultaat ook weer cached en daar een eigen TTL aan meegeeft. Het is van belang om een lage TTL te gebruiken want dat zorgt voor een meer representatieve spreiding en simulatie naar het CDN. Zo voorkom je ook dat een edge node onterecht teveel load krijgt en zelfs overbelast kan raken.
Raymond Steenvoorden
