Uitgelegd · vier
Vijf kolommen komen in de meeste van onze tabellen voor. Hier staat wat elk ervan meet, waarom het de moeite van publiceren waard is, en ruwweg hoe een goede of slechte waarde eruitziet op een machine die je echt zelf hebt.
Het hoofdcijfer
De klok begint wanneer de taak wordt toegevoegd en stopt wanneer de afgeronde inhoud op schijf staat, geverifieerd en uitgepakt. Niet wanneer de download klaar is, en niet wanneer de client zegt dat hij klaar is.
Dit is het enige cijfer dat overeenkomt met iets dat jij meemaakt. Een client kan snel klaar zijn met downloaden en daarna een minuut besteden aan controleren en uitpakken, en vanaf jouw stoel hoort die minuut bij het wachten. Alleen de download meten zou clients bevoordelen die hun werk achteraf doen, en dat zijn de meeste.
Het is ook waarom onze architectuur er in deze tabellen ongewoon uitziet. Wij verifiëren elk stuk zodra het binnenkomt en pakken uit terwijl de download nog loopt, dus als het laatste artikel landt is er nauwelijks nog iets te doen. Andere clients zetten eerst de hele post op schijf, verifiëren die daarna en pakken die daarna uit, in drie opeenvolgende fasen. Bij een makkelijke taak is het verschil bescheiden. Bij een grote of beschadigde taak is het bijna het hele resultaat.
Degene die verkeerd gelezen wordt
De grootste hoeveelheid geheugen die het programma op enig moment tijdens de taak vasthield. RSS staat voor resident set size, oftewel simpelweg het geheugen dat werkelijk in het RAM zit in plaats van toegezegd of gereserveerd.
Hoger is niet automatisch slechter, en lager is niet automatisch beter. Geheugen wordt uitgegeven om iets duurders te vermijden, meestal dezelfde gegevens twee keer van schijf lezen. De vraag die telt is of die uitgave iets oplevert en of ze begrensd is.
Begrensd is het belangrijke woord. Een client waarvan het geheugen meegroeit met de omvang van de taak komt uiteindelijk een taak tegen die hij op jouw machine niet kan afmaken, en de storing komt als wisselbestandgebruik of een afgeschoten proces in plaats van een beleefde melding. Wij houden een budget aan en blijven daarbinnen, en daarom kunnen we een taak van 190 GB door een machine halen waar ongeveer 1.1 GB geheugen voor ons beschikbaar is. Een cijfer als 9.3 GB bij een taak van 190 GB is niet alleen groot, het heeft een andere vorm: het schaalt mee met het werk.
Waar ons eigen geheugen stijgt, proberen we te zeggen wat het opleverde. Bij zwaar beschadigde posts houdt de huidige build pariteitsgegevens in het geheugen om meteen te repareren in plaats van later meer op te halen, wat het piekgeheugen van ongeveer 0.8 GB naar ongeveer 1.3 GB brengt en zo'n tien seconden bespaart. Bij een onbeschadigde post gebeurt die uitgave niet en is het cijfer 0.24 GB.
De energie-indicator
De totale processortijd die het hele programma verbruikte, opgeteld over alle kernen. Het is een maat voor verricht werk in plaats van verstreken tijd, dus het kan veel groter zijn dan de klok.
Als een taak 100 seconden duurt en 1,600 processorseconden meldt, waren ongeveer zestien kernen de hele run bezig. Dat telt om drie praktische redenen: het is warmte, het is stroom, en op een machine die tegelijk iets anders doet is het concurrentie om rekenkracht. Een client die in redelijke tijd klaar is terwijl hij elke kern volbelast is niet efficiënt geweest, hij is duur geweest.
In deze kolom staan de breedste verschillen van de hele site, breder dan bij welke eindtijd ook. Bij byte-identieke uitvoer op dezelfde beschadigde post hebben we een spreiding van dertig keer in processorseconden tussen clients gemeten. Het loont dit te controleren voordat je aanneemt dat twee clients die binnen enkele seconden van elkaar klaar zijn een vergelijkbare hoeveelheid werk doen.
De twee schijfkolommen
Piekschijfgebruik is de grootste extra ruimte die de taak op enig moment nodig had. Volume-I/O is de totale hoeveelheid gegevens die daarvoor is gelezen en geschreven. Ze beantwoorden verschillende vragen.
Piekschijfgebruik is een harde grens. Het bepaalt of de taak überhaupt kan draaien. De meeste clients schrijven de volledige post naar schijf en pakken er dan een tweede kopie naast uit, dus hebben ze ruwweg twee keer de inhoud aan vrije ruimte nodig. Voor een taak van 190 GB is dat ongeveer 313 GB vrij voordat je begint, tegen ongeveer 157 GB bij ons, omdat wij uitpakken tijdens het downloaden en de archiefvolumes nooit materialiseren. Als je schijf niet het dubbele van de taak aankan, is dat verschil geen percentage, maar de vraag of de download plaatsvindt.
Volume-I/O is slijtage en tijd. De post schrijven, hem teruglezen om te verifiëren, hem nog eens lezen om uit te pakken en de uitvoer schrijven is vier keer over de gegevens heen. Het in één keer doen is ruwweg een derde van het verkeer, wat op een SSD levensduur is, en op een tragere schijf vaak het werkelijke knelpunt in plaats van het netwerk.
Een noot over hoe wij deze twee lezen, want ze heeft ons te pakken gehad en kan jou te pakken krijgen bij het lezen van onze tabellen. Beide cijfers komen van tellers die de hele schijf beslaan, niet één programma. Dat maakt ze een uitstekende controle op de vraag of een benchmark vervuild is door iets anders dat draaide, en het betekent dat een getal dat onmogelijk lijkt dat meestal ook is: een taak van 6.5 GB die 144 GB schijfverkeer meldt is geen client die zich vreemd gedraagt, het zijn twee taken die een machine delen.
Een tabel lezen
De tabellen zelf, met de build en de datum naast elk ervan, staan op de benchmarkpagina, inclusief de runs die we verliezen.