Forklaret · fire
Fem kolonner går igen i de fleste af vores tabeller. Her står, hvad hver enkelt måler, hvorfor den er værd at offentliggøre, og nogenlunde hvordan en god eller dårlig værdi ser ud på en maskine, du rent faktisk selv har.
Hovedtallet
Uret starter, når opgaven tilføjes, og stopper, når det færdige indhold ligger på disken, verificeret og udpakket. Ikke når downloadet er færdigt, og ikke når klienten erklærer sig færdig.
Det er det eneste tal, der svarer til noget, du selv oplever. En klient kan blive hurtigt færdig med at downloade og derefter bruge et minut på at kontrollere og pakke ud, og fra hvor du sidder, er det minut en del af ventetiden. At måle downloadet alene ville favorisere de klienter, der laver arbejdet bagefter, altså de fleste.
Det er også derfor, vores arkitektur ser usædvanlig ud i disse tabeller. Vi verificerer hvert stykke, efterhånden som det ankommer, og pakker ud, mens downloadet stadig kører, så når den sidste artikel lander, er der meget lidt tilbage. Andre klienter lægger først hele opslaget på disk, verificerer det så og pakker det så ud, i tre led efter hinanden. På en let opgave er forskellen beskeden. På en stor eller beskadiget er den det meste af resultatet.
Den, folk læser forkert
Den største mængde hukommelse, programmet holdt på noget tidspunkt under opgaven. RSS står for resident set size, altså ganske enkelt den hukommelse, der faktisk ligger i RAM, snarere end lovet eller reserveret.
Højere er ikke automatisk værre, og lavere er ikke automatisk bedre. Hukommelse bliver brugt for at undgå noget dyrere, som regel at læse de samme data fra disken to gange. Spørgsmålet, der er værd at stille, er, om forbruget køber noget, og om det er afgrænset.
Afgrænset er det vigtige ord. En klient, hvis hukommelse vokser med opgavens størrelse, møder før eller siden en opgave, den ikke kan gennemføre på din maskine, og fejlen kommer som swap eller en dræbt proces frem for en høflig besked. Vi holder et budget og bliver inden for det, og derfor kan vi køre en opgave på 190 GB gennem en maskine, hvor omkring 1.1 GB hukommelse er til rådighed for os. Et tal som 9.3 GB på en opgave på 190 GB er ikke bare stort, det har en anden form: det vokser med arbejdet.
Hvor vores egen hukommelse stiger, prøver vi at sige, hvad den købte. På hårdt beskadigede opslag holder det nuværende build paritetsdata i hukommelsen for at reparere med det samme frem for at hente mere senere, hvilket tager spidsbelastningen fra omkring 0.8 GB til omkring 1.3 GB og sparer omkring ti sekunder. På et ubeskadiget opslag sker det forbrug ikke, og tallet er 0.24 GB.
Energimålet
Den samlede processortid, hele programmet har brugt, lagt sammen på tværs af alle kerner. Det er et mål for udført arbejde snarere end forløbet tid, så det kan være meget større end uret.
Hvis en opgave tager 100 sekunder og rapporterer 1,600 processorsekunder, var omkring seksten kerner optaget hele kørslen igennem. Det betyder noget af tre praktiske grunde: det er varme, det er strøm, og på en maskine, der laver noget andet samtidig, er det kamp om ressourcerne. En klient, der bliver færdig på rimelig tid, mens den mætter hver eneste kerne, har ikke været effektiv, den har været dyr.
Det er i denne kolonne, de bredeste forskelle på hele sitet dukker op, bredere end ved nogen sluttid. For byte-identisk output på det samme beskadigede opslag har vi målt en tredivedobbelt spredning i processorsekunder mellem klienter. Det er værd at tjekke, før man antager, at to klienter, der bliver færdige med få sekunders mellemrum, udfører sammenlignelige mængder arbejde.
De to diskkolonner
Disktop er den største ekstra plads, opgaven havde brug for på ét enkelt tidspunkt. Volumen-I/O er den samlede mængde data, der blev læst og skrevet for at nå dertil. De besvarer forskellige spørgsmål.
Disktop er en hård begrænsning. Den afgør, om opgaven overhovedet kan køre. De fleste klienter skriver hele opslaget til disk og pakker så en kopi nummer to ud ved siden af, så de skal bruge omtrent det dobbelte af indholdet i ledig plads. For en opgave på 190 GB er det omkring 313 GB ledigt, før du går i gang, mod omkring 157 GB for os, fordi vi pakker ud undervejs og aldrig materialiserer arkivbindene. Hvis din disk ikke kan rumme det dobbelte af opgaven, er den forskel ikke en procentsats, men om downloadet finder sted.
Volumen-I/O er slid og tid. At skrive opslaget, læse det tilbage for at verificere, læse det igen for at pakke ud og skrive output er fire gennemløb af data. At gøre det i ét gennemløb er omtrent en tredjedel af trafikken, hvilket på en SSD er levetid, og på en langsommere disk ofte den egentlige flaskehals frem for netværket.
En bemærkning om, hvordan vi læser disse to, for den snød os og kan snyde dig, når du læser vores tabeller. Begge tal kommer fra tællere, der dækker hele disken, ikke ét enkelt program. Det gør dem til en fremragende kontrol af, om en måling blev forurenet af noget andet, der kørte, og det betyder, at et tal, der ser umuligt ud, som regel er det: en opgave på 6.5 GB, der rapporterer 144 GB disktrafik, er ikke en klient, der opfører sig mærkeligt, det er to opgaver, der deler en maskine.
At læse en tabel
Selve tabellerne, med build og dato ved siden af hver enkelt, står på benchmarksiden, inklusive de omgange, vi taber.