Förklarat · fyra
Fem kolumner återkommer i de flesta av våra tabeller. Här står vad var och en mäter, varför den är värd att publicera, och ungefär hur ett bra eller dåligt värde ser ut på en maskin du faktiskt äger själv.
Huvudsiffran
Klockan startar när jobbet läggs till och stannar när det färdiga innehållet finns på disken, verifierat och uppackat. Inte när nedladdningen är klar, och inte när klienten säger att den är färdig.
Detta är den enda siffran som motsvarar något du själv upplever. En klient kan bli klar med nedladdningen snabbt och sedan lägga en minut på att kontrollera och packa upp, och från där du sitter är den minuten en del av väntan. Att mäta bara nedladdningen skulle gynna de klienter som gör sitt arbete efteråt, alltså de flesta.
Det är också därför vår arkitektur ser ovanlig ut i dessa tabeller. Vi verifierar varje bit när den kommer och packar upp medan nedladdningen fortfarande pågår, så när den sista artikeln landar återstår mycket lite. Andra klienter lägger först hela posten på disk, verifierar den sedan och packar upp den sedan, i tre led efter varandra. På ett lätt jobb är skillnaden blygsam. På ett stort eller skadat är den större delen av resultatet.
Den som läses fel
Den största mängd minne programmet höll vid något tillfälle under jobbet. RSS står för resident set size, alltså helt enkelt det minne som verkligen ligger i RAM snarare än utlovat eller reserverat.
Högre är inte automatiskt sämre, och lägre är inte automatiskt bättre. Minne används för att slippa något dyrare, oftast att läsa samma data från disk två gånger. Frågan värd att ställa är om utgiften ger något och om den är begränsad.
Begränsad är det viktiga ordet. En klient vars minne växer med jobbets storlek kommer förr eller senare att möta ett jobb den inte kan slutföra på din maskin, och felet kommer som växling till disk eller en dödad process i stället för ett artigt meddelande. Vi håller en budget och stannar inom den, vilket är varför vi kan köra ett jobb på 190 GB genom en maskin där ungefär 1.1 GB minne står till vårt förfogande. En siffra som 9.3 GB på ett jobb på 190 GB är inte bara stor, den har en annan form: den växer med arbetet.
Där vårt eget minne stiger försöker vi säga vad det köpte. På svårt skadade poster håller nuvarande bygge paritetsdata i minnet för att reparera direkt i stället för att hämta mer senare, vilket tar toppminnet från omkring 0.8 GB till omkring 1.3 GB och sparar ett tiotal sekunder. På en oskadad post sker den utgiften inte och siffran är 0.24 GB.
Energimåttet
Den totala processortid hela programmet förbrukade, summerad över alla kärnor. Det är ett mått på utfört arbete snarare än förfluten tid, så det kan vara mycket större än klockan.
Om ett jobb tar 100 sekunder och rapporterar 1,600 processorsekunder var ungefär sexton kärnor upptagna hela körningen. Det spelar roll av tre praktiska skäl: det är värme, det är el, och på en maskin som gör något annat samtidigt är det konkurrens om resurserna. En klient som blir klar på rimlig tid samtidigt som den mättar varje kärna har inte varit effektiv, den har varit dyr.
Det är i den här kolumnen de största skillnaderna på hela webbplatsen syns, större än vid någon sluttid. För byte-identisk utdata på samma skadade post har vi mätt en trettiofaldig spridning i processorsekunder mellan klienter. Det är värt att kontrollera innan man antar att två klienter som blir klara med några sekunders mellanrum utför jämförbara mängder arbete.
De två diskkolumnerna
Disktopp är det största extrautrymme jobbet behövde vid något enskilt tillfälle. Volym-I/O är den totala mängd data som lästes och skrevs för att komma dit. De besvarar olika frågor.
Disktopp är en hård begränsning. Den avgör om jobbet över huvud taget kan köras. De flesta klienter skriver hela posten till disk och packar sedan upp en andra kopia bredvid, så de behöver ungefär dubbla innehållet i ledigt utrymme. För ett jobb på 190 GB är det omkring 313 GB ledigt innan du börjar, mot omkring 157 GB för oss, eftersom vi packar upp under nedladdningen och aldrig materialiserar arkivvolymerna. Om din disk inte rymmer dubbla jobbet är den skillnaden inte en procentsats, utan huruvida nedladdningen blir av.
Volym-I/O är slitage och tid. Att skriva posten, läsa tillbaka den för att verifiera, läsa den igen för att packa upp och skriva utdata är fyra genomgångar av datan. Att göra det i ett enda pass är ungefär en tredjedel av trafiken, vilket på en solid state-disk är livslängd, och på en långsammare disk ofta den verkliga flaskhalsen snarare än nätverket.
En anmärkning om hur vi läser dessa två, för den lurade oss och kan lura dig när du läser våra tabeller. Båda siffrorna kommer från räknare som täcker hela disken, inte ett enskilt program. Det gör dem till en utmärkt kontroll av om en mätning förorenats av något annat som kördes, och det betyder att ett tal som ser omöjligt ut oftast är det: ett jobb på 6.5 GB som rapporterar 144 GB disktrafik är inte en klient som beter sig konstigt, det är två jobb som delar en maskin.
Att läsa en tabell
Tabellerna själva, med bygge och datum bredvid var och en, finns på benchmarksidan, inklusive de omgångar vi förlorar.