Spiegazioni · quattro
Cinque colonne compaiono nella maggior parte delle nostre tabelle. Ecco cosa misura ciascuna, perché vale la pena pubblicarla, e più o meno che aspetto ha un valore buono o cattivo su una macchina che possiedi davvero.
Il dato principale
Il cronometro parte quando il lavoro viene aggiunto e si ferma quando il contenuto finito esiste su disco, verificato ed estratto. Non quando finisce lo scaricamento, e non quando il client si dichiara pronto.
È l'unico numero che corrisponde a qualcosa che vivi davvero. Un client può finire di scaricare in fretta e poi passare un minuto a verificare e scompattare, e da dove sei seduto quel minuto fa parte dell'attesa. Misurare solo lo scaricamento favorirebbe i client che fanno il lavoro dopo, cioè quasi tutti.
È anche il motivo per cui la nostra architettura appare insolita in queste tabelle. Verifichiamo ogni pezzo appena arriva e scompattiamo mentre lo scaricamento è ancora in corso, così quando arriva l'ultimo articolo resta pochissimo da fare. Gli altri client depositano prima tutto il post su disco, poi lo verificano, poi lo scompattano, in tre fasi consecutive. Su un lavoro facile la differenza è modesta. Su uno grande o danneggiato è quasi tutto il risultato.
Quella che si legge male
La quantità massima di memoria che il programma ha tenuto in un qualsiasi momento del lavoro. RSS sta per resident set size, cioè semplicemente la memoria davvero in RAM anziché promessa o riservata.
Più alto non è automaticamente peggio, e più basso non è automaticamente meglio. La memoria viene spesa per evitare qualcosa di più costoso, di solito leggere due volte gli stessi dati dal disco. La domanda che conta è se quella spesa compri qualcosa e se sia limitata.
Limitata è la parola importante. Un client la cui memoria cresce con la dimensione del lavoro prima o poi incontrerà un lavoro che non riesce a finire sulla tua macchina, e il guasto arriva come swap o processo ucciso anziché come messaggio cortese. Noi teniamo un budget e ci restiamo dentro, ed è per questo che possiamo far passare un lavoro da 190 GB su una macchina in cui abbiamo circa 1.1 GB di memoria disponibile. Una cifra come 9.3 GB su un lavoro da 190 GB non è soltanto grande, è di forma diversa: cresce col lavoro.
Dove sale la nostra memoria, proviamo a dire cosa ha comprato. Sui post gravemente danneggiati la build attuale tiene i dati di parità in memoria per riparare subito invece di procurarsene altri dopo, il che porta la memoria di picco da circa 0.8 GB a circa 1.3 GB e fa risparmiare una decina di secondi. Su un post integro quella spesa non avviene e la cifra è 0.24 GB.
L'indicatore di consumo
Il tempo di processore totale consumato dall'intero programma, sommato su tutti i core. È una misura del lavoro svolto anziché del tempo trascorso, quindi può essere molto maggiore del cronometro.
Se un lavoro dura 100 secondi e riporta 1,600 secondi di processore, all'incirca sedici core sono stati occupati per tutta la durata. Conta per tre motivi pratici: è calore, è elettricità, e su una macchina che nel frattempo fa altro è contesa. Un client che finisce in un tempo ragionevole saturando ogni core non è stato efficiente, è stato costoso.
È in questa colonna che compaiono le differenze più ampie di tutto il sito, più ampie di qualsiasi tempo di arrivo. A parità di output identico byte per byte sullo stesso post danneggiato, abbiamo misurato uno scarto di trenta volte nei secondi di processore tra client. Vale la pena controllarlo prima di dare per scontato che due client che finiscono a pochi secondi l'uno dall'altro stiano facendo una quantità di lavoro paragonabile.
Le due colonne del disco
Il picco di disco è il massimo spazio aggiuntivo che il lavoro ha richiesto in un dato istante. L'I/O del volume è la quantità totale di dati letti e scritti per arrivarci. Rispondono a domande diverse.
Il picco di disco è un vincolo netto. Decide se il lavoro può girare del tutto. La maggior parte dei client scrive l'intero post su disco e poi ne scompatta una seconda copia accanto, quindi serve loro circa il doppio del contenuto in spazio libero. Per un lavoro da 190 GB sono circa 313 GB liberi prima di cominciare, contro circa 157 GB per noi, perché scompattiamo mentre scarichiamo e non materializziamo mai i volumi dell'archivio. Se il tuo disco non regge il doppio del lavoro, quella differenza non è una percentuale, è se lo scaricamento avviene o no.
L'I/O del volume è usura e tempo. Scrivere il post, rileggerlo per verificarlo, rileggerlo ancora per scompattarlo e scrivere l'output fa quattro passate sui dati. Farlo in una passata sola è circa un terzo del traffico, che su un disco a stato solido è vita del disco, e su un disco più lento è spesso il vero collo di bottiglia anziché la rete.
Una nota su come leggiamo questi due, perché ci ha colti in fallo e potrebbe cogliere in fallo anche te leggendo le nostre tabelle. Entrambe le cifre vengono da contatori che coprono l'intero disco, non un singolo programma. Questo li rende un ottimo controllo su un benchmark contaminato da qualcos'altro in esecuzione, e significa che un numero che sembra impossibile di solito lo è: un lavoro da 6.5 GB che riporta 144 GB di traffico su disco non è un client che si comporta in modo strano, sono due lavori che condividono una macchina.
Leggere una tabella
Le tabelle vere e proprie, con la build e la data accanto a ciascuna, sono nella pagina dei benchmark, comprese le prove che perdiamo.