Explications · quatre
Cinq colonnes reviennent dans la plupart de nos tableaux. Voici ce que mesure chacune, pourquoi elle mérite d'être publiée, et à peu près à quoi ressemble une bonne ou une mauvaise valeur sur une machine que vous possédez vraiment.
Le chiffre principal
Le chronomètre démarre quand la tâche est ajoutée et s'arrête quand le contenu fini existe sur le disque, vérifié et extrait. Pas quand le téléchargement se termine, et pas quand le client se déclare prêt.
C'est le seul chiffre qui corresponde à quelque chose que vous vivez. Un client peut finir de télécharger vite puis passer une minute à vérifier et à décompacter, et de là où vous êtes cette minute fait partie de l'attente. Ne mesurer que le téléchargement flatterait les clients qui font leur travail après coup, c'est-à-dire la plupart.
C'est aussi pourquoi notre architecture paraît inhabituelle dans ces tableaux. Nous vérifions chaque morceau à son arrivée et décompactons pendant que le téléchargement tourne encore, si bien qu'au dernier article il ne reste presque rien à faire. Les autres clients déposent d'abord tout le post sur le disque, puis le vérifient, puis le décompactent, en trois phases successives. Sur une tâche facile l'écart est modeste. Sur une tâche volumineuse ou endommagée, il fait l'essentiel du résultat.
Celui qu'on lit de travers
La plus grande quantité de mémoire détenue par le programme à un moment quelconque de la tâche. RSS signifie resident set size, c'est-à-dire simplement la mémoire réellement en RAM plutôt que promise ou réservée.
Plus haut n'est pas automatiquement pire, et plus bas n'est pas automatiquement mieux. La mémoire est dépensée pour éviter quelque chose de plus coûteux, en général lire deux fois les mêmes données depuis le disque. La question à poser est de savoir si cette dépense achète quelque chose et si elle est bornée.
Bornée est le mot important. Un client dont la mémoire croît avec la taille de la tâche finira par rencontrer une tâche qu'il ne peut pas terminer sur votre machine, et la panne arrive sous forme de swap ou de processus tué plutôt que de message poli. Nous tenons un budget et restons dedans, ce qui nous permet de faire passer une tâche de 190 GB sur une machine où environ 1.1 GB de mémoire nous est disponible. Un chiffre comme 9.3 GB sur une tâche de 190 GB n'est pas seulement grand, il est d'une autre nature : il croît avec le travail.
Là où notre propre mémoire monte, nous essayons de dire ce qu'elle a acheté. Sur les posts lourdement endommagés, la version actuelle garde les données de parité en mémoire pour réparer tout de suite au lieu d'en chercher davantage ensuite, ce qui fait passer la mémoire de pointe d'environ 0.8 GB à environ 1.3 GB et fait gagner une dizaine de secondes. Sur un post intact cette dépense n'a pas lieu et le chiffre est de 0.24 GB.
L'indicateur d'énergie
Le temps processeur total consommé par l'ensemble du programme, additionné sur tous les cœurs. C'est une mesure du travail accompli plutôt que du temps écoulé, elle peut donc être bien plus grande que le chronomètre.
Si une tâche prend 100 secondes et rapporte 1,600 secondes processeur, à peu près seize cœurs ont été occupés pendant toute la durée. Cela compte pour trois raisons pratiques : c'est de la chaleur, c'est de l'électricité, et sur une machine qui fait autre chose en même temps c'est de la contention. Un client qui finit en un temps raisonnable en saturant tous les cœurs n'a pas été efficace, il a été coûteux.
C'est dans cette colonne qu'apparaissent les écarts les plus larges de tout le site, plus larges que n'importe quel temps de fin. Pour une sortie identique octet pour octet sur le même post endommagé, nous avons mesuré un écart de trente fois en secondes processeur entre clients. Cela vaut la peine d'être vérifié avant de supposer que deux clients qui terminent à quelques secondes l'un de l'autre font une quantité de travail comparable.
Les deux colonnes disque
Le pic disque est l'espace supplémentaire maximal dont la tâche a eu besoin à un instant donné. Les E/S du volume sont la quantité totale de données lues et écrites pour y parvenir. Ils répondent à des questions différentes.
Le pic disque est une contrainte dure. Il décide si la tâche peut tourner, tout court. La plupart des clients écrivent le post complet sur le disque puis décompactent une seconde copie à côté, il leur faut donc environ deux fois le contenu en espace libre. Pour une tâche de 190 GB, cela fait environ 313 GB de libre avant de commencer, contre environ 157 GB chez nous, parce que nous décompactons pendant le téléchargement et ne matérialisons jamais les volumes d'archive. Si votre disque ne peut pas contenir deux fois la tâche, cet écart n'est pas un pourcentage, c'est la différence entre télécharger et ne pas télécharger.
Les E/S du volume, c'est de l'usure et du temps. Écrire le post, le relire pour le vérifier, le relire encore pour le décompacter et écrire la sortie fait quatre passages sur les données. Le faire en une passe représente environ un tiers du trafic, ce qui sur un disque SSD est de la durée de vie, et sur un disque plus lent est souvent le vrai goulot d'étranglement plutôt que le réseau.
Une remarque sur la façon de lire ces deux chiffres, parce qu'elle nous a pris au dépourvu et pourrait vous prendre au dépourvu en lisant nos tableaux. Les deux proviennent de compteurs qui couvrent tout le disque, pas un seul programme. Cela en fait un excellent contrôle pour savoir si un benchmark a été pollué par autre chose en cours d'exécution, et cela signifie qu'un chiffre qui paraît impossible l'est généralement : une tâche de 6.5 GB annonçant 144 GB de trafic disque n'est pas un client au comportement étrange, ce sont deux tâches qui se partagent une machine.
Lire un tableau
Les tableaux eux-mêmes, avec la version et la date à côté de chacun, sont sur la page des benchmarks, y compris les manches que nous perdons.