High Performance MySQL [Cap. 2: Benchmarking de MySQL]
High Performance MySQL
- Un benchmark es un experimento controlado. Escribe la pregunta antes de escribir el script.
- Reporta percentiles, no promedios. Una sola petición atascada puede mover la media; al p95 apenas lo toca.
- Throughput, latencia, concurrencia y escalabilidad responden preguntas distintas. Mide la que necesitas.
- La mayoría de los malos benchmarks fallan en el realismo: pocos datos, una distribución equivocada o una carga que llega demasiado rápido.
Para qué hacer benchmarks
Una base de datos de desarrollo con unos cientos de filas casi no te dice nada sobre producción. Los benchmarks te permiten someter el sistema a la carga que elijas y observarlo: cuánto aguanta, dónde empieza a ceder, si una suposición sobre el hardware o el esquema se sostiene y cómo se comporta en los casos límite que preferirías no encontrarte en vivo. También son la forma honesta de comparar dos diseños antes de comprometerte con uno.
Su punto débil es que la carga es inventada. El tráfico real es desordenado, llega a ráfagas y se reparte de forma desigual sobre los datos. Un benchmark que lo ignora produce números precisos y equivocados.
Dónde mienten los benchmarks
- Tamaño de los datos. Una prueba de 1 GB para una tabla de 100 GB cabe entera en el buffer pool y mide la memoria, no el almacenamiento.
- Distribución. Las claves uniformemente aleatorias reparten la carga de forma pareja; los usuarios reales machacan unas pocas filas calientes y dejan frías las demás.
- Ritmo de llegada. Lanzar consultas una tras otra lo más rápido posible no se parece a ningún cliente real y genera una contención que nunca ocurre en producción.
- Extrapolación. Que un servidor soporte 10× transacciones por segundo no significa que el negocio pueda crecer 10×. El crecimiento trae funcionalidades nuevas y consultas más pesadas, no solo más de las de hoy.
Pila completa o un solo componente
Hacer benchmark de toda la aplicación, desde HTTP hasta la base de datos, responde la pregunta que les importa a los usuarios: ¿qué tan rápido es el producto? Captura los saltos de red, las cachés de la aplicación y la serialización, pero es caro de montar y ruidoso de interpretar.
Hacer benchmark de MySQL por separado es la herramienta adecuada para preguntas más acotadas: cuál de dos consultas es más barata, si un cambio de esquema ayuda, qué efecto tiene una variable de configuración. Menos piezas en movimiento significa resultados que puedes atribuir a una causa.
Qué medir
| MÉTRICA | QUÉ RESPONDE |
|---|---|
| Throughput | Trabajo por unidad de tiempo, normalmente transacciones por segundo. Suites estándar como TPC-C lo miden para cargas OLTP. |
| Latencia | Cuánto tarda una tarea. Resúmela con percentiles: p95 = 200 ms significa que el 95% de las peticiones terminan en 200 ms o menos. El mínimo y el máximo miden sobre todo la suerte; la media la arrastran los valores atípicos. |
| Concurrencia | Cuántas tareas se ejecutan a la vez. Cuenta los hilos que realmente están trabajando, no las conexiones abiertas: miles de usuarios navegando pueden producir solo un puñado de consultas concurrentes. |
| Escalabilidad | Cómo cambia el rendimiento cuando cambian la carga o los recursos. Pocos sistemas son lineales; la mayoría muestra rendimientos decrecientes y luego empeora. |
Estas métricas se complementan. Una latencia excelente con un solo hilo no dice nada de lo que pasa con 64 clientes concurrentes.
Un benchmark en el que puedas confiar
- Elige a propósito entre estándar o a medida. Una suite estándar tiene que parecerse a tu carga: un benchmark analítico como TPC-H te dice poco sobre un servicio OLTP.
- Parte de datos reales. Toma una instantánea de producción (anonimizada si hace falta) y consérvala para que cada ejecución empiece desde el mismo estado.
- Reproduce consultas reales. Captura los logs de consultas de producción en periodos representativos en lugar de inventar una mezcla de consultas.
- Calienta y luego ejecuta el tiempo suficiente. Las cachés se llenan y el throughput oscila antes de estabilizarse. Como regla práctica, sigue midiendo al menos tanto tiempo como duró el calentamiento.
- Regístralo todo, en bruto. Los datos de más cuestan disco; los que faltan cuestan repetir la prueba. Guarda las muestras en bruto para poder agregarlas de otra forma más adelante.
- Automatiza. Una ejecución con script es repetible, y la repetibilidad es lo que permite comparar dos configuraciones.
Herramientas
Para MySQL por separado, mysqlslap viene con el servidor: puede crear un esquema de prueba, ejecutar un archivo de consultas o consultas generadas a través de muchas conexiones y reportar tiempos. sysbench es la opción habitual para benchmarks de tipo OLTP y de hardware. Para pruebas de pila completa, los generadores de carga HTTP atacan la aplicación desde fuera. Elijas lo que elijas, aprende bien un conjunto pequeño de herramientas y escribe scripts alrededor.
Cómo se refleja en QueryCrack
QueryCrack no puntúa el tiempo real a propósito. El tiempo depende del estado de la caché, de los vecinos y de la suerte: justo el ruido del que advierte este capítulo. Las filas examinadas son deterministas para un plan y un conjunto de datos dados, así que funcionan como métrica de benchmark sin varianza: la misma consulta siempre obtiene la misma nota.
Preguntas frecuentes
¿Por qué no reportar simplemente la latencia media?
Los promedios esconden la cola. Unas pocas peticiones lentas pueden dominar la media mientras la mayoría de los usuarios ve respuestas rápidas, o una media rápida puede esconder un p99 doloroso. Los percentiles describen lo que los usuarios experimentan de verdad.
¿Cuántos datos necesita un benchmark?
Los suficientes para que el conjunto de trabajo guarde con la memoria la misma relación que en producción. Si producción no cabe en el buffer pool, el benchmark tampoco debe caber.
Fuente: Schwartz, Zaitsev y Tkachenko, High Performance MySQL, capítulo 2: Benchmarking MySQL. Son nuestras notas, no un sustituto del libro.