En las tres lecciones anteriores hemos dado muchos números: 641 peticiones por segundo, luego 3 105, luego 11 840; percentiles 99 de 204, 54 y 11 milisegundos; un retraso del bucle de eventos que pasó de 4 176 ms a 11 ms. Esos números no salieron de la intuición: salieron de medir antes, cambiar una cosa y medir después. Esa práctica, que hemos aplicado sin nombrarla, es el contenido de esta lección.

Aquí no vas a encontrar una lista de trucos, sino un método, un catálogo de instrumentos (pruebas de carga, perfiles de CPU, flamegraphs, instantáneas del montículo) y un catálogo de cuellos de botella típicos de Node con su arreglo, todos anclados a lo que ya sabes del curso.

1. El método: medir, localizar, arreglar, volver a medir
2. Qué se mide: latencia, rendimiento, errores, saturación
3. Pruebas de carga con autocannon
4. Perfilado de CPU y flamegraphs
5. Perfilado de memoria y fugas
6. El retraso del bucle de eventos como métrica de salud
7. Catálogo de cuellos de botella típicos en Node
8. Optimizaciones de la capa HTTP
9. La base de datos: el pool de conexiones
10. V8 sin caer en el micro-optimizado inútil
11. El orden correcto de las palancas

El ciclo tiene cuatro pasos y ninguno es opcional: medir el sistema completo bajo una carga realista y anotar la línea base; localizar el cuello de botella con un perfil, no con una corazonada; arreglar solo eso, un cambio cada vez; y volver a medir con la misma prueba, comparando con la línea base.

Un cambio por iteración es innegociable. Si tocas tres cosas y el sistema mejora un 30 %, no sabes cuál de las tres funcionó, ni si alguna empeoró las cosas y las otras dos lo compensaron.

La cita de Donald Knuth se repite mucho y casi siempre mutilada. La frase completa es: "deberíamos olvidarnos de las pequeñas eficiencias, digamos el 97 % del tiempo: la optimización prematura es la raíz de todos los males. Sin embargo, no deberíamos dejar pasar nuestras oportunidades en ese 3 % crítico." Los dos extremos son errores: reescribir un bucle para ahorrar microsegundos en código que se ejecuta una vez al día, y también ignorar que tu consulta principal hace un escaneo secuencial sobre una tabla de un millón de filas. La diferencia entre ambos no es filosófica: es que uno lo has medido y el otro no. Corolario práctico: optimizar sin medir es adivinar, y la intuición del programador sobre dónde está el tiempo es notoriamente mala. En Escena Viva cualquiera habría apostado a que el cuello estaba en generar el PDF; el perfil demostró que en el catálogo el 62 % del tiempo se iba en serializar JSON y en una consulta sin índice.

Cuatro señales, conocidas como las golden signals:

Sobre la latencia hay que insistir en algo, y es que la media miente:

Si diez peticiones tardan 10 ms y una tarda 5 000 ms, la media es 463 ms: un número que no describe ni a las rápidas ni a la lenta. Y la aritmética del p99 asusta cuando se traduce a experiencia: una página que hace 12 llamadas a la API tiene una probabilidad de 1 − 0,99¹² ≈ 11 % de encontrarse al menos una petición del percentil 99. Optimizar la cola, no la media. Estos son los objetivos de servicio de Escena Viva, acordados con el negocio:

Ese último caso demuestra que no todo lo lento es un problema: bcrypt con coste 12 tarda ~250 ms a propósito, porque esa lentitud es la defensa contra la fuerza bruta (M8), y optimizarla sería una regresión de seguridad.

Una prueba de carga honesta cumple cuatro condiciones. Calentamiento: los primeros segundos no cuentan, porque V8 necesita ejecutar el código varias veces antes de que el compilador optimizador (TurboFan) haga su trabajo y las cachés están frías. Duración suficiente: 30-60 segundos mínimo, ya que diez segundos pueden esconder una fuga o el efecto de una recolección de basura mayor. Concurrencia realista: no 5 000 conexiones si tu pico real son 200. Y escenario realista: no martillear una sola ruta trivial, sino reproducir el recorrido del usuario.

Un escenario de compra realista se define por programa:

Y así se lee la salida:

k6 es la alternativa cuando necesitas escenarios con estado (login, cookies, sesiones encadenadas), umbrales que hagan fallar la prueba en CI y carga distribuida: autocannon es perfecto para el ciclo rápido de "mide, cambia, mide", y k6 para la prueba de regresión de rendimiento en integración continua (M11).

Advertencia importante y no negociable. Una prueba de carga es, técnicamente, un ataque de denegación de servicio. Lánzala solo contra sistemas que sean tuyos y en entornos de prueba: nunca contra producción sin coordinación previa (y ahí, mejor tráfico espejo o carga sintética limitada), y nunca contra una API de terceros, ni la de divisas del M8, ni la pasarela de pago, ni un servicio público. Es ilegal en muchas jurisdicciones y siempre es una falta de respeto profesional.

La prueba de carga te dice que algo es lento; el perfil te dice dónde.

Opción 1: el perfilador integrado de V8. node --prof src/servidor.js genera un isolate-*.log con muestras del contador de programa; se lanza la carga, se para el servidor y node --prof-process isolate-*.log > perfil.txt lo convierte en un informe legible que empieza con el resumen que más importa:

Dos lecturas inmediatas: JSON.stringify se lleva el 15,5 % y la recolección de basura el 24,4 %, lo que sugiere que estamos creando demasiados objetos temporales. El * delante del nombre significa que V8 optimizó esa función; un ~ significaría que la ejecutó sin optimizar, y eso a veces es la pista de un problema de formas ocultas.

Opción 2: el inspector de Chrome DevTools. Con node --inspect src/servidor.js y chrome://inspect tienes perfil de CPU con gráfico de llamas, instantáneas del montículo y comparación entre ellas en una sola interfaz. En un servidor remoto se usa --inspect=0.0.0.0:9229 con un túnel SSH, nunca expuesto a internet: el inspector permite ejecutar código arbitrario en tu proceso.

Opción 3: 0x y los flamegraphs.

Cómo se lee un flamegraph, que es donde casi todo el mundo se equivoca:

• El eje horizontal NO es el tiempo, sino la proporción de muestras; las funciones se ordenan alfabéticamente, no cronológicamente.
• La anchura de una caja es el tiempo total en esa función, incluyendo lo que llamó. Es lo único que importa buscar: cajas anchas.
• La altura es la profundidad de la pila. Una torre muy alta y estrecha es solo código con muchas capas: no es un problema.
• Una caja ancha con una meseta plana encima significa que el tiempo se consume en ella misma, no en sus llamadas: ahí está tu función cara.
• El color no significa nada por defecto (salvo en 0x, que resalta las funciones no optimizadas).

En el flamegraph de Escena Viva antes de la caché, una meseta ancha sobre obtenerCatalogo → mapearEventos → JSON.stringify ocupaba casi dos tercios del ancho; tras la lección 10-03 esa meseta desaparece y el ancho lo ocupa el bucle ocioso de libuv, que es exactamente lo que quieres ver.

Una fuga de memoria en Node no se manifiesta como un error, sino como una degradación: el proceso crece, la recolección de basura trabaja cada vez más (y sus pausas son tiempo robado a tu bucle de eventos), y finalmente el proceso muere con JavaScript heap out of memory. Método de diagnóstico con instantáneas del montículo: arranca el proceso y déjalo estabilizarse; toma la instantánea A (DevTools → Memory → Heap snapshot, o v8.writeHeapSnapshot()); aplica carga sostenida durante varios minutos; fuerza una recolección y toma la instantánea B; y en DevTools elige la vista Comparison entre B y A.

La columna decisiva es Delta: cuántos objetos de cada tipo hay de más. Si Array o un constructor tuyo crece de forma monótona instantánea tras instantánea, ahí está la fuga; después, Retainers te dice quién impide que el recolector se los lleve.

Las dos fugas que verás en la vida real, y las dos aparecieron en Escena Viva. La primera, caché sin límite: antes de la lección 10-03, la caché de divisas era un Map en memoria que con pares fijos no crecía, pero que si la clave hubiera incluido el importe (EUR:USD:4500) habría crecido sin fin. Toda caché en memoria necesita un techo con expulsión LRU (lru-cache) o irse a Redis, que caduca sola. La segunda, oyentes no desregistrados: nuestro GestorDeVentas es un EventEmitter (M2), y si cada petición registra un oyente que nadie quita, el emisor acumula referencias a los cierres y con ellos a todo lo que capturan.

El aviso MaxListenersExceededWarning: Possible EventEmitter memory leak detected es Node diciéndote literalmente que tienes esta fuga. Nunca lo silencies subiendo setMaxListeners: arregla el desregistro.

Si tuvieras que elegir una sola métrica para saber si un proceso Node está sano, sería esta: la CPU al 90 % puede ser normal, pero un retraso del bucle de 800 ms nunca lo es.

Cómo interpretar los valores:

Es también el mejor valor para una comprobación de salud: un proceso con el bucle atascado responde 200 OK a un /salud trivial mientras deja tirados a todos los usuarios, y solo un /salud que mire el retraso del bucle detecta ese estado.

Dos merecen desarrollo. El primero, await secuencial donde cabía Promise.all, es el error de rendimiento más común y más barato de arreglar:

La condición es la independencia: si la segunda consulta necesita el resultado de la primera, el await secuencial es obligatorio. Y para operaciones donde el fallo de una no debe tumbar el resto, usa Promise.allSettled. El segundo es el ReDoS: expresiones regulares con retroceso catastrófico, el único cuello de botella de esta lista que además es una vulnerabilidad de seguridad (OWASP, M8), porque una sola petición de 40 caracteres puede congelar el proceso durante minutos.

La defensa en capas: validar longitud y forma con zod (M6) antes de cualquier regex, evitar cuantificadores anidados y desconfiar de las expresiones copiadas de internet para validar correos o URLs.

Antes de tocar tu código, comprueba que la capa de transporte no regala trabajo:

La compresión no es gratis: consume CPU. Con respuestas pequeñas (< 1 KB) cuesta más de lo que ahorra, y en un servidor con la CPU saturada puede ser contraproducente; en producción lo habitual es delegarla al proxy inverso (M11). Sobre las conexiones salientes, cada llamada al servicio de divisas del M8 sin keep-alive paga saludo TCP y negociación TLS: unos 40-80 ms de puro protocolo.

Abrir una conexión a PostgreSQL cuesta entre 5 y 50 ms (autenticación, TLS, proceso en el servidor). Por eso Sequelize mantiene un pool: un conjunto de conexiones abiertas que se prestan y devuelven.

Cómo se dimensiona, en orden: averigua max_connections del servidor (100 por defecto en PostgreSQL); reserva margen para migraciones, consumidores de cola y administración; divide el resto entre el número de procesos que conectan; y recuerda que más grande no es mejor, porque un pool de 100 contra 4 núcleos de base de datos solo añade contención (hay una fórmula clásica que sugiere núcleos × 2 + husos de disco como punto de partida).

Qué pasa cuando el pool se agota: las peticiones esperan hasta acquire y luego fallan con SequelizeConnectionAcquireTimeoutError, con un síntoma característico y engañoso —latencia altísima sin CPU alta, porque todo el mundo está esperando—. Si lo ves, mira primero si hay consultas lentas reteniendo conexiones o transacciones abiertas que nadie cierra.

V8 optimiza tu código mediante formas ocultas (hidden classes): objetos creados con la misma estructura comparten una descripción interna y el acceso a sus propiedades se compila a un desplazamiento fijo, rapidísimo. Si cambias la forma, V8 crea otra y el acceso pasa a ser polimórfico o megamórfico, mucho más lento.

Y sobre memoria: el montículo antiguo tiene un límite (típicamente ~2 GB en 64 bits, o menos en contenedores pequeños) que se ajusta con --max-old-space-size=2048. Dos matices imprescindibles: subirlo no arregla una fuga, solo retrasa la muerte y alarga las pausas de la recolección de basura; y en un contenedor hay que ponerlo por debajo del límite de memoria del contenedor, porque si no el sistema mata el proceso (OOM killer) antes de que V8 se dé cuenta (detalle que retomaremos en el M11).

La advertencia general: estas micro-optimizaciones importan en código que se ejecuta millones de veces. En un controlador HTTP que se ejecuta 3 000 veces por segundo y pasa el 95 % del tiempo esperando a la base de datos, reordenar propiedades no cambia nada. Aplícalas solo si el perfil señala esa función.

Cuando algo va lento hay un orden por retorno de la inversión:

Se recorre de arriba abajo. Comprar una máquina el doble de grande para tapar una consulta sin índice significa pagar el doble cada mes por un problema que se arreglaba con CREATE INDEX. Y así llegamos al recorrido real de Escena Viva en este módulo: primero concurrencia (10-01, 10-02), luego caché (10-03)... con el matiz honesto de que habría sido más eficiente empezar por el índice y la caché. Lo hicimos en el orden del temario por razones didácticas; en tu proyecto, sigue la tabla. Por último, qué se registra en producción para saber que todo sigue bien:

Recoger, almacenar y alertar sobre estas métricas es monitorización en producción, materia del módulo 11; aquí hemos aprendido a producirlas y a interpretarlas.

• Optimizar sin perfil. Es adivinar. En Escena Viva el sospechoso era el PDF y el culpable era el JSON.
• Fijarse en la media. Optimiza el p99; es lo que la gente experimenta y recuerda.
• Medir en desarrollo con datos de juguete. Con 3 eventos todo es rápido; con 30 000 aparece la consulta sin índice.
• Prueba de carga con non2xx distinto de cero, o cambiar varias cosas a la vez: en el primer caso mides la velocidad de fallar, en el segundo no sabrás qué funcionó.
• Perfilar en modo desarrollo. Sin NODE_ENV=production, Express no cachea vistas y hay comprobaciones extra: el perfil miente.
• Subir --max-old-space-size para tapar una fuga. Retrasa la caída y empeora las pausas de la GC.
• Consejo: guarda los resultados de la línea base en el repositorio; comparar contra el mes pasado detecta regresiones que ninguna prueba unitaria ve.
• Consejo: añade una prueba de carga con umbral en CI (k6 con thresholds) y el rendimiento pasa de ser una opinión a un requisito verificable.

Define una prueba de carga reproducible para GET /api/eventos/evt-003/sesiones con 10 s de calentamiento y 60 s de medición a 100 conexiones. Registra media, p50, p95, p99, req/s y non2xx. Compara con el objetivo de servicio de 200 ms y decide si hay que actuar.

Añade a Escena Viva un endpoint GET /api/informes/ocupacion que calcule la ocupación de las 7 sesiones ordenando el array de entradas con un algoritmo cuadrático deliberado. Perfila con 0x, localiza la caja ancha, sustituye por Array.prototype.sort y vuelve a medir.

Introduce una fuga registrando un oyente de venta-registrada en cada petición sin retirarlo. Lanza 30 000 peticiones registrando heapUsed cada 10 s. Toma dos instantáneas del montículo, compáralas y localiza el retenedor. Arregla y verifica.

Ejercicio 1. El escenario define warmup: { connections: 10, duration: 10 } y connections: 100, duration: 60. Resultado típico sin caché: media 96 ms, p50 84 ms, p95 210 ms, p99 340 ms, 1 030 req/s, non2xx: 0. El p99 de 340 ms incumple el objetivo de 200 ms, así que hay que actuar. La lectura fina es más interesante que el veredicto: la media (96 ms) parece cómoda y la mediana también; solo el p99 revela el problema. La causa habitual aquí es que las sesiones se cargan con una consulta por sesión (N+1): el arreglo es un include (M7) más caché (10-03), y tras aplicarlos el p99 baja a ~35 ms.

Ejercicio 2. En el flamegraph aparece una meseta ancha y plana sobre ordenarPorOcupacion, ocupando ~70 % del ancho, con muy poca profundidad encima: la señal inequívoca de que el tiempo se consume en esa función y no en sus llamadas. Con 7 sesiones el algoritmo cuadrático es irrelevante; el ejercicio revela su coste al hacerlo sobre las 1 811 entradas vendidas (~3,3 millones de comparaciones por petición). Sustituir por entradas.sort((a, b) => b.ocupacion - a.ocupacion) (O(n log n)) reduce el tiempo de la ruta de ~420 ms a ~6 ms. Es la palanca número 1 de la tabla —el algoritmo— y ninguna cantidad de cluster, hilos o caché habría dado un factor 70.

Ejercicio 3. heapUsed crece de forma monótona: 42 MB, 78 MB, 121 MB, 168 MB... sin estabilizarse nunca, ni siquiera tras una recolección forzada. Alrededor de la petición 10 000 aparece MaxListenersExceededWarning. En la comparación de instantáneas, el Delta muestra decenas de miles de objetos Closure y ServerResponse de más; los Retainers apuntan a GestorDeVentas._events['venta-registrada'], un array que crece sin fin. Cada cierre retiene respuesta, y con ella el socket y las cabeceras: por eso una fuga de "un oyente" cuesta kilobytes por petición. El arreglo es respuesta.on('close', () => gestor.off('venta-registrada', alVender)), y tras aplicarlo heapUsed se estabiliza en una sierra entre 45 y 70 MB: subida por asignación, bajada por recolección. Esa forma de sierra estable es exactamente el aspecto de un proceso sano.

Ya no optimizamos por intuición. Tenemos un método —medir, localizar, arreglar una cosa, volver a medir— y las cuatro señales que hay que vigilar, sabiendo que la media miente y que el p99 es lo que la gente experimenta. Sabemos diseñar una prueba de carga honesta con autocannon (calentamiento, duración, concurrencia y escenario realistas) y por qué jamás se lanza contra un sistema ajeno. Sabemos sacar un perfil de CPU con --prof, con el inspector o con 0x, y leer un flamegraph buscando cajas anchas y no torres altas. Sabemos cazar una fuga comparando instantáneas del montículo y mirando los retenedores. Y tenemos el retraso del bucle de eventos como la métrica de salud número uno. Además, hemos recorrido el catálogo de cuellos de botella de Node —E/S síncrona, JSON gigante, N+1, falta de índices, await secuencial, logging síncrono, ReDoS, datos cacheables— con su arreglo, hemos afinado la capa HTTP y el pool de conexiones, y hemos puesto las micro-optimizaciones de V8 en su sitio: al final de la lista, y solo si el perfil las señala. Sobre todo, tenemos el orden de las palancas: algoritmo, consulta, caché, concurrencia, hardware.

Escena Viva ya es rápida y está medida, así que lo que le queda pendiente no es rendimiento sino diseño. Su API creció por acumulación: rutas con verbos, códigos de estado usados a ojo, sin paginación por cursor, sin versionado, sin política de deprecación, y con una duda que dejamos abierta en el módulo 4 y que nunca resolvimos: qué pasa cuando un POST /api/pedidos se envía dos veces porque el usuario perdió la cobertura en el estreno. En la lección siguiente, Construcción de APIs RESTful, pasamos de "funciona" a "está bien diseñado".