Latency uitgelegd: hoe dicht moeten je data staan?

Hoe korter de afstand die gegevens moeten afleggen, hoe sneller ze beschikbaar zijn. Idealiter hou je latency dus laag. Of kan het geen kwaad om een milliseconde langer te moeten wachten?

Data zijn het meest kostbare bezit van je organisatie: het is inmiddels al een huizenhoog cliché. Maar gegevens zijn niet altijd actief in gebruik en dus stoppen bedrijven ze veilig weg in data lakes, data warehouses of andere vormen van opslag, fysiek of in de cloud, tot ze weer nodig zijn. Het opnieuw opvragen van die gegevens kan een beetje geduld vragen en in de gehaaste wereld van vandaag hebben we daar altijd te weinig van.

Er is dan ook een fobie ontstaan voor latency, ofwel de vertraging die bij een dataverplaatsing kan optreden. Waarom ontstaat die vertraging en hoe hou je die zo laag mogelijk? En is het per definitie een probleem?

Hoe ontstaat latency?

Latency drukt letterlijk de tijd uit die data erover doen om van punt A naar punt B te verplaatsen. Jouw apparaat stuurt een pakketje met een verzoek voor bepaalde data naar een opslagserver en die server verwerkt je verzoek en retourneert vervolgens het pakketje. Er zijn heel wat externe factoren die de reistijd van gegevens kunnen beïnvloeden.

Een eerste voor de hand liggende factor is de afstand tussen de opslaglocatie en de eindbestemming. Data die in een Belgisch datacenter bewaard worden, zouden een fractie sneller beschikbaar moeten komen dan wanneer je data in pakweg Frankfurt, Londen of New York staan. Dit is dan ook een graag gebruikt verkoopargument voor lokale providers om klanten te verleiden en één van de redenen waarom Google en Microsoft fors investeren in datacenterinfrastructuur in België en Nederland.

Latency hangt nauw samen met doorvoer en bandbreedte op een netwerk, al mogen de termen ook niet met elkaar verward worden. Waar latency een tijdsmeting omslaat, meten doorvoer en bandbreedte de hoeveelheid gegevens op een netwerk. De doorvoer is de hoeveelheid gegevens die op één bepaald moment door het netwerk reist. De bandbreedte is de maximale hoeveelheid die het netwerk aankan. Doorvoer en bandbreedte hebben dus een directe invloed op latency.

De wetten van de fysica

Zelfs met de meest geavanceerde netwerktechnologieën, valt de impact van afstand niet uit te wissen, legt John Engates, Field CTO bij internetserviceprovider Cloudflare, schriftelijk uit. “Ook al bewegen gegevens zich bijna met de snelheid van het licht, de geografische afstand kan nog steeds voor merkbare vertragingen zorgen. Zeker wanneer gegevens continenten of oceanen moeten doorkruisen of zich via satellieten heen en terug in de ruimte verplaatsen. Vaak is deze vertraging gewoon een natuurkundig probleem en het is moeilijk om tegen de natuur in te gaan.”

De beschikbare middelen om de afstand te overbruggen, spelen een minstens even grote rol. Een hypermodern datacenter dat uitgerust is met kilometers glasvezelkabel zal je data veel sneller terug tot bij jou kunnen brengen dan een server op een afgelegen locatie met nauwelijks tot geen connectiviteit. Vergelijk het met reizen in het echte leven: je bereikt doorgaans ook sneller je bestemming wanneer je langs goed onderhouden snelwegen kan rijden, dan wanneer je over hobbelige landwegen moet. Zelfs wanneer de afstand over de snelweg in vogelvlucht enkele kilometers langer is.

Trek je die vergelijking verder, dan begrijp je ook waarom verkeer op het netwerk een invloed heeft op latency. Hoe meer auto’s op de snelweg rijden, hoe groter de kans op file die de reistijd zal verlengen. Een server die overladen wordt met verzoeken, zal dus ook meer tijd nodig hebben om die allemaal verwerkt te krijgen. Tenslotte spelen ook netwerkconfiguraties, -protocollen en de capaciteiten van routers en servers om grote datastromen te verwerken een rol. Latency is dus de optelsom van vele factoren.

Vaak is latency gewoon een natuurkundig probleem en het is moeilijk om tegen de natuur in te gaan.

John Engates, Field CTO Cloudflare

Heen en terug

Er zijn verschillende werkwijzen om latency op een netwerk te berekenen. De meest gebruikte meeteenheid is de retourtijd (in het Engels round-trip time of RTT). Daarbij wordt de chronometer er bijna letterlijk bij genomen om te berekenen hoelang het duurt om data naar een server te verzenden en die weer terug tot bij het apparaat te krijgen. Anderen verkiezen dan weer time to first byte (TTFB) als maatstaf, waarbij de chrono al wordt stopgezet op het moment dat de eerste databits de eindbestemming hebben bereikt.

In principe kan iedere handige IT-gebruiker latency zelf testen door een ‘pingtest’ uit te voeren. Daarvoor heb je geen speciale tools nodig: de opdrachtprompt van Windows is voldoende. Bij een pingtest worden vier testpakketjes naar een hostserver of -computer gestuurd om de beschikbaarheid te testen.

Om meer inzicht te verwerven in waarom latency ontstaat, voer je een traceroute uit. Dit moet je zien als een GPS voor data. Een traceroute tekent de weg die data hebben afgelegd uit, zodat je kan zien waar de vertraging zich heeft voorgedaan. Aan de hand van Real User Monitoring-tools kan je meten hoe latency de gebruikservaring van applicaties beïnvloedt.

Er bestaan gelukkig wel trucs om latency te beperken. Veel webtoepassingen maken daarvoor gebruik van een CDN, ofwel content delivery network. In een CDN wordt statische content van een webpagina gecachet. De CDN-servers kunnen over meerdere locaties verspreid worden om de gegevens van zo dicht mogelijk bij de gebruiker op te roepen, zodat die de content sneller te zien krijgt. Een CDN is ook geen heilige oplossing omdat je er geen ‘dynamische’ gegevens, zoals blogs, in kan onderbrengen.

Elke milliseconde telt

Latency zal in vele gevallen slechts een kwestie van milliseconden (ms) zijn en is zelden met het blote oog merkbaar. Waarom is het dan een probleem? Er zijn heel wat situaties te bedenken waarin een milliseconde een wereld van verschil maakt. Een goed voorbeeld is een zelfrijdende wagen die moet remmen voor een overstekende voetganger: slechts een duizendste van een seconde vertraging kan dan catastrofale gevolgen hebben. Ook bij robotchirurgie is het wenselijk dat de robot elke handeling uitvoert op het exacte moment dat de chirurg die ingeeft.

Nog meer voorbeelden nodig? Denk aan cybersecurity: vindt er ergens in je systemen verdachte activiteit plaats, dan wil je dat het SOC daar ook zo snel mogelijk alert van wordt gemaakt. Iedere milliseconde geeft de indringer een significante voorsprong. Een ander voorbeeld is fraudebestrijding door banken: er is maar een zeer korte tijdspanne om een verdachte transactie tegen te houden en dan is latency evenzeer nefast.

Het hoeft niet altijd spannend te zijn om aan te tonen waarom latency niet onderschat mag worden. Webontwikkelaars krijgen koude rillingen over heel hun lichaam als ze het woord nog maar horen. Bufferende webpagina’s doen bezoekers afhaken en ook Google deinst er niet voor terug om websites daarop af te straffen. Voor de meeste internettoepassingen is latency pas ‘zichtbaar’ als de vertraging meer dan 100-150 ms, ofwel een tiende van een seconde, bedraagt.

Sneller dan het licht: is zero latency een fabeltje?

Providers spelen dan ook graag in op die angst voor latency. Zero latency en real-time data zijn vandaag hippe marketingtermen, maar zijn die beloftes ook realistisch? Een latency van 0,0 ms lijkt volgens de wetten van de fysica onmogelijk: de data zou zich dan sneller dan het licht moeten voortbewegen en dat is zelfs met de meest geavanceerde netwerktechnologie nog lang niet haalbaar.

Dat beaamt ook Engates: “Zero latency is meer een geïdealiseerd concept dan een technisch haalbare realiteit. Technologische innovaties en optimalisaties van netwerkprotocollen hebben vooral als doel de latency tot de laagst mogelijke waarden te beperken. Hiermee verbeter je de gebruikservaring van toepassingen die real-time interactie vereisen, zelfs al blijft werkelijke zero latency onbereikbaar.”

De laatste jaren zijn natuurlijk wel grote stappen gezet om latency zo dicht mogelijk tot bij het magische nulpunt te brengen. Met 5G is het mogelijk om latency te reduceren tot 1 milliseconde (bij optimale omstandigheden), wat door het menselijke brein als real-time wordt gepercipieerd en wat ook een aanzienlijke sprong vooruit is ten opzichte van 4G, dat een latency van gemiddeld 30 tot 50 milliseconden heeft.

Het konijn uit de hoge hoed van Wifi 7 is multi-link operation (MLO). Deze techniek maakt het mogelijk om datapakketten simultaan over de drie beschikbare frequentiebanden te verzenden. Dit moet verstopping op één van de frequentiebanden helpen voorkomen, wat niet alleen snelheid, maar ook stabiliteit en latency ten goede komt. “Tenslotte biedt ook edge-infrastructuur een significant voordeel in het kader van latency, omdat data zo dicht mogelijk bij de bron worden verwerkt en niet uit een datacenter van een cloudprovider moeten komen”, voegt Engates nog toe.

Hoe dicht moeten data staan?

Latency lijkt dan ook een perfecte reclameboodschap voor de edge. Data kunnen blijven daar waar ze nodig zijn, wat vooral voor bedrijfsgevoelige data een interessante premisse is. Daar staan wel investeringen in lokale server- en netwerkinfrastructuur om die data beschikbaar te maken tegenover. Ook beveiliging van edge-data zijn dan volledig de verantwoordelijkheid van de eigenaar.

Waar en hoe dicht data moeten staan, hangt af van wie de data nodig heeft en waarvoor. Voor workloads die lokaal beter draaien, is het interessanter dat de data ook van een server zo dicht mogelijk bij de machine komen. Gaat het om data waar meerdere teams in de organisatie simultaan aan moeten kunnen of cloud-gebaseerde workloads, dan heb je meer baat bij de toegankelijkheid die de cloud biedt.

Zoals bij elk IT-probleem is er dus niet één oplossing die voor elke situatie werkt. Soms heb je data onmiddellijk nodig, maar vaak kan een milliseconde wachten geen kwaad. Bekijk latency dan ook in de context van een individuele use case en bepaal van daaruit waar data zich thuis voelen.