Ferraris og lastbiler

Når man arbejder i SMB-verdenen, er det faktisk ret sjældent, at vi behøver at tale om latenstid. SMB-verdenen er næsten universelt fokuseret på systemgennemstrømning og generelt ubevidst om latenstid som et behov. Men der er tider, hvor latenstid bliver vigtig, og når det sker, er det kritisk, at vi forstår samspillet mellem gennemstrømning og latenstid og præcis, hvad "hastighed" betyder for os. Når vi begynder at bevæge os ind i enterprise-verdenen, vil latenstid oftere blive betragtet som en bekymring, men selv der hersker gennemstrømning næsten altid, til det punkt, at begreber om hastighed næsten universelt drejer sig om gennemstrømning, og begreber om latenstid ofte ignoreres eller glemmes.

At forstå latenstids rolle i et system kan være kompliceret, selv om latenstid i sig selv er relativt simpel at forstå.

En god sammenligning mellem latenstid og gennemstrømning, som jeg godt kan lide at bruge, er idéen om en Ferrari og en lastbil. Ferraris er "hurtige" i traditionel forstand – de har et højt "antal kilometer i timen." Man kan sige, at de er designet til hastighed. Men er de det?

Vi betragter generelt lastbiler som langsomme. De er store og tungere dyr med en lav tophastig hed. Men de transporterer mange ting ad gangen.

I computermæssige termer tænker vi normalt på hastighed som transportkapacitet – vi tænker i "enheder" pr. sekund. I en Ferraris termer er det at køre to hundrede kilometer i timen fantastisk, men den kan transportere måske én kasse ad gangen. En lastbil kan kun køre et hundrede kilometer i timen, men kan transportere nærmere et tusinde kasser ad gangen. Når vi taler om gennemstrømning eller hastighed på en computer, er det mere det, vi tænker på. I netværkstermer tænker vi på gigabytes pr. sekund og er sjældent bekymrede over hastigheden på en enkelt datapakke, da en enkelt pakke sjældent er vigtig. I beregningsmæssige termer tænker vi på begreber som floating point-operationer pr. sekund – et lignende begreb. Ingen bekymrer sig rigtig om, hvor lang tid en enkelt FLOP (floating point-operation) tager, kun hvor mange vi kan få udført på et eller ti sekunder.

Så når vi kigger på en Ferrari, kan vi sige, at den har en nyttig hastighed på to hundrede kasse-kilometer i timen. Det vil sige, at for hver times drift kan en Ferrari flytte én kasse op til to hundrede kilometer. En lastbil har en nyttig hastighed på et hundrede tusinde kasse-kilometer i timen. Hvad angår flytning af pakker, er lastbilens gennemstrømning let fem hundrede gange "hurtigere" end Ferrarienes.

Så i termer af, hvordan vi normalt tænker på computere og netværk, ville en lastbil være "hurtig", og en Ferrari ville være "langsom."

Men der er også latenstid at overveje. Antag, at vores nyttelast er lille – f.eks. et brev eller en lille pakke – kan en Ferrari flytte den ene kasse over et tusinde kilometer på blot fem timer! En lastbil ville tage ti timer på den samme rejse (men ville have MANGE breve, der alle ankommer på én gang). Hvis det, vi har brug for, er at få en besked eller en lille pakke fra ét sted til et andet meget hurtigt, er Ferrarien det bedre valg, fordi den har halvt så stor latenstid (forsinkelse) fra det tidspunkt, vi initierer leveringen, til den første pakke leveres, sammenlignet med lastbilen.

Som man kan forestille sig, er lastbiler i de fleste tilfælde langt mere praktiske, fordi deres leveringshastighed er så meget højere. Og eftersom det er tilfældet, ser vi faktisk store lastbiler på motorvejene hele tiden, og forekomsten af Ferraris er meget lav – selv om hver koster omtrent det samme at købe (meget groft sagt). Men i særlige tilfælde giver Ferrarien mere mening. Bare ikke særlig ofte.

Dette er et generelt koncept og kan anvendes på adskillige applikationer. Det gælder for caching-systemer, hukommelse, CPU, netværk, operativsystemkerner og planlæggere, biler og meget mere. Latenstid og gennemstrømning er generelt omvendt relaterede – vi giver afkald på latenstid for at opnå gennemstrømning. For de fleste operationer giver dette bedst mening. Men nogle gange giver det mere mening at tune for latenstid.

Lagring er faktisk en særling inden for databehandling, hvor næsten al fokus på lagringsydelse er rettet mod IOPS, som groft sagt er en proxy-måling for latenstid, frem for gennemstrømning, der måles i "data overført pr. sekund". Sjældent bekymrer vi os om dette andet tal, da det næsten aldrig er kilden til lagerflaskehalse. Men dette er undtagelsen, ikke reglen.

Latenstid og gennemstrømning kan have nogle overraskende interaktioner i computerverdenen. Når vi taler om netværk, for eksempel, måler vi typisk kun gennemstrømning (Gb/s), men bekymrer os sjældent meget om latenstiden (normalt målt i millisekunder). Typisk er det fordi, næsten alle netværkssystemer har lignende latenstidstal, og de fleste applikationer er temmelig ubekymrede over latensforsinke lser. Det er kun den sjældne applikation som VoIP over internationale forbindelser eller satellit, hvor latenstid påvirker den gennemsnitlige person, eller som kan overraske folk, når de forsøger noget usædvanligt som iSCSI over en lang WAN-forbindelse, og latenstid pludselig dukker op som et uforudset problem.

Et af de steder, hvor interaktionen af latenstid og gennemstrømning begynder at blive chokerende og interessant, er, når vi bevæger os fra elektriske eller optiske datanetværk til fysiske netværk. Et berømt citat i branchen er:

Undervurder aldrig båndbredden af en stationcar fuld af bånd, der raser ned ad motorvejen.

Dette er en fremragende demonstration af enorm båndbredde med meget høj latenstid. Ved at køre halvtreds kilometer på tværs af byen kunne en enkelt stationcar eller SUV transportere hundredvis af petabytes af data og opnå datahastigheder, som 10GB/s fiberoptik ikke ville kunne komme tæt på. Men tiden for den første datapakke til at ankomme er omkring en time. Vi afviser ofte denne slags netværk, fordi vi antager, at latenstid skal holdes under ca. 500 ms. Men det er ikke altid tilfældet.

Australien kom for nylig i nyhederne, hvor de lavede en test for at se, om en due, der bar et SD-kort, i forhold til netværksgennemstrømning kunne overgå regionens internetudbyder – og duen endte med at være hurtigere end internetudbyderen!

Hvad angår databehandlingsydelse ignorerer vi ofte latenstid til det punkt, at vi ikke engang er opmærksomme på den som en kontekst, hvori vi kan diskutere ydelse. Men i kredse med lav latenstid overvejes den meget nøje. Systemgennemstrømning reduceres generelt kraftigt (det bliver almindeligt at sigte mod systemer med kun ti procents CPU-udnyttelse, mens mere traditionelle systemer sigter mod nærmere halvfems procent) med begreber som realtidskerner, CPU-affinitet, processorfastgørelse, cache-hit-ratioer og sænket måling – alt bruges til at fokusere på at opnå den mest umiddelbare respons mulig fra et system frem for at forsøge at få den mest samlede behandling ud af et system.

Almindelige steder, hvor lav latenstid fra et beregningsmæssigt perspektiv er ønskelig, er i kritiske controllersystemer (såsom produktionskontrollere, hvor selv en millisekunds latenstid kan forårsage problemer på fabriksgulvet) eller i finansielle handelssystemer, hvor et par millisekunders forsinkelse kan medføre, at investeringer har ændret pris, eller produkter allerede er solgt og ikke længere er tilgængelige. Hastighed, hvad angår latenstid, er ofte den afgørende faktor mellem at tjene penge eller tabe penge – selv en enkelt millisekund kan være lammende.

Teknisk set skal selv lyd- og videobehandlingssystemer være latensempfindelige, men de fleste moderne computersystemer har så meget reserve behandlingskapacitet, og latenstid er generelt lav nok til, at de fleste systemer – selv VoIP PBX'er og konferencesystemer – i dag kan fungere og kun meget sjældent behøver at være opmærksomme på latensbekymringer på behandlingssiden (selv netværkslatenstid er ved at blive en stadig sjældnere bekymring). Den gennemsnitlige systemadministrator eller ingeniør kan nemt klare en karriere uden nogensinde at have brug for at arbejde på et system, der er latensfølsomt, eller for hvilket der ikke er så meget tilgængeligt overhead til at skjule enhver latensfølsomhed.

At definere hastighed – hvad enten det betyder gennemstrømning, latenstid eller endda noget andet eller en kombination af de to – er noget, der er meget vigtigt i alle aspekter af IT og i livet. At forstå, hvordan de påvirker os i forskellige situationer, og hvordan de reagerer på hinanden med dem, der generelt eksisterer i et omvendt forhold, hvor forbedringer i gennemstrømning sker på bekostning af latenstid eller omvendt – og at lære at balancere disse efter behov for at forbedre de systemer, vi arbejder på, er meget værdifuldt.