Explicaciones · cuatro
Cinco columnas aparecen en la mayoría de nuestras tablas. Esto es lo que mide cada una, por qué merece publicarse, y más o menos qué aspecto tiene un valor bueno o malo en una máquina que tengas tú de verdad.
La cifra principal
El reloj arranca cuando se añade el trabajo y se para cuando el contenido terminado existe en el disco, verificado y extraído. No cuando acaba la descarga, y no cuando el cliente se declara listo.
Es la única cifra que se corresponde con algo que tú vives. Un cliente puede terminar de descargar rápido y luego pasar un minuto comprobando y desempaquetando, y desde donde estás sentado ese minuto forma parte de la espera. Medir solo la descarga favorecería a los clientes que hacen su trabajo después, que son casi todos.
También es la razón de que nuestra arquitectura parezca rara en estas tablas. Verificamos cada pieza según llega y desempaquetamos mientras la descarga sigue en marcha, así que cuando aterriza el último artículo queda muy poco por hacer. Los demás clientes depositan primero todo el post en el disco, luego lo verifican, luego lo desempaquetan, en tres fases seguidas. En un trabajo fácil la diferencia es modesta. En uno grande o dañado es casi todo el resultado.
La que se lee mal
La mayor cantidad de memoria que el programa mantuvo en cualquier momento del trabajo. RSS son las siglas de resident set size, es decir, sencillamente la memoria que está de verdad en la RAM y no prometida o reservada.
Más alto no es automáticamente peor, y más bajo no es automáticamente mejor. La memoria se gasta para evitar algo más caro, normalmente leer dos veces los mismos datos del disco. La pregunta que vale la pena hacerse es si ese gasto compra algo y si está acotado.
Acotado es la palabra importante. Un cliente cuya memoria crece con el tamaño del trabajo acabará encontrándose con un trabajo que no puede terminar en tu máquina, y el fallo llega como intercambio a disco o como proceso matado, no como un mensaje cortés. Nosotros mantenemos un presupuesto y nos quedamos dentro, y por eso podemos pasar un trabajo de 190 GB por una máquina donde tenemos alrededor de 1.1 GB de memoria disponible. Una cifra como 9.3 GB en un trabajo de 190 GB no es solo grande, es de otra forma: crece con el trabajo.
Donde sube nuestra propia memoria, intentamos decir qué compró. En posts muy dañados la compilación actual mantiene los datos de paridad en memoria para reparar de inmediato en vez de buscar más después, lo que lleva la memoria máxima de unos 0.8 GB a unos 1.3 GB y ahorra unos diez segundos. En un post intacto ese gasto no ocurre y la cifra es 0.24 GB.
El indicador de consumo
El tiempo de procesador total consumido por todo el programa, sumado en todos los núcleos. Es una medida del trabajo hecho más que del tiempo transcurrido, así que puede ser mucho mayor que el reloj.
Si un trabajo tarda 100 segundos y reporta 1,600 segundos de procesador, aproximadamente dieciséis núcleos estuvieron ocupados durante toda la ejecución. Eso importa por tres razones prácticas: es calor, es electricidad, y en una máquina que hace algo más al mismo tiempo es competencia por los recursos. Un cliente que termina en un tiempo razonable saturando todos los núcleos no ha sido eficiente, ha sido caro.
En esta columna aparecen las diferencias más amplias de todo el sitio, más amplias que en cualquier tiempo de llegada. Para una salida idéntica byte a byte en el mismo post dañado, hemos medido una dispersión de treinta veces en segundos de procesador entre clientes. Vale la pena comprobarlo antes de dar por hecho que dos clientes que terminan con pocos segundos de diferencia están haciendo una cantidad de trabajo comparable.
Las dos columnas de disco
El pico de disco es el máximo espacio adicional que el trabajo necesitó en un instante dado. La E/S del volumen es la cantidad total de datos leídos y escritos para llegar ahí. Responden a preguntas distintas.
El pico de disco es una restricción dura. Decide si el trabajo puede ejecutarse siquiera. La mayoría de los clientes escriben el post completo en el disco y luego desempaquetan una segunda copia al lado, así que necesitan aproximadamente el doble del contenido en espacio libre. Para un trabajo de 190 GB eso son unos 313 GB libres antes de empezar, frente a unos 157 GB en nuestro caso, porque desempaquetamos mientras descargamos y nunca materializamos los volúmenes del archivo. Si tu disco no aguanta el doble del trabajo, esa diferencia no es un porcentaje, es si la descarga ocurre o no.
La E/S del volumen es desgaste y tiempo. Escribir el post, releerlo para verificarlo, releerlo otra vez para desempaquetarlo y escribir la salida son cuatro pasadas sobre los datos. Hacerlo en una sola pasada es aproximadamente un tercio del tráfico, que en un disco de estado sólido es vida útil, y en un disco más lento suele ser el auténtico cuello de botella en lugar de la red.
Una nota sobre cómo leemos estos dos, porque nos pilló a nosotros y podría pillarte a ti leyendo nuestras tablas. Ambas cifras vienen de contadores que cubren todo el disco, no un solo programa. Eso los convierte en un control excelente de si un benchmark se contaminó con otra cosa en ejecución, y significa que un número que parece imposible normalmente lo es: un trabajo de 6.5 GB que reporta 144 GB de tráfico de disco no es un cliente comportándose de forma extraña, son dos trabajos compartiendo una máquina.
Leer una tabla
Las tablas en sí, con la compilación y la fecha junto a cada una, están en la página de benchmarks, incluidas las vueltas que perdemos.