Erklärt · vier
Fünf Spalten tauchen in den meisten unserer Tabellen auf. Hier steht, was jede misst, warum sie veröffentlichenswert ist, und ungefähr wie ein guter oder schlechter Wert auf einer Maschine aussieht, die dir tatsächlich gehört.
Die Kennzahl
Die Uhr startet, wenn der Auftrag hinzugefügt wird, und stoppt, wenn die fertigen Nutzdaten auf der Platte liegen, geprüft und entpackt. Nicht wenn der Download endet, und nicht wenn der Client sich für fertig erklärt.
Das ist die einzige Zahl, der etwas entspricht, das du erlebst. Ein Client kann schnell fertig herunterladen und dann eine Minute lang prüfen und entpacken, und von deinem Platz aus gehört diese Minute zur Wartezeit. Nur den Download zu messen würde die Clients begünstigen, die ihre Arbeit hinterher erledigen, also die meisten.
Es ist auch der Grund, warum unsere Architektur in diesen Tabellen ungewöhnlich aussieht. Wir prüfen jedes Stück bei der Ankunft und entpacken, während der Download noch läuft, sodass beim letzten Artikel kaum noch etwas zu tun ist. Andere Clients legen den ganzen Post erst auf der Platte ab, prüfen ihn dann und entpacken ihn dann, in drei aufeinanderfolgenden Phasen. Bei einem leichten Auftrag ist der Unterschied bescheiden. Bei einem großen oder beschädigten macht er das meiste am Ergebnis aus.
Die, die falsch gelesen wird
Die größte Menge Speicher, die das Programm zu irgendeinem Zeitpunkt des Auftrags hielt. RSS steht für resident set size, also schlicht der Speicher, der tatsächlich im RAM liegt, statt zugesagt oder reserviert zu sein.
Höher ist nicht automatisch schlechter, und niedriger ist nicht automatisch besser. Speicher wird ausgegeben, um etwas Teureres zu vermeiden, meist dieselben Daten zweimal von der Platte zu lesen. Die lohnende Frage ist, ob die Ausgabe etwas einbringt und ob sie begrenzt ist.
Begrenzt ist das wichtige Wort. Ein Client, dessen Speicher mit der Auftragsgröße wächst, trifft irgendwann auf einen Auftrag, den er auf deiner Maschine nicht beenden kann, und der Fehlschlag kommt als Auslagern oder abgeschossener Prozess statt als höfliche Meldung. Wir halten ein Budget und bleiben darin, weshalb wir einen 190 GB-Auftrag durch eine Maschine schicken können, auf der uns rund 1.1 GB Speicher zur Verfügung stehen. Eine Zahl wie 9.3 GB bei einem 190 GB-Auftrag ist nicht bloß groß, sie hat eine andere Gestalt: sie skaliert mit der Arbeit.
Wo unser eigener Speicher steigt, versuchen wir zu sagen, was er eingebracht hat. Bei schwer beschädigten Posts hält der aktuelle Build Paritätsdaten im Speicher, um sofort zu reparieren, statt später mehr zu holen; das hebt die Speicherspitze von etwa 0.8 GB auf etwa 1.3 GB und spart rund zehn Sekunden. Bei einem unbeschädigten Post findet diese Ausgabe nicht statt, und die Zahl beträgt 0.24 GB.
Der Energie-Indikator
Die gesamte Prozessorzeit, die das ganze Programm verbraucht hat, über alle Kerne aufsummiert. Sie misst geleistete Arbeit statt verstrichener Zeit und kann deshalb viel größer sein als die Uhr.
Wenn ein Auftrag 100 Sekunden dauert und 1,600 Prozessorsekunden meldet, waren ungefähr sechzehn Kerne den ganzen Lauf über beschäftigt. Das zählt aus drei praktischen Gründen: es ist Wärme, es ist Strom, und auf einer Maschine, die gleichzeitig noch etwas anderes tut, ist es Konkurrenz um Rechenzeit. Ein Client, der in vernünftiger Zeit fertig wird und dabei jeden Kern auslastet, war nicht effizient, sondern teuer.
In dieser Spalte treten die größten Unterschiede der ganzen Website auf, größer als bei jeder Endzeit. Für byte-identische Ausgabe beim selben beschädigten Post haben wir eine dreißigfache Spanne an Prozessorsekunden zwischen Clients gemessen. Das lohnt einen Blick, bevor man annimmt, zwei Clients, die wenige Sekunden auseinander fertig werden, leisteten vergleichbar viel Arbeit.
Die beiden Plattenspalten
Die Plattenspitze ist der größte zusätzliche Platz, den der Auftrag zu einem einzelnen Zeitpunkt brauchte. Volumen-E/A ist die Gesamtmenge an Daten, die dafür gelesen und geschrieben wurde. Sie beantworten verschiedene Fragen.
Die Plattenspitze ist eine harte Schranke. Sie entscheidet, ob der Auftrag überhaupt laufen kann. Die meisten Clients schreiben den kompletten Post auf die Platte und entpacken dann eine zweite Kopie daneben, brauchen also etwa das Doppelte der Nutzdaten an freiem Platz. Für einen 190 GB-Auftrag sind das etwa 313 GB frei, bevor du anfängst, gegenüber etwa 157 GB bei uns, weil wir während des Ladens entpacken und die Archivbände nie materialisieren. Wenn deine Platte nicht das Doppelte des Auftrags fasst, ist dieser Unterschied kein Prozentsatz, sondern die Frage, ob der Download stattfindet.
Volumen-E/A ist Verschleiß und Zeit. Den Post schreiben, ihn zum Prüfen zurücklesen, ihn zum Entpacken nochmals lesen und die Ausgabe schreiben sind vier Durchgänge über die Daten. In einem Durchgang sind es rund ein Drittel des Verkehrs, was auf einer SSD Lebensdauer ist und auf einer langsameren Platte oft der eigentliche Engpass statt des Netzwerks.
Eine Anmerkung dazu, wie wir diese beiden lesen, denn sie hat uns erwischt und könnte dich beim Lesen unserer Tabellen erwischen. Beide Zahlen stammen aus Zählern, die die ganze Platte erfassen, nicht ein einzelnes Programm. Das macht sie zu einer ausgezeichneten Kontrolle, ob ein Benchmark durch etwas anderes Laufendes verunreinigt wurde, und es heißt, dass eine unmöglich wirkende Zahl es meist auch ist: ein 6.5 GB-Auftrag, der 144 GB Plattenverkehr meldet, ist kein seltsam arbeitender Client, sondern sind zwei Aufträge, die sich eine Maschine teilen.
Eine Tabelle lesen
Die Tabellen selbst, mit Build und Datum neben jeder, stehen auf der Benchmark-Seite, einschließlich der Durchgänge, die wir verlieren.