Una prueba de referencia es una prueba controlada que simula una carga real o aísla un aspecto del sistema para comparar resultados en condiciones iguales. La idea es simple: fijar el entorno, repetir el procedimiento y comparar las cifras. Lo fundamental es elegir no el «test más popular», sino el que refleje exactamente su escenario. De lo contrario se obtendrá un gráfico atractivo sobre la vida de otra persona.
¿Por qué ejecutar una prueba de referencia?
Convertir sensaciones en hechos y tomar decisiones sin adivinaciones. Cuando hay cifras, desaparecen las discusiones del tipo «me parece» y aparecen acciones concretas: actualización, ajuste, cambio de plan tarifario o modificación de un nodo arquitectónico.
- Compras y actualizaciones: elegir CPU/GPU, discos e instancias en la nube por motivos técnicos, no por publicidad.
- Planificación de capacidad: entender cuánto tráfico soportará el sistema con un SLO dado.
- Regresiones: detectar degradaciones tras lanzamientos en comparación con la línea base.
- Economía: calcular rendimiento por dólar y por vatio.
Como beneficio adicional obtiene un historial de cambios: cómo varió la velocidad tras parches, migraciones y actualizaciones de hardware. Esa «crónica» ahorra presupuesto y nervios.
Clasificación: en pocas palabras
Diferentes tareas requieren diferentes pruebas; de lo contrario se comparan peras con tornillos. Primero hay que decidir qué se quiere medir: el resultado final para el usuario o el comportamiento de un nodo aislado.
- Aplicadas vs sintéticas: «como en la vida real» frente a mediciones puntuales de subsistemas.
- Micro/meso/macro: desde una función o un disco hasta un escenario de extremo a extremo.
- Rendimiento vs conformidad: velocidad frente a corrección/compatibilidad.
- Carga/estrés/durabilidad: funcionamiento normal, extremos y pruebas de larga duración.
La estrategia ideal combina una prueba aplicada para una imagen realista y una o dos sintéticas para encontrar rápidamente el cuello de botella.
Métricas clave
Una cifra rara vez cuenta la verdad: observamos distribuciones y colas. El usuario no nota la «media», sino las latencias en los peores momentos, por eso prestar atención a p95/p99 es cuidar la experiencia, no preparar una presentación.
- Latencias: p50/p95/p99, tiempo hasta el primer byte, carga completa.
- Capacidad de transferencia: RPS/QPS, fotogramas/seg, tokens/sec.
- E/S (IO): IOPS, ancho de banda secuencial/aleatorio, latencia de lectura/escritura.
- Energía y coste: rendimiento por vatio y por dólar.
- Estabilidad: jitter, varianza, timeouts; para ML — además métricas de calidad.
Fije el contexto: tamaños de datos, perfiles de consultas, limitaciones de potencia. Sin eso, cualquier gráfico bonito carece de sentido.
Cómo elegir una prueba de referencia
Formule la pregunta y solo después nombre la prueba. Si el objetivo es seleccionar una instancia para un SLA, use un escenario de extremo a extremo; si necesita entender por qué «va lento», haga micropruebas de disco, red, CPU y memoria.
- Describa su escenario: perfil de solicitudes, volúmenes de datos, criterios de calidad.
- Elija la clase: micro — para diagnóstico, macro — para comparar plataformas.
- Fije métricas y objetivos: qué percentiles y valores son críticos.
- Verifique representatividad y repetibilidad: conjunto de datos, metodología, versiones.
No dude en adaptar una prueba estándar a su caso: cambie proporciones de operaciones, tamaños de objetos y timeouts — así el resultado será más cercano a la realidad.
Conjuntos populares: qué y cuándo
A continuación, un mapa breve del terreno. Los enlaces llevan a páginas oficiales y documentación; siempre verifique versiones y condiciones de ejecución.
CPU y sistema general
Adecuado cuando se necesita entender el potencial de la plataforma y comparar compilaciones y configuraciones.
- SPEC CPU — pruebas comparativas rigurosas de procesadores.
- Geekbench — sintéticos rápidos para orientarse.
- Cinebench — proxy para multihilo/renderizado.
- Phoronix Test Suite — automatización de escenarios en Linux.
GPU y gráficos
Adecuado para gaming, visualización y evaluación de tarjetas gráficas en estaciones de trabajo.
ML y LLM
Separe calidad y velocidad: una sin la otra no ofrece una visión completa.
- MLPerf — entrenamiento e inferencia con reglas claras.
- Open LLM Leaderboard — calidad de modelos en conjuntos abiertos.
- vLLM — infraestructura para mediciones propias de velocidad/coste.
Bases de datos y almacenamiento
Selección para sistemas transaccionales, analítica y evaluación de la subsistema de disco.
- TPC-C/H/DS — transacciones y analítica con metodología transparente.
- YCSB — perfiles de carga para NoSQL.
- fio y CrystalDiskMark — mediciones puntuales de E/S.
Redes y web
Combine mediciones de red y métricas de usuario para obtener la imagen completa.
- iPerf — capacidad, pérdida y jitter.
- k6, JMeter, Locust, wrk — carga para APIs HTTP.
- WebPageTest, Lighthouse — velocidad de frontend desde la perspectiva del usuario.
Móviles y escenarios de usuario
Para teléfonos y navegadores importan las sensaciones, por eso se simulan acciones típicas.
- PCMark for Android — «como en la vida real» en smartphones.
- JetStream y Speedometer — capacidad de respuesta del navegador y del motor JS.
Recetas breves para objetivos
Mínimo de elementos irrelevantes — máximo de utilidad. Tome un escenario real, añada una prueba de diagnóstico y verifique las colas de la distribución, no solo la media.
- Juegos/gráficos: 3DMark + telemetría de FPS en sus proyectos; para renderizado — Cinebench.
- OLTP/analítica: TPC-C/H/DS y perfiles propios; para NoSQL — YCSB.
- HTTP-API: k6/ JMeter/ wrk + p95/p99; frontend — WebPageTest/ Lighthouse.
- Inferencia LLM: calidad según Leaderboard, velocidad/coste en su propia configuración mediante vLLM.
Si hay poco tiempo, ejecutar una prueba aplicada ya ofrece una base para decidir. Lo demás se puede completar más adelante, cuando haya oportunidad.
Metodología sin autoengaños
De lo contrario cualquier «ganancia» resultará ser un espejismo. Un procedimiento honesto es más importante que una herramienta exótica: el orden vence al caos.
- Aísle el entorno; fije versiones de SO/controladores/bibliotecas.
- Vigile temperatura y energía; evite el throttling.
- Warm-up y varios pases; observe la mediana y los percentiles.
- Tenga en cuenta caches y parámetros de datos; para ML — fije semillas y conjuntos de datos.
Guarde resultados crudos, configuraciones y scripts — así la reproducción no será un desafío y las conclusiones inspirarán confianza.
Cómo interpretar los resultados
El sentido importa más que una «puntuación bonita». Compare no solo la velocidad, sino el coste para alcanzar el SLA objetivo con las restricciones dadas.
- Enfóquese en p95/p99, no solo en la media.
- Compare rendimiento con precio y consumo energético.
- Identifique los cuellos de botella (CPU, E/S, red, bloqueos).
- No lleve la optimización «para la prueba» a la vida real sin verificarlo.
Y recuerde: si una prueba muestra «peor», no es una derrota, sino una indicación de dónde dirigir esfuerzos para una mejora real.
Conclusión
Una prueba de referencia es una herramienta para resolver una tarea concreta. Describa su escenario, elija el conjunto adecuado, asegure una metodología honesta e interprete las cifras en el contexto del precio y la energía. Entonces el «parece más rápido» se convertirá en un «funciona mejor — y aquí está la razón». Lo demás es cuestión de técnica y disciplina.
