Ferrarier og lastebiler

I SMB-verdenen er det faktisk ganske sjeldent at vi trenger å snakke om latens. SMB-verdenen er nesten universelt fokusert på systemgjennomstrømning og generelt uvitende om latens som et behov. Men det er tider der latens blir viktig og når det skjer er det kritisk at vi forstår samspillet mellom gjennomstrømning og latens og hva «hastighet» betyr for oss. Når vi begynner å bevege oss inn i enterprise-området, vil latens oftere bli sett på som en bekymring, men selv der regjerer gjennomstrømning nesten alltid øverst, til det punktet at konsepter om hastighet nesten universelt dreier seg om gjennomstrømning og konsepter om latens ofte ignoreres eller glemmes.

Å forstå rollen til latens i et system kan være komplisert, selv om latens i seg selv er relativt enkelt å forstå.

En flott sammenligning mellom latens og gjennomstrømning som jeg liker å bruke er ideen om en Ferrari og en lastebil. Ferrarier er «raske» i tradisjonell forstand, de har et høyt «antall kilometer per time.» Man kan si at de er designet for hastighet. Men er de det?

Vi anser generelt lastebiler for å være trege. De er store og klosset kjøretøy med lav topphastighet. Men de frakter mye gods på en gang.

I datatermer tenker vi normalt på hastighet som fraktekapasitet – vi tenker i termer av «elementer» per sekund. I termer av en Ferrari som kjører to hundre kilometer i timen er det flott, men den kan frakte kanskje én eske om gangen. En lastebil kan bare kjøre hundre kilometer i timen men kan frakte nærmere tusen esker om gangen. Når vi snakker om gjennomstrømning eller hastighet på en datamaskin er dette mer det vi tenker på. I nettverksformer tenker vi på gigabyte per sekund og er sjelden bekymret for hastigheten til en individuell pakke da en enkelt pakke sjelden er viktig. I beregningsmessige termer tenker vi på ideer som flyttallsoperasjoner per sekund, et lignende konsept. Ingen bryr seg virkelig om hvor lang tid en enkelt FLOP (flyttallsoperasjon) tar, bare hvor mange vi kan gjøre unna i ett eller ti sekunder.

Så når vi ser på en Ferrari kan vi si at den har en nyttig hastighet på to hundre eske-kilometer per time. Det vil si for hver times drift kan en Ferrari flytte én eske opp til to hundre kilometer. En lastebil har en nyttig hastighet på hundre tusen eske-kilometer per time. I termer av å flytte pakker rundt er gjennomstrømningen til lastebilen lett fem hundre ganger «raskere» enn den til Ferrarien.

Så i termer av hvordan vi normalt tenker på datamaskiner og nettverk ville en lastebil være «rask» og en Ferrari ville være «langsom.»

Men det er også latens å vurdere. Forutsatt at vår nyttelast er liten, si et brev eller en liten eske, kan en Ferrari flytte den ene esken over tusen kilometer på bare fem timer! En lastebil ville ta ti timer på å gjøre den samme reisen (men kunne ha MANGE brev som alle ankommer på en gang.) Hvis det vi trenger er å få en melding eller en liten pakke fra ett sted til et annet svært raskt, er Ferrarien det bedre valget fordi den har halvparten av latensen (forsinkelsen) fra tidspunktet vi iverksetter leveringen til den første pakken leveres, sammenlignet med lastebilen.

Som du kan forestille deg, er lastebiler i de fleste tilfeller enormt mer praktiske fordi leveringshastigheten deres er så mye høyere. Og siden dette er tilfellet ser vi faktisk store lastebiler på motorveiene hele tiden, og forekomsten av Ferrarier er svært lav – selv om begge koster omtrent det samme å kjøpe inn (svært grovt sett.) Men i spesielle tilfeller gir Ferrarien mer mening. Bare ikke veldig ofte.

Dette er et generelt konsept og kan gjelde for mange applikasjoner. Det gjelder bufringssystemer, minne, CPU, nettverk, operativsystemkjerner og planleggere, for biler og mer. Latens og gjennomstrømning er generelt omvendt relatert – vi gir opp latens for å oppnå gjennomstrømning. For de fleste operasjoner gir dette best mening. Men noen ganger er det mer fornuftig å tune for latens.

Lagring er faktisk et merkelig unntak i databehandling der nesten alt fokus på lagringsytelse er rundt IOPS, som er omtrent en indirekte måling for latens, i stedet for gjennomstrømning som måles i «data overført per sekund.» Sjelden bryr vi oss om dette andre tallet da det nesten aldri er kilden til lagringsflaskehalser. Men dette er unntaket, ikke regelen.

Latens og gjennomstrømning kan ha noen overraskende interaksjoner i dataverdenen. Når vi snakker om nettverk, for eksempel, måler vi vanligvis bare gjennomstrømning (Gb/s) men bryr oss sjelden mye om latensen (vanligvis målt i millisekunder.) Vanligvis er dette fordi nesten alle nettverkssystemer har lignende latensnumre og de fleste applikasjoner er ganske mye ubeskjeftigt med latensforsinkelser. Det er bare den sjeldne applikasjonen som VoIP over internasjonale lenker eller satellitt der latens påvirker den gjennomsnittlige personen eller noen ganger kan overraske folk når de forsøker noe uvanlig som iSCSI over en langdistanse WAN-tilkobling og plutselig dukker latens opp for å overraske dem som et uforutsett problem.

Et av stedene der samspillet mellom latens og gjennomstrømning begynner å bli sjokkerende og interessant er når vi beveger oss fra elektriske eller optiske datanettverk til fysiske. Et kjent sitat i bransjen er:

Undervurder aldri båndbredden til en stasjonsvogn full av bånd som raser nedover motorveien.

Dette er en flott demonstrasjon av enorm båndbredde med svært høy latens. Å kjøre femti mil tvers over en by kunne en enkelt stasjonsvogn eller SUV frakte hundrevis av petabyte med data og nå datahastigheter som 10GB/s fiber ikke kunne komme i nærheten av. Men tiden for den første datapakken til å ankomme er omtrent en time. Vi avfeier ofte denne typen nettverk fordi vi antar at latens må være begrenset til under omtrent 500ms. Men det er ikke alltid tilfellet.

Australia ble nylig nevnt i nyhetene der de gjorde en test for å se om en due som bærer et SD-kort, i termer av nettverksgjennomstrømning, kunne utkonkurrere regionens internettleverandør – og duen endte opp med å være raskere enn internettleverandøren!

I termer av databehandlingsytelse ignorerer vi ofte latens til det punktet av ikke engang å være klar over det som en kontekst der vi diskuterer ytelse. Men i lavlatensdatabehandlingskretser vurderes det svært nøye. Systemgjennomstrømning er generelt sterkt redusert (det blir vanlig å målrette systemer til bare å treffe ti prosent CPU-utnyttelse når mer tradisjonelle systemer målretter nærmere nitti prosent) med konsepter som sanntidskjerner, CPU-affinitet, prosessorpinning, cache-treffforhold og redusert måling, som alle brukes for å fokusere på å oppnå den mest umiddelbare responsen mulig fra et system i stedet for å forsøke å få den mest totale behandlingen ut av et system.

Vanlige steder der lav latens fra et beregningsperspektiv er ønsket er i kritiske kontrollsystemer (som produksjonskontrollere der selv en millisekunds latens kan forårsake problemer på fabrikken) eller i finansielle handelssystemer der noen millisekunds forsinkelse kan føre til at investeringer har endret pris eller produkter allerede har blitt solgt og ikke lenger er tilgjengelige. Hastighet, i termer av latens, er ofte den avgjørende faktoren mellom å tjene eller tape penger – selv et enkelt millisekund kan være lammende.

Teknisk sett må selv lyd- og videoprosesseringssystemer være latensfølsomme, men de fleste moderne datasystemer har så mye ledig prosesseringskapasitet og latens er generelt lav nok til at de fleste systemer, selv VoIP PBX-er og konferansesystemer, kan fungere i dag med bare svært sjelden behov for å være klar over latensproblemer på prosesseringssiden (selv nettverkslatens er i ferd med å bli mindre og mindre vanlig som en bekymring.) Den gjennomsnittlige systemadministratoren eller ingeniøren kan lett klare å gå gjennom en karriere uten noen gang å måtte jobbe på et system som er latensfølsomt eller for hvilket det ikke er så mye tilgjengelig kapasitet som til å skjule eventuell latensfølsomhet.

Å definere hastighet, enten det betyr gjennomstrømning, latens eller til og med noe annet eller en kombinasjon av de to, er noe som er svært viktig i alle aspekter av IT og i livet. Å forstå hvordan de påvirker oss i ulike situasjoner og hvordan de reagerer på hverandre der de generelt eksisterer i et indirekte forhold der forbedringer i gjennomstrømning kommer til en kostnad for latens eller omvendt, og å lære å balansere disse etter behov for å forbedre systemene vi jobber med er svært verdifullt.