Ti trije opisujejo različne stvari in se nenehno zamenjujejo. Latency je zakasnitev — koliko časa potrebuje ena enota podatkov, da potuje od A do B (merjeno v času, npr. ms). Bandwidth je zmogljivost — največja podatkovna hitrost, ki jo povezava lahko prenese (npr. Gbps). je hitrost, ki jo dosežete v praksi in je običajno pod bandwidthom. Analogija cevi to razjasni:
├────────────── length of pipe = LATENCY (how long to traverse) ─────────────┤
╔══════════════════════════════════════════════════════════════════════════╗
║ width of pipe = BANDWIDTH (max capacity) ║
║ water actually flowing = THROUGHPUT (real achieved rate ≤ bandwidth) ║
╚══════════════════════════════════════════════════════════════════════════╝
Ključno, širša cev je ne naredi krajše: dodajanje bandwidtha ne zmanjša latency. Debela čezatlantska povezava ima še vedno ~80 ms krožne latency, ki jo narekujeta razdalja in hitrost svetlobe — pod njo se ne morete odkupiti. Zato latency, in ne bandwidth, prevladuje pri občutku interaktivnih aplikacij: vsaka krožna pot (DNS, TCP handshake, TLS, nato zahtevek) plača davek latency in ti se seštevajo.
Latency in throughput vplivata drug na drugega prek Bandwidth-Delay Product (BDP = bandwidth × round-trip time), količine podatkov »na poti«, ki je potrebna, da je cev polna. Na »long fat network« z visokim bandwidthom in visoko latency protokol, kot je TCP, ki čaka na ACK-e, ne more napolniti cevi, razen če je njegovo okno vsaj enako BDP — zato je throughput na koncu omejen z latency, ne z bandwidthom. Zato en tok TCP na dolgi razdalji pogosto podpovprečno deluje celo na hitri povezavi in zato pomagajo vzporednost, večja okna in CDN-ji (ki skrajšajo razdaljo in s tem latency).
Zamenjevanje teh treh je ena najpogostejših — in najbolj usodnih — napak pri zmogljivosti: ekipe kupijo več bandwidtha, da bi popravile to, kar je v resnici problem latency, in ne vidijo izboljšave. Senior uvid je, da je latency spodnja meja, ki jo postavi fizika (razdalja) in jo napadate arhitekturno — strežnike/CDN-je postavite bližje uporabnikom, zmanjšate krožne poti (ponovna uporaba povezave, HTTP/3, predpomnjenje) in združujete zahtevke — medtem ko bandwidth pogosto lahko preprosto priskrbite. Razumevanje BDP pojasni protiintuitivne rezultate, kot je »hitra« povezava, ki dostavlja počasne prenose z enim tokom, kar je natanko tista vrsta sklepanja, ki se pričakuje pri načrtovanju ali odpravljanju napak visokozmogljivih, geografsko porazdeljenih sistemov.
Knjižnica IT vprašanj za razgovore s podrobnimi odgovori — od začetnika do izkušenega.
Doniraj