Lange svartider er skyens skjulte fjende

Mange virksomheder glemmer at medregne svartiden mellem klienter og servere, når de sender deres it-services ud i skyen. Der mangler generelt en forståelse for problematikken, konstaterer it-konsulent Claus Flygenring.

Stadig flere virksomheder lægger deres it-services ud i skyen. De udstyrer sig med kraftige og kostbare gigabitforbindelser uden at tage højde for den forsinkelse, der uafhængig af båndbreddens størrelse opstår mellem klienter og servere - den såkalde svartid eller latency. Det siger it-konsulent Claus Flygenring, der siden 2003 har hjulpet virksomheder med at optimere dataforbindelser.

Han forudser, at mange fremtidige gigabitkunder vil få sig en voldsom aha-oplevelse, når de opdager, at deres skyapplikationer faktisk ikke fungerer, selv om de sidder på en højhastighedsforbindelse.

»Mange kunder i et lokalt klient-servermiljø oplever i hverdagen, at de stort set ikke har nogen forsinkelse i svartider. Men prøver en kunde så at køre den samme applikation eksternt, så opdager de at i stedet for at flytte 8-900 megabit i sekundet på en 1-gigabitforbindelse, så ligger de og roder omkring 50-60 megabit i sekundet,« siger Claus Flygenring til Version2.

Forsinkelsen i hastigheden opstår i det såkaldte round-trip delay, der er betegnelsen for den samlede tid, det tager for en datapakke at blive sendt fra en klient til en server, og til at serveren svarer tilbage til klienten, at den har modtaget pakken, og er klar til den næste. Lidt forenklet kan man sige at der ikke behandlet ny data, før klienten har fået svar tilbage fra serveren for et antal udestående datapakker.

En almindelig computer med Windows XP, der kommunikerer via webservices med en Windows Server 2003-server med en pakkestørrelse sat til 64 kbit, oplever i gennemsnit en round-trip delay på 5-8 millisekunder mellem landsdelene.

Det lyder i sig selv ikke af meget, men har en virksomhed for eksempel købt en 1 gigabitforbindelse, vil man kun kunne opnå en tyvendedel af den forbindelses teoretiske hastighed. Det svarer reelt til en hastighed på 50-60 megabit for den enkelte bruger. For modsat hvad man måtte tro, så har båndbreddens størrelse meget lidt at gøre med round-trip hastigheden.

»Det er et problem for mange virksomheder, da det sløver arbejdsgangen, hvis man regner med, at hastigheden vil forblive den samme, hvis man for eksempel opdeler kontormiljøet på tværs af landet.«

It-infrastrukturchef Thomas Danø fortæller, at blandt andet latency var en stor faktor, da man besluttede sig for at bygge lige netop en privat sky på Københavns Universitet.

»En af de ting der forsvarede, at vi i første omgang byggede en privat cloud på KU, var blandt andet latencyproblemet. Hvis en forsker skal have adgang til store mængder data, der konstant skal skrives og sendes til, som for eksempel billedmateriale, så vil en ekstern cloudløsning ikke være mulig netop på grund af de lange svartider,« siger Thomas Danø til Version2.

Thomas Danø fortæller, at eksterne skyer vil være mest interessante for universitetets forskere i forhold til regnekraft. Datamængden i de algoritmer, som forskeren typisk skal bruge stor regnekraft til at beregne, er ofte så små, at svartiderne vil være irrelevante.

Virksomheden skal med andre ord være opmærksom på, hvilke services de sender ud i skyen, og i den sammenhæng have en realistisk forventning til hvilken ydelse, man faktisk kan forvente af systemet.

»Jeg oplever det typisk som et meget undereksponeret problem, når man snakker om at flytte services ud i en sky eller på eksterne lokaliteter. Det er klart, at hvis der kun er tale om mindre opdateringer af tekst i et browservindue, så vil man ikke opleve det som et problem. Men de fleste virksomheder arbejder i dag med store mængder data, og der begynder det for alvor at blive et problem, hvis man ikke er forberedt på det,« siger Claus Flygenring til Version2.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (8)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Kasper Revsbech

En almindelig computer med Windows XP, der kommunikerer via webservices med en Windows Server 2003-server med en pakkestørrelse sat til 64 kbit, oplever i gennemsnit en round-trip delay på 5-8 millisekunder mellem landsdelene.

Det lyder i sig selv ikke af meget, men har en virksomhed for eksempel købt en 1 gigabitforbindelse, vil man kun kunne opnå en tyvendedel af den forbindelses teoretiske hastighed. Det svarer reelt til en hastighed på 50-60 megabit for den enkelte bruger. For modsat hvad man måtte tro, så har båndbreddens størrelse meget lidt at gøre med round-trip hastigheden.

Er problemet ikke overhead fra headers, og ikke latency i det skitserede eksempel?, kan ikke helt følge jeres beregning.

  • 0
  • 0
#2 Michael Hansen

Der argumenteres for at latency er et stort problem imellem privat netværk og skyen. Dette er rigtigt ved interactive applicationer.

Thomas Danø's argument holder ikke. Da der netop her er tale om store data mængder, vil det have en meget mindre betydning. Antallet af pakker der typisk kan sendes før der ACK's stiger eksponentielt i de TCP Congestion algoritme der bruges af nutidens operativ systemer og skalere fint til 1Gbit. F.eks. TCP CUBIC og Compound TCP. Ældre algoritmer kunne have problemer høje hastigheder pga. latency, men nyere algoritme er meget bedre til at gemme latencien.

  • 0
  • 0
#3 Michael Hansen

Nej, det har at gøre med at før flere pakker bliver sendt til en modtager, skal modtageren ACK'e de modtagne pakker, først derefter bliver de næste pakker sendt. Overheadet er kun ca. 4% ved 1500 byte pakker. Selvfølgelig større procentdel ved små beskeder.

  • 0
  • 0
#4 Jens Jönsson

Er problemet ikke overhead fra headers, og ikke latency i det skitserede eksempel?, kan ikke helt følge jeres beregning.

På Windows maskiner, så har TCP/IP Windows Size en hel del at sige. Størrelsen af Send og/eller receive Windows har stor betydning, jo større roundtrip.

Jeg oplevede problemet første gang, jeg forbandt 2 lokationer over et 100 Mbit/s MPLS netværk. Når klienterne på den ene lokation, hentede data fra serveren på den anden lokation, skulle man jo mene at vi kunne udnytte de fulde 100 Mbit/s i båndbredde (forudsat af diskene kunne følge med). Det kunne vi ikke, før vi fik tunet på TCP/IP Windows size. Da vi fik tunet værdien af Windows size (vi testede med IPerf http://en.wikipedia.org/wiki/Iperf) opnåede vi en brugbar hastighed.

  • 0
  • 0
#6 Hans Henrik Happe

Det lyder som en historie der datere noget tid tilbage.

Rigtigt. Når man siger "latencyproblemet" og "store mængder data" i samme sætning, så er der en klokke som burde begynde at ringe.

Fra min laptop på mobilt bredbånd er der 300ms latency til caltech.edu i LA. Det svarer ca. til 30MB på en 1Gbit linie. Det er ikke store mængder data.

  • 0
  • 0
#7 Hans Henrik Happe

Det lyder som en historie der datere noget tid tilbage.

Rigtigt. Når man siger "latencyproblemet" og "store mængder data" i samme sætning, så er der en klokke som burde begynde at ringe.

Fra min laptop på mobilt bredbånd er der 300ms latency til caltech.edu i LA. Det svarer ca. til 30MB på en 1Gbit linie. Det er ikke store mængder data.

  • 0
  • 0
#8 Martin Toft Bay

Mon ikke hele artiklen dækker over

http://en.wikipedia.org/wiki/Bandwidth-delay_product

selv om der ikke står product noget sted i artiklen :)

Ja, der skal tunes lidt på de fleste netværkstakkes TCP options, hvis en enkelt TCP-forbindelse skal udnytte den fysiske forbindelse fuldt ud, men hvis man f.eks. er en content provider og har mange samtidige besøgende, så betyder det pludselig ikke så meget. Men en cloudløsning til beregning har nok nærmere behov for få, men hurtige, TCP-forbindelser...

  • 0
  • 0
Log ind eller Opret konto for at kommentere