Qué mide un CPU score y por qué dos servidores iguales no rinden igual
Publicado el 2026-09-12 por frfrand
De dónde sale ese número, qué mide y qué ignora, por qué un solo hilo puede importar más que dieciséis, y cómo medir lo que de verdad afecta a tu aplicación.
Cuando comparás servidores aparecen números: puntajes de rendimiento, frecuencias, generaciones. Vale entender qué miden, porque elegir por el número equivocado cuesta plata.
Qué es un puntaje
Un puntaje de CPU es el resultado de ejecutar un conjunto de tareas conocidas y medir cuánto tardó. Nada más.
Hay dos familias que se confunden todo el tiempo:
Un hilo. Mide qué tan rápido completa una sola tarea de principio a fin. Depende de la frecuencia, de cuántas instrucciones ejecuta por ciclo y de la memoria caché.
Muchos hilos. Mide el trabajo total con todos los núcleos ocupados. Depende sobre todo de cuántos núcleos hay.
Un procesador con 32 núcleos lentos puede tener un puntaje multihilo enorme y un puntaje de un hilo mediocre. Otro con 8 núcleos rápidos, lo contrario.
Cuál mirar
Depende por completo de qué hace tu software.
Si atendés peticiones web, cada petición normalmente la resuelve un hilo. La latencia que siente el usuario depende del rendimiento de un hilo. Tener 32 núcleos te permite atender más peticiones a la vez, pero no hace que cada una responda más rápido.
Por eso, para la mayoría de las aplicaciones web, el rendimiento por hilo importa más de lo que la gente cree.
Si compilás, procesás vídeo o corrés trabajos por lotes, ahí sí manda el multihilo.
Y si tu aplicación pasa la mayor parte del tiempo esperando (la base de datos, un servicio externo, el disco), ninguno de los dos números importa mucho. Agregar núcleos a un servidor que está al 20% no cambia nada.
Por qué dos servidores "iguales" difieren
Cuatro razones, y ninguna aparece en la tabla de precios:
La generación. Un núcleo de hace ocho años y uno actual pueden diferir en el doble a la misma frecuencia, porque ejecutan más instrucciones por ciclo.
La frecuencia sostenida. Los procesadores aceleran cuando hay trabajo y bajan cuando se calientan. Una prueba de diez segundos y una carga de diez minutos dan resultados distintos. Para un servidor, importa la segunda.
Los vecinos. En un plan compartido, el rendimiento depende de qué estén haciendo los demás. Eso no lo captura ningún puntaje publicado.
La memoria. Ancho de banda y latencia. Muchas cargas están limitadas por la memoria y no por el procesador; ahí, dos máquinas con el mismo procesador y distinta configuración de memoria rinden distinto.
Cómo medir lo tuyo
Lo genérico da una referencia:
sysbench cpu --threads=1 run # un hilo sysbench cpu --threads=$(nproc) run # todos
Pero lo que de verdad importa es medir tu carga. Y para eso conviene mirar tres cosas en el servidor real:
- El uso de CPU durante el trabajo real. Si tu aplicación está al 20% y va lenta, el problema no es el procesador.
- El tiempo robado (columna "st" en vmstat). Si es alto, estás compitiendo con vecinos.
- El promedio de carga comparado con la cantidad de núcleos. Un promedio de 8 en una máquina de 8 núcleos significa que está justa; en una de 2 núcleos significa que hay cola.
La conclusión práctica
Antes de pagar por un plan con más núcleos, comprobá que el procesador sea el cuello de botella. En aplicaciones web, muy seguido el límite está en la base de datos, en una consulta sin índice o en una llamada externa lenta.
Cambiar el plan en esos casos cuesta más y no mejora nada.