Forklart · fire
Fem kolonner går igjen i de fleste av tabellene våre. Her står det hva hver av dem måler, hvorfor den er verdt å publisere, og omtrent hvordan en god eller dårlig verdi ser ut på en maskin du faktisk eier selv.
Hovedtallet
Klokka starter når jobben legges til og stopper når det ferdige innholdet finnes på disken, verifisert og pakket ut. Ikke når nedlastingen er ferdig, og ikke når klienten sier at den er ferdig.
Dette er det eneste tallet som svarer til noe du selv opplever. En klient kan bli fort ferdig med å laste ned og deretter bruke et minutt på å kontrollere og pakke ut, og der du sitter er det minuttet en del av ventingen. Å måle bare nedlastingen ville smigre de klientene som gjør arbeidet etterpå, altså de fleste.
Det er også derfor arkitekturen vår ser uvanlig ut i disse tabellene. Vi verifiserer hver bit etter hvert som den kommer og pakker ut mens nedlastingen fortsatt går, så når den siste artikkelen lander er det svært lite igjen. Andre klienter legger først hele posten på disk, verifiserer den så og pakker den så ut, i tre trinn etter hverandre. På en lett jobb er forskjellen beskjeden. På en stor eller skadd er den mesteparten av resultatet.
Den folk leser feil
Den største mengden minne programmet holdt på noe tidspunkt under jobben. RSS står for resident set size, altså rett og slett minnet som faktisk ligger i RAM, ikke lovet eller reservert.
Høyere er ikke automatisk verre, og lavere er ikke automatisk bedre. Minne brukes for å slippe noe dyrere, som regel å lese de samme dataene fra disk to ganger. Spørsmålet det er verdt å stille, er om forbruket kjøper noe, og om det er avgrenset.
Avgrenset er det viktige ordet. En klient hvis minne vokser med jobbens størrelse, vil før eller siden møte en jobb den ikke får gjort ferdig på maskinen din, og feilen kommer som veksling til disk eller en drept prosess i stedet for en høflig melding. Vi holder et budsjett og blir innenfor det, og derfor kan vi kjøre en jobb på 190 GB gjennom en maskin der omkring 1.1 GB minne er tilgjengelig for oss. Et tall som 9.3 GB på en jobb på 190 GB er ikke bare stort, det har en annen form: det vokser med arbeidet.
Der vårt eget minne stiger, prøver vi å si hva det kjøpte. På hardt skadde poster holder dagens bygg paritetsdata i minnet for å reparere med en gang i stedet for å hente mer senere, noe som tar toppminnet fra omtrent 0.8 GB til omtrent 1.3 GB og sparer rundt ti sekunder. På en uskadd post skjer ikke det forbruket, og tallet er 0.24 GB.
Energimålet
Den samlede prosessortiden hele programmet brukte, summert over alle kjerner. Det er et mål på utført arbeid snarere enn medgått tid, så det kan være mye større enn klokka.
Hvis en jobb tar 100 sekunder og rapporterer 1,600 prosessorsekunder, var omtrent seksten kjerner opptatt hele kjøringen. Det betyr noe av tre praktiske grunner: det er varme, det er strøm, og på en maskin som gjør noe annet samtidig er det kamp om ressursene. En klient som blir ferdig på rimelig tid mens den metter hver kjerne, har ikke vært effektiv, den har vært dyr.
Det er i denne kolonnen de bredeste forskjellene på hele nettstedet dukker opp, bredere enn ved noen sluttid. For byte-identisk utdata på den samme skadde posten har vi målt en tredvedobbel spredning i prosessorsekunder mellom klienter. Det er verdt å sjekke før man antar at to klienter som blir ferdige med få sekunders mellomrom, utfører sammenlignbare mengder arbeid.
De to diskkolonnene
Disktopp er den største ekstraplassen jobben trengte på ett enkelt tidspunkt. Volum-I/O er den samlede datamengden som ble lest og skrevet for å komme dit. De svarer på ulike spørsmål.
Disktopp er en hard skranke. Den avgjør om jobben i det hele tatt kan kjøre. De fleste klienter skriver hele posten til disk og pakker så ut en kopi nummer to ved siden av, så de trenger omtrent det dobbelte av innholdet i ledig plass. For en jobb på 190 GB er det omkring 313 GB ledig før du begynner, mot omkring 157 GB for oss, fordi vi pakker ut mens vi laster ned og aldri materialiserer arkivbindene. Hvis disken din ikke rommer det dobbelte av jobben, er den forskjellen ikke en prosentsats, men om nedlastingen skjer.
Volum-I/O er slitasje og tid. Å skrive posten, lese den tilbake for å verifisere, lese den igjen for å pakke ut og skrive utdata er fire gjennomganger av dataene. Å gjøre det i én omgang er omtrent en tredjedel av trafikken, som på en SSD er levetid, og på en tregere disk ofte den egentlige flaskehalsen framfor nettverket.
En merknad om hvordan vi leser disse to, for den lurte oss og kan lure deg når du leser tabellene våre. Begge tallene kommer fra tellere som dekker hele disken, ikke ett enkelt program. Det gjør dem til en utmerket kontroll på om en måling ble forurenset av noe annet som kjørte, og det betyr at et tall som ser umulig ut, som regel er det: en jobb på 6.5 GB som rapporterer 144 GB disktrafikk, er ikke en klient som oppfører seg rart, det er to jobber som deler en maskin.
Å lese en tabell
Selve tabellene, med bygg og dato ved siden av hver enkelt, ligger på ytelsestestsiden, inkludert omgangene vi taper.