Explicações · quatro
Cinco colunas aparecem na maioria das nossas tabelas. Eis o que cada uma mede, porque vale a pena publicá-la, e mais ou menos o aspeto de um valor bom ou mau numa máquina que tenhas mesmo.
O número principal
O cronómetro arranca quando a tarefa é adicionada e para quando o conteúdo terminado existe no disco, verificado e extraído. Não quando o descarregamento acaba, e não quando o cliente se declara pronto.
É o único número que corresponde a algo que tu vives. Um cliente pode acabar de descarregar depressa e depois passar um minuto a verificar e a desempacotar, e de onde estás sentado esse minuto faz parte da espera. Medir só o descarregamento favoreceria os clientes que fazem o trabalho depois, ou seja, quase todos.
É também porque a nossa arquitetura parece invulgar nestas tabelas. Verificamos cada peça à medida que chega e desempacotamos enquanto o descarregamento ainda decorre, portanto quando o último artigo aterra resta muito pouco por fazer. Os outros clientes depositam primeiro todo o post no disco, depois verificam-no, depois desempacotam-no, em três fases seguidas. Numa tarefa fácil a diferença é modesta. Numa tarefa grande ou danificada é quase todo o resultado.
A que se lê mal
A maior quantidade de memória que o programa manteve em qualquer momento da tarefa. RSS significa resident set size, ou seja, simplesmente a memória que está mesmo na RAM em vez de prometida ou reservada.
Mais alto não é automaticamente pior, e mais baixo não é automaticamente melhor. A memória é gasta para evitar algo mais caro, em geral ler duas vezes os mesmos dados do disco. A pergunta que interessa é se esse gasto compra alguma coisa e se está limitado.
Limitado é a palavra importante. Um cliente cuja memória cresce com o tamanho da tarefa acabará por encontrar uma tarefa que não consegue terminar na tua máquina, e a falha chega como troca para disco ou processo abatido em vez de uma mensagem educada. Nós mantemos um orçamento e ficamos dentro dele, e é por isso que conseguimos passar uma tarefa de 190 GB por uma máquina onde temos cerca de 1.1 GB de memória disponível. Um valor como 9.3 GB numa tarefa de 190 GB não é só grande, é de outra forma: cresce com o trabalho.
Onde a nossa própria memória sobe, tentamos dizer o que comprou. Em posts muito danificados a compilação atual mantém os dados de paridade em memória para reparar de imediato em vez de ir buscar mais depois, o que leva a memória de pico de cerca de 0.8 GB a cerca de 1.3 GB e poupa uns dez segundos. Num post intacto esse gasto não acontece e o valor é 0.24 GB.
O indicador de consumo
O tempo de processador total consumido pelo programa inteiro, somado em todos os núcleos. É uma medida do trabalho feito e não do tempo decorrido, por isso pode ser muito maior do que o cronómetro.
Se uma tarefa demora 100 segundos e reporta 1,600 segundos de processador, cerca de dezasseis núcleos estiveram ocupados durante toda a execução. Isso importa por três razões práticas: é calor, é eletricidade, e numa máquina a fazer outra coisa ao mesmo tempo é disputa de recursos. Um cliente que acaba num tempo razoável saturando todos os núcleos não foi eficiente, foi caro.
É nesta coluna que aparecem as diferenças mais largas de todo o sítio, mais largas do que em qualquer tempo de chegada. Para uma saída idêntica byte a byte no mesmo post danificado, medimos uma dispersão de trinta vezes em segundos de processador entre clientes. Vale a pena verificar antes de dar por adquirido que dois clientes que acabam a poucos segundos um do outro estão a fazer uma quantidade de trabalho comparável.
As duas colunas de disco
O pico de disco é o máximo de espaço adicional de que a tarefa precisou num dado instante. A E/S do volume é a quantidade total de dados lidos e escritos para lá chegar. Respondem a perguntas diferentes.
O pico de disco é uma restrição rígida. Decide se a tarefa consegue sequer correr. A maioria dos clientes escreve o post completo no disco e depois desempacota uma segunda cópia ao lado, portanto precisa de cerca do dobro do conteúdo em espaço livre. Para uma tarefa de 190 GB são cerca de 313 GB livres antes de começar, contra cerca de 157 GB no nosso caso, porque desempacotamos enquanto descarregamos e nunca materializamos os volumes do arquivo. Se o teu disco não aguentar o dobro da tarefa, essa diferença não é uma percentagem, é se o descarregamento acontece ou não.
A E/S do volume é desgaste e tempo. Escrever o post, relê-lo para verificar, relê-lo outra vez para desempacotar e escrever a saída são quatro passagens sobre os dados. Fazê-lo numa só passagem é cerca de um terço do tráfego, o que num disco de estado sólido é tempo de vida, e num disco mais lento é muitas vezes o verdadeiro estrangulamento em vez da rede.
Uma nota sobre como lemos estes dois, porque nos apanhou e pode apanhar-te a ler as nossas tabelas. Ambos os valores vêm de contadores que cobrem o disco inteiro, não um único programa. Isso torna-os um excelente controlo sobre se um benchmark foi contaminado por outra coisa em execução, e significa que um número que parece impossível normalmente é: uma tarefa de 6.5 GB a reportar 144 GB de tráfego de disco não é um cliente a comportar-se de forma estranha, são duas tarefas a partilhar uma máquina.
Ler uma tabela
As próprias tabelas, com a compilação e a data ao lado de cada uma, estão na página de benchmarks, incluindo as voltas que perdemos.