5.2Rendimiento, clustering y escalado
Lo esencial en 30 segundos
- Monohilo : un proceso Node solo usa un núcleo — el clustering (módulo cluster o PM2) lanza una instancia por núcleo.
- Caché primero : poner en caché los resultados costosos (memoria o Redis) — a menudo la palanca más impactante.
- Medir antes de optimizar : perfilar para encontrar los verdaderos cuellos de botella — nunca optimización prematura.
Mini-caso hilado — Salim absorbe la carga en Argel
La API tipada de Salim en Argel empieza a ir lenta : la página de inicio de la tienda tarda en responder en horas punta. En vez de reescribirlo todo, mide : las consultas de catálogo vuelven sin cesar y la base se solicita para nada. Activa el clustering para aprovechar los núcleos del servidor y pone en caché el catálogo. Continuación del caso 5.1 — Salim optimiza lo que ha medido, no al azar.
Continuación del caso 5.1 — Salim aplica la regla de oro : medir primero, optimizar después.
1. Clustering y worker threads
Node es monohilo : un proceso solo usa un núcleo, mientras los servidores tienen varios. El clustering (módulo nativo cluster o PM2) lanza varias instancias de la aplicación (una por núcleo) que se reparten las peticiones — aprovechando todos los núcleos. PM2 añade el reinicio automático, la monitorización y los logs. Los worker threads, en cambio, ejecutan las tareas intensivas en CPU (cálculos pesados que bloquearían el bucle de eventos) en hilos separados. Salim lanza su API en modo clúster : la capacidad se multiplica sin cambiar una línea de lógica.
Reflejo : si un solo proceso corre en una máquina multinúcleo, hay recursos dormidos — el clustering es el escalado vertical estándar de Node.
2. Las palancas que rentan
Otras palancas : la puesta en caché (memoria o Redis — guardar los resultados costosos para no rehacerlos, a menudo lo más impactante), la optimización de consultas de base (indexación, evitar el problema N+1 — la base es muy a menudo el verdadero cuello de botella), no bloquear el bucle de eventos (nada de operaciones síncronas pesadas en el hilo principal), el paralelismo (Promise.all para operaciones independientes), y el escalado horizontal (varias instancias tras un balanceador de carga — de ahí el interés de las aplicaciones stateless y los JWT). Salim pone el catálogo en caché : las peticiones repetidas ya no tocan la base.
Orden de rentabilidad típico : base de datos (índice, N+1), caché, clustering, luego escalado horizontal — siempre guiado por la medición.
3. El buen método : medir, focalizar, verificar
Principio esencial : no optimizar prematuramente. Escribir código correcto y claro primero, medir (perfilado, métricas, tiempos de petición) para identificar los verdaderos cuellos de botella cuando surgen, optimizar focalizado donde cuenta, y luego remediar para confirmar. Optimizar a ciegas hace perder tiempo, complica el código y falla casi siempre el verdadero problema — la intuición engaña, la medición decide. Salim perfila antes de tocar el código : el cuello de botella estaba en la base, no en sus bucles.
Node destaca en I/O (servidores, API, tiempo real) — el límite monohilo afecta a la CPU, no a la I/O, y la mayoría de las aplicaciones web están limitadas por la I/O. Bien usado, Node sirve cargas muy grandes.
🔎 Ejemplo concreto — Salim aprovecha los núcleos
Clustering con PM2, caché después.
# lanzar una instancia por núcleo
pm2 start app.js -i max
# medir ANTES de optimizar (perfilado)
# poner en caché un resultado costoso (Redis)
# verificar : nada bloque el bucle de eventosLectura : cada línea es una etapa comprobable por separado.
Lección : la base de datos es a menudo el verdadero cuello de botella — medirla primero.
Vocabulario de la sección
- Clustering
- Varias instancias de la app (una por núcleo) que se reparten las peticiones.
Ejemplo sencillo: Salim lanza su API con PM2 en modo clúster.
Lo que no es: un Node que usaría todos los núcleos automáticamente.
Reflejo: ¿cuántos núcleos duermen en mi servidor?
- Worker threads
- Hilos separados para los cálculos pesados, sin bloquear el bucle.
Ejemplo sencillo: Salim delega ahí una exportación voluminosa que congelaba la API.
Lo que no es: el propio clustering.
Reflejo: ¿este cálculo bloquea el hilo principal?
- Puesta en caché
- Guardar los resultados costosos para no recalcularlos.
Ejemplo sencillo: El catálogo de Salim servido desde la caché, ya no desde la base.
Lo que no es: añadir servidores antes de cachear.
Reflejo: ¿qué peticiones vuelven sin cesar idénticas?
- Perfilado
- Medir para identificar los verdaderos cuellos de botella antes de optimizar.
Ejemplo sencillo: Salim descubre que la lentitud viene de una consulta sin índice.
Lo que no es: optimizar sus bucles por intuición.
Reflejo: ¿medí antes de tocar el código?
- Escalado horizontal
- Varios servidores tras un repartidor de carga.
Ejemplo sencillo: Salim prevé instancias replicables gracias a su app stateless.
Lo que no es: aprovechar los núcleos de una sola máquina.
Reflejo: ¿mi app se replica fácilmente (stateless)?
En la práctica — Optimizar y escalar una aplicación
- Use el clustering (módulo cluster o PM2) para lanzar una instancia por núcleo y aprovechar todo el procesador (Node es monohilo).
- Ponga en caché un resultado costoso (consulta frecuente) — en memoria o con Redis — y mida la ganancia.
- Perfile para identificar los verdaderos cuellos de botella ANTES de optimizar (medir antes de optimizar) ; verifique que nada bloquea el bucle de eventos.
- Comprenda el escalado horizontal : varias instancias tras un balanceador de carga, y el interés de una aplicación « stateless » (JWT) para replicarse fácilmente.
Guion listo para decir — justificar una optimización
« En Argel, nuestra API se ralentiza en horas punta. Medí : son las peticiones de catálogo las que saturan la base. Propongo dos gestos focalizados : clustering para aprovechar todos los núcleos, y caché en el catálogo. Remedimos después, y solo añadimos servidores si la medición lo justifica. »
Para decir al responsable para hacer validar una optimización medida en vez de una reescritura a ciegas.
Modelo copiar-pegar — ficha diagnóstico perf
PERF — DIAGNÓSTICO
SÍNTOMA : _______________ (¿cuándo? ___)
MEDICIÓN : tiempo de respuesta ___ · petición más lenta ___
CUELLO SOSPECHOSO : base / sin caché / bucle bloqueado / CPU : ___
ACCIÓN FOCALIZADA : clustering / caché / índice / worker : ___
REMEDICIÓN : antes ___ → después ___ · GANANCIA : ___Solo / presupuesto pequeño
Salim solo : PM2 en modo clúster + caché en memoria basta para absorber los picos sin nuevo servidor.
Pyme / equipo reducido
Indexar primero las consultas lentas : a menudo la ganancia más rápida, sin infraestructura.
Pyme en Argel
Salim planifica las mediciones en horas punta en Argel, con un protocolo de remedición tras cada cambio.
Equipo que empieza
Pareja : uno perfila mientras el otro prepara la caché ; revisión común de las mediciones antes de toda optimización.
✓ Buenas prácticas
- Aprovechar todos los núcleos con el clustering (PM2 en producción).
- Poner en caché los resultados costosos ; optimizar las consultas de base (índice, N+1).
- Medir (perfilar) antes de optimizar, y focalizar los verdaderos cuellos de botella.
✗ Errores frecuentes
- Dejar que un solo proceso solo aproveche un núcleo.
- Optimizar prematuramente (pérdida de tiempo, complejidad inútil).
- Bloquear el bucle de eventos con un cálculo CPU pesado en el hilo principal.
Puntos clave
- Node es MONOHILO : el CLUSTERING (cluster / PM2) lanza una instancia por núcleo para aprovechar TODOS los núcleos. WORKER THREADS para la CPU pesada.
- Palancas : PUESTA EN CACHÉ (Redis — a menudo lo más impactante), optimización de CONSULTAS (indexación, evitar el N+1), no BLOQUEAR el bucle, paralelismo (Promise.all).
- MEDIR (perfilar) antes de optimizar (regla de oro) ; identificar los verdaderos cuellos de botella en vez de optimizar a ciegas.
- ESCALADO HORIZONTAL : varios servidores tras un BALANCEADOR DE CARGA (favorece las apps stateless/JWT). NO optimizar prematuramente.
Reto 48h — aplica mañana
Rellene la ficha diagnóstico para 1 lentitud real de su app : síntoma, medición, cuello sospechoso — sin tocar aún el código.
- Puedo explicar clustering frente a worker threads en una frase.
- Mi ficha diagnóstico (medición antes de optimización) está rellena.
- Sé por qué la base es el primer sospechoso.
Preguntas frecuentes
¿Por qué es necesario el clustering, y es Node una mala opción para el rendimiento?
El clustering es necesario porque Node ejecuta su código en un solo hilo (un núcleo), mientras los servidores modernos tienen varios : un solo proceso desperdicia los demás núcleos. El clustering (módulo cluster, o PM2 que lo automatiza con reinicio auto y monitorización) lanza varios procesos que se reparten las peticiones. Pero eso no hace de Node una mala opción : Node destaca en I/O (servidores, API, tiempo real — la mayoría de las apps web) con su modelo no bloqueante, el límite monohilo afecta a la CPU (gestionable vía worker threads), y Node escala bien (vertical + horizontal). Bien usado, Node sirve cargas muy grandes.
¿Cómo saber CUÁNDO y QUÉ optimizar sin caer en la optimización prematura?
Regla de oro : no optimice antes de un problema real y medido. La optimización prematura hace perder tiempo, complica el código y falla el verdadero cuello de botella (la intuición engaña). El método : código correcto y claro primero, medir (perfilado, métricas) cuando surge un problema, optimizar focalizado donde cuenta, remedir para confirmar. Palancas comunes : base de datos (índice, N+1), caché (Redis), clustering, bucle no bloqueado, paralelismo, escalado horizontal.
¿Cómo aprovecha una aplicación Node todos los núcleos de un servidor?