Mejores prácticas del bucle de eventos
Reglas para mantener el bucle de eventos de Node.js receptivo bajo carga: descarga la CPU, procesa E/S por lotes y mide el retraso antes de que los usuarios lo perciban.
Busca en todas las páginas de la documentación
Reglas para mantener el bucle de eventos de Node.js receptivo bajo carga: descarga la CPU, procesa E/S por lotes y mide el retraso antes de que los usuarios lo perciban.
worker_threads o a una cola.*Sync (readFileSync, bcrypt.hashSync) en los manejadores HTTP. Usa variantes asíncronas de promesa o callback.JSON.parse en el borde y la aplicación. Los cuerpos grandes bloquean el análisis de forma síncrona.Promise.all para E/S independientes, no await secuencial en bucles. Añade límites de concurrencia para lotes grandes.queueMicrotask o setImmediate sobre setTimeout(fn, 0) para el aplazamiento. Haz coincidir el tipo de aplazamiento con las necesidades de ordenación.process.nextTick para procesar trabajo por lotes. Agota las E/S y los temporizadores.try/catch el código await en los manejadores de solicitudes. Las promesas rechazadas sin manejar detienen el proceso.for await en los streams en lugar de cargar cargas útiles completas en la memoria. Los streams cooperan con la contrapresión.setTimeout/setInterval como aproximados, no como relojes en tiempo real. Usa planificadores externos para cron de reloj de pared.setInterval se superpongan. Encadena setTimeout después de que el trabajo se complete.SIGTERM). O llama a .unref() solo cuando sea intencionalmente "disparar y olvidar".monitorEventLoopDelay. Alerta antes de que el p99 visible para el usuario se duplique.eventLoopUtilization junto con la CPU. Un ELU alto con una CPU moderada indica bloques síncronos.blocked-at en staging para atribuir bloques a trazas de pila. No siempre activo en producción.Ningún JavaScript síncrono largo en el hilo principal durante el manejo de solicitudes. Todo lo demás se deriva de eso.
No. async solo cede en los puntos await. El código síncrono entre awaits sigue bloqueando.
Depende del hardware; perfila. Regla general: limita los cuerpos a 1-10 MB para las API típicas; haz streaming más allá de eso.
cluster duplica los listeners HTTP en los núcleos. worker_threads comparte un servidor con pools de CPU. A menudo se usan ambos patrones en diferentes capas.
No, los guards, pipes e interceptors siguen ejecutándose en el hilo principal a menos que los descargues explícitamente.
Solo si descargan al pool de hilos de libuv o devuelven asíncronamente. Las llamadas nativas síncronas bloquean como los bucles de JavaScript.
zlib.gzipSync bloquea; usa promisify(gzip) o zlib/promises en las rutas de solicitud.
Mejorados, pero el manejo explícito de errores y la higiene del bucle siguen siendo tu responsabilidad.
Busca Sync, bucles ajustados, JSON.parse(req.body) y nuevo middleware sin benchmarks.
La compilación del esquema JSON suele ser al inicio; la validación por solicitud es síncrona pero rápida; aún así, perfila las cargas útiles grandes.
Aplazar el trabajo hasta después de la fase actual de sondeo de E/S: agrupar múltiples lecturas de socket antes de la agregación.
Detección de bloqueo del bucle de eventos para métricas y worker_threads para soluciones.
Versiones de la pila: Esta página fue escrita para Node.js 24.18.0 (LTS activa), npm 10+, TypeScript 5.6+, Express 5, Fastify 5 y NestJS 11.
Revisado por Chris St. John·Última actualización: 16 jul 2026