Forklart · to
En nedlasting som går perfekt er det lette tilfellet, og enhver klient håndterer det kompetent. De interessante forskjellene dukker opp når en del av posten mangler, og det skjer langt oftere enn det rene tilfellet skulle tilsi. Dette er hva som faktisk foregår, og hvorfor det koster så mye tid.
Problemets form
En Usenet-post er ikke én fil. Den er tusenvis av små artikler, hver lagret uavhengig på hver leverandørs tjenere, og NZB-fila du laster ned er en liste over navnene deres. En utgivelse på 6.5 GB er omtrent 9,000 av dem.
Artikler blir borte av helt vanlige grunner. Leverandører beholder dem i en fast lagringstid og sletter dem så. Noen leverandører mottok aldri en bestemt artikkel i utgangspunktet, fordi spredningen mellom tjenere er ufullkommen. Nå og da var en opplasting ufullstendig da den ble lagt ut, og en del av den fantes aldri noe sted. Uansett årsak blir virkningen den samme: klienten din ber om en artikkel, og svaret er et avslag i stedet for data.
Dette er vanlig nok til at de som legger ut på Usenet regner med det. Nesten hver utgivelse følges av paritetsdata, som regel PAR2-filer, altså ekstra overflødig informasjon beregnet ut fra originalen. Mangler en del av innholdet, kan pariteten gjenskape det, forutsatt at du har nok av den. En typisk post bærer omkring 10% paritet, så en post kan miste en god bit av seg selv og likevel være fullt ut mulig å redde.
En skadd post er derfor sjelden en ødelagt nedlasting. Det er en nedlasting som krever litt regning før den er ferdig. Spørsmålet er bare hvor lang tid en klient bruker på å regne det ut, og der skiller de seg med en faktor to eller mer.
Den dyre delen
Når en tjener ikke har en artikkel, returnerer den et avslag, og klienten prøver da neste tjener på lista di. Det er riktig å gjøre, for den andre leverandøren har den svært ofte. Kostnaden dukker opp når ingen har den.
I det tilfellet går klienten gjennom hele leverandørlista di, én tjener om gangen, og blir avvist av hver eneste før den kan slutte at artikkelen virkelig er borte. Gjennomgangen er sekvensiell, og avslag er tregere enn folk antar. Vi målte dem direkte, på en hvilende linje, uten at noe innhold beveget seg i det hele tatt:
| leverandør | tid til å svare på en vanlig forespørsel | tid til å avslå en manglende artikkel |
|---|---|---|
| Leverandør A | 77.5 ms | 78.8 ms |
| Leverandør B | 10.5 ms | 454 ms |
| Leverandør C | 10.8 ms | 871 ms |
| Leverandør D | 9.9 ms | 1,227 ms |
| Leverandør E | 10.6 ms | 2,239 ms |
To ting stikker seg ut. For det første er spredningen enorm: et avslag koster et sted mellom 79 ms og 2.2 sekunder avhengig av hvilken leverandør som svarer, en forskjell på nesten tretti ganger. For det andre avslår én leverandør stort sett på den tida det tar å spørre, mens en annen bruker mer enn to hundre ganger sin egen normale svartid på å si nei. Det er ikke nettverksforsinkelse, det er arbeid som skjer hos dem, og å spørre i færre rundturer hjelper knapt.
Legg det sammen: en full gjennomgang av fem leverandører koster, for én enkelt artikkel som ikke lenger finnes, omkring 5 sekunder. Tenk så på at en skadd post har mange slike artikler, og at en klient som behandler dem i rekkefølge betaler den kostnaden gang på gang mens forbindelsen din står stille. Nedlastinga er ikke treg fordi dataene kommer sakte. De har sluttet å komme i det hele tatt, og klienten venter på å få vite det den allerede har nok opplysninger til å regne ut.
Løsningen
Innsikten er ikke å gjøre avslagene raskere, for vi rår ikke over leverandørene. Den er å merke seg når svaret ikke lenger spiller noen rolle.
I ethvert øyeblikk under en nedlasting vet klienten to ting: hvor mange biter som fortsatt mangler, og hvor mye paritetsdata den allerede har. Rekker pariteten den holder til å bygge opp alt som gjenstår, kan svaret på om noen har denne artikkelen ikke lenger endre utfallet. Enten det er et tregt ja eller et tregt nei, blir fila bygd opp likevel. Å fortsette gjennomgangen kjøper ingenting annet enn forsinkelse.
Dagens bygg slutter derfor å spørre på det punktet og går rett på reparasjon. Selve gjenoppbyggingen er rask og har alltid vært det: omkring 2.3 sekunder på en post på 6.5 GB, og det tallet er det samme i hver eneste versjon vi har målt. Den sparte tida er utelukkende ventinga som ikke lenger skjer.
| post på 6.5 GB, 60 manglende artikler | tid til en verifisert fil |
|---|---|
| vente på at hver leverandør avslår | 23 s |
| stoppe så snart pariteten dekker hullet | 13 s |
| hvorav selve reparasjonsregnestykket | 2.3 s |
Den samme endringen gjør ingenting som helst på en uskadd post, noe som er det klareste beviset på at den gjør det vi tror: uten manglende artikler er det ingen gjennomgang å korte ned, og de to byggene fullfører en ren jobb på 6.5 GB på identiske 7 sekunder.
Det er en avveining, ikke en gratis seier. Å reparere tidlig betyr å holde paritetsdata i minnet framfor å kaste dem og hente mer senere, så toppminnet (RSS) på en hardt skadd post stiger fra omkring 0.8 GB til omkring 1.3 GB, og vi henter rundt 400 MB mer fra leverandørene. På en uskadd post er minnet uendret på 0.24 GB. Vi mener det er den riktige avveiningen for de fleste, siden minnet bare brukes i det tilfellet der det gir deg ti sekunder, men det er en reell kostnad, og det finnes en innstilling for den.
Leverandørnavnene er bevisst utelatt i avslagstabellen. Tallene er egenskapen ved én måling én kveld fra ett sted, og en leverandør som indekserer annerledes, eller som vi tilfeldigvis traff på en dårlig kveld, bør ikke stemples som treg på grunnlag av én enkelt omgang. Det som betyr noe for argumentet, er formen: avslag varierer enormt, og summen er stor nok til å dominere en skadd nedlasting. Tallene per leverandør og de rå måledataene ligger i våre interne notater, og tallene fra ende til annen som de forklarer, ligger på ytelsestestsiden.