Esta traducci贸n proporcionada por StrongLoop / IBM.

Este documento puede estar desfasado respecto a la documentaci贸n en ingl茅s. Para ver las 煤ltimas actualizaciones, consulte la documentaci贸n en ingl茅s.

Mejores pr谩cticas de producci贸n: rendimiento y fiabilidad

Visi贸n general

En este art铆culo se describen las mejores pr谩cticas de rendimiento y fiabilidad para las aplicaciones Express desplegadas en producci贸n.

Este tema entra claramente dentro del 谩rea de 鈥淒evOps鈥, que abarca operaciones y desarrollos tradicionales. Por lo tanto, la informaci贸n se divide en dos partes:

Cosas que hacer en el c贸digo

Estas son algunas de las cosas que puede hacer en el c贸digo para mejorar el rendimiento de la aplicaci贸n:

Utilizar la compresi贸n de gzip

La compresi贸n de gzip puede disminuir significativamente el tama帽o del cuerpo de respuesta y, por lo tanto, aumentar la velocidad de una aplicaci贸n web. Utilice el middleware de compresi贸n para la compresi贸n de gzip en la aplicaci贸n Express. Por ejemplo:


var compression = require('compression');
var express = require('express');
var app = express();
app.use(compression());

Para un sitio web con un tr谩fico elevado en producci贸n, la mejor forma de aplicar la compresi贸n es implementarla como un nivel de proxy inverso (consulte Utilizar un proxy inverso). En este caso, no es necesario utilizar el middleware de compresi贸n. Para obtener detalles sobre c贸mo habilitar la compresi贸n de gzip en Nginx, consulte Module ngx_http_gzip_module en la documentaci贸n de Nginx.

No utilizar funciones s铆ncronas

Las funciones s铆ncronas y los m茅todos impiden el avance del proceso de ejecuci贸n hasta que vuelven. Una llamada individual a una funci贸n s铆ncrona puede volver en pocos microsegundos o milisegundos, aunque en sitios web de tr谩fico elevado, estas llamadas se suman y reducen el rendimiento de la aplicaci贸n. Evite su uso en producci贸n.

Aunque Node y muchos m贸dulos proporcionan versiones s铆ncronas y as铆ncronas de las funciones, utilice siempre la versi贸n as铆ncrona en producci贸n. La 煤nica vez que est谩 justificado utilizar una funci贸n s铆ncrona es en el arranque inicial.

Si utiliza Node.js 4.0+ o io.js 2.1.0+, puede utilizar el distintivo de l铆nea de mandatos --trace-sync-io para imprimir un aviso y un seguimiento de la pila siempre que la aplicaci贸n utilice una API s铆ncrona. Desde luego, no desear谩 utilizarlo en producci贸n, s贸lo para garantizar que el c贸digo est谩 listo para producci贸n. Consulte Weekly update for io.js 2.1.0 para obtener m谩s informaci贸n.

Utilizar el middleware para el servicio de archivos est谩ticos

En el desarrollo, puede utilizar res.sendFile() para el servicio de archivos est谩ticos. Sin embargo, no lo haga en producci贸n, porque esta funci贸n debe leer el sistema de archivos para cada solicitud de archivo, por lo que encontrar谩 una latencia significativa y afectar谩 al rendimiento general de la aplicaci贸n. Tenga en cuenta que res.sendFile() no se implementa con la llamada al sistema sendfile, lo que har铆a que fuera mucho m谩s eficaz.

En su lugar, utilice el middleware serve-static (o algo equivalente), que est谩 optimizado para el servicio de archivos para aplicaciones Express.

Una soluci贸n a煤n mejor es utilizar un proxy inverso para el servicio de archivos est谩ticos; consulte Utilizar un proxy inverso para obtener m谩s informaci贸n.

Realizar un registro correcto

En general, hay dos motivos para realizar un registro desde la aplicaci贸n: a efectos de depuraci贸n o para registrar la actividad de la aplicaci贸n (b谩sicamente, todo lo dem谩s). El uso de console.log() o console.err() para imprimir mensajes de registro en el terminal es una pr谩ctica com煤n en el desarrollo. No obstante, estas funciones son s铆ncronas cuando el destino es un terminal o un archivo, por lo que no son adecuadas para producci贸n, a menos que canalice la salida a otro programa.

A efectos de depuraci贸n

Si realiza el registro a efectos de depuraci贸n, en lugar de utilizar console.log(), utilice un m贸dulo de depuraci贸n especial como debug. Este m贸dulo permite utilizar la variable de entorno DEBUG para controlar qu茅 mensajes de depuraci贸n se env铆an a console.err(), si se env铆a alguno. Para mantener la aplicaci贸n b谩sicamente as铆ncrona, deber谩 canalizar console.err() a otro programa. Pero en este caso, realmente no va a depurar en producci贸n, 驴no?

Para la actividad de la aplicaci贸n

Si est谩 registrando la actividad de la aplicaci贸n (por ejemplo, realizando un seguimiento del tr谩fico o las llamadas de API), en lugar de utilizar console.log(), utilice una biblioteca de registro como Winston o Bunyan. Para ver una comparaci贸n detallada de estas dos bibliotecas, consulte el post del blog StrongLoop Comparing Winston and Bunyan Node.js Logging.

Manejar las excepciones correctamente

Las aplicaciones Node se bloquean cuando encuentran una excepci贸n no capturada. Si no maneja las excepciones ni realiza las acciones necesarias, la aplicaci贸n Express se bloquear谩 y quedar谩 fuera de l铆nea. Si sigue el consejo de Asegurarse de que la aplicaci贸n se reinicia autom谩ticamente m谩s abajo, la aplicaci贸n se recuperar谩 de un bloqueo. Afortunadamente, las aplicaciones Express normalmente necesitan un breve tiempo de arranque. No obstante, desea evitar el bloqueo en primer lugar y, para ello, deber谩 manejar correctamente las excepciones.

Para asegurarse de manejar todas las excepciones, siga estas t茅cnicas:

Antes de profundizar en estos temas, deber谩 tener unos conocimientos b谩sicos del manejo de errores de Node/Express: el uso de devoluciones de llamada error-first y la propagaci贸n de errores en el middleware. Node utiliza un convenio de 鈥渄evoluci贸n de llamada error-first鈥 para devolver los errores de las funciones as铆ncronas, donde el primer par谩metro en la funci贸n de devoluci贸n de llamada es el objeto de error, seguido de los datos de resultados en los par谩metros posteriores. Para indicar que no hay ning煤n error, pase null como el primer par谩metro. La funci贸n de devoluci贸n de llamada debe seguir por lo tanto el convenio de devoluci贸n de llamada error-first para manejar correctamente el error. En Express, la pr谩ctica recomendada es utilizar la funci贸n next() para propagar los errores a trav茅s de la cadena de middleware.

Para obtener m谩s informaci贸n sobre los aspectos b谩sicos del manejo de errores, consulte:

Qu茅 no debe hacer

Algo que no debe hacer es escuchar el suceso uncaughtException, que se emite cuando una excepci贸n se reproduce hacia atr谩s en el bucle de sucesos. La adici贸n de un escucha de sucesos para uncaughtException cambiar谩 el comportamiento predeterminado del proceso que se encuentra con la excepci贸n; el proceso continuar谩 ejecut谩ndose a pesar de la excepci贸n. Esto puede parecer una buena forma de evitar el bloqueo de la aplicaci贸n, pero continuar ejecutando la aplicaci贸n despu茅s de una excepci贸n no capturada es una pr谩ctica peligrosa y no se recomienda, ya que el estado del proceso se vuelve imprevisible y poco fiable.

Asimismo, el uso de uncaughtException se reconoce oficialmente como un mecanismo arduo y hay una propuesta para eliminarlo del n煤cleo. Por lo tanto, la escucha uncaughtException no es una buena idea. Es por esto por lo que se recomiendan varios procesos y supervisores; el bloqueo y el reinicio es a menudo la forma m谩s fiable de recuperarse de un error.

Tampoco se recomienda el uso de dominios. Generalmente no soluciona el problema y es un m贸dulo en desuso.

Utilizar try-catch

Try-catch es una construcci贸n de lenguaje JavaScript que puede utilizar para capturar excepciones en c贸digo s铆ncrono. Por ejemplo, utilice try-catch para manejar los errores de an谩lisis de JSON, como se muestra a continuaci贸n.

Utilice una herramienta como JSHint o JSLint para buscar excepciones impl铆citas como errores de referencia o variables sin definir.

A continuaci贸n, se muestra un ejemplo de uso de try-catch para manejar una posible excepci贸n de bloqueo de proceso. Esta funci贸n de middleware acepta un par谩metro de campo de consulta denominado 鈥減arams鈥 que es un objeto JSON.


app.get('/search', function (req, res) {
  // Simulating async operation
  setImmediate(function () {
    var jsonStr = req.query.params;
    try {
      var jsonObj = JSON.parse(jsonStr);
      res.send('Success');
    } catch (e) {
      res.status(400).send('Invalid JSON string');
    }
  });
});

No obstante, try-catch s贸lo funciona para el c贸digo s铆ncrono. Como la plataforma de Node es principalmente as铆ncrona (particularmente en un entorno de producci贸n), try-catch no capturar谩 muchas excepciones.

Utilizar promesas

Las promesas manejar谩n todas las excepciones (expl铆citas e impl铆citas) en los bloques de c贸digos as铆ncronos que utilicen then(). S贸lo tiene que a帽adir .catch(next) al final de las cadenas de promesas. Por ejemplo:


app.get('/', function (req, res, next) {
  // do some sync stuff
  queryDb()
    .then(function (data) {
      // handle data
      return makeCsv(data)
    })
    .then(function (csv) {
      // handle csv
    })
    .catch(next);
});

app.use(function (err, req, res, next) {
  // handle error
});

Ahora todos los errores, as铆ncronos y s铆ncronos, se propagar谩n al middleware de errores.

No obstante, hay dos advertencias:

  1. Todo el c贸digo as铆ncrono debe devolver promesas (excepto los emisores). Si una determinada biblioteca no devuelve promesas, convierta el objeto base utilizando una funci贸n de ayuda como Bluebird.promisifyAll().
  2. Los emisores de sucesos (como las secuencias) todav铆a pueden provocar excepciones no capturadas. Por lo tanto, aseg煤rese de que est谩 manejando el suceso de error correctamente; por ejemplo:

app.get('/', wrap(async (req, res, next) => {
  let company = await getCompanyById(req.query.id)
  let stream = getLogoStreamById(company.id)
  stream.on('error', next).pipe(res)
}))

Para obtener m谩s informaci贸n sobre el manejo de errores utilizando promesas, consulte:

Cosas que hacer en el entorno / configuraci贸n

Estas son algunas de las cosas que puede hacer en el entorno del sistema para mejorar el rendimiento de la aplicaci贸n:

Establecer NODE_ENV en 鈥減roduction鈥

La variable de entorno NODE_ENV especifica el entorno en el que se ejecuta una aplicaci贸n (normalmente, desarrollo o producci贸n). Una de las cosas m谩s sencillas que puede hacer para mejorar el rendimiento es establecer NODE_ENV en 鈥減roduction鈥.

Si establece NODE_ENV en 鈥減roduction鈥, Express:

Las pruebas indican que s贸lo esta acci贸n puede mejorar hasta tres veces el rendimiento de la aplicaci贸n.

Si necesita escribir c贸digo espec铆fico del entorno, puede comprobar el valor de NODE_ENV con process.env.NODE_ENV. Tenga en cuenta que comprobar el valor de una variable de entorno supone una reducci贸n de rendimiento, por lo que debe hacerse moderadamente.

En el desarrollo, normalmente establece las variables de entorno en el shell interactivo, por ejemplo, utilizando export o su archivo .bash_profile. Sin embargo, en general, no debe hacerlo en un servidor de producci贸n; en su lugar, utilice el sistema init de su sistema operativo (systemd o Upstart). En la siguiente secci贸n se proporcionan m谩s detalles sobre el uso del sistema init en general, pero el establecimiento de NODE_ENV es tan importante (y f谩cil de hacer) para el rendimiento, que se resalta aqu铆.

Con Upstart, utilice la palabra clave env en el archivo de trabajo. Por ejemplo:


# /etc/init/env.conf
 env NODE_ENV=production

Para obtener m谩s informaci贸n, consulte Upstart Intro, Cookbook and Best Practices.

Con systemd, utilice la directiva Environment en el archivo unit. Por ejemplo:


# /etc/systemd/system/myservice.service
Environment=NODE_ENV=production

Para obtener m谩s informaci贸n, consulte Using Environment Variables In systemd Units.

Si est谩 utilizando StrongLoop Process Manager, tambi茅n puede establecer la variable de entorno cuando instala StrongLoop PM como un servicio.

Asegurarse de que la aplicaci贸n se reinicia autom谩ticamente

En la producci贸n, no desea que la aplicaci贸n est茅 nunca fuera de l铆nea. Esto significa que debe asegurarse de que se reinicia si la aplicaci贸n o el servidor se bloquean. Aunque espera que no se produzca ninguno de estos sucesos, si somos realistas, debe tener en cuenta ambas eventualidades de la siguiente manera:

Las aplicaciones Node se bloquean si encuentran una excepci贸n no capturada. Lo primero que debe hacer es asegurarse de que se realizan las pruebas correctas en la aplicaci贸n y que se manejan todas las excepciones (consulte Manejar correctamente las excepciones para obtener detalles). No obstante, para estar libre de errores, aplique un mecanismo para garantizar que cuando se bloquee la aplicaci贸n, se reinicie autom谩ticamente.

Utilizar un gestor de procesos

En el desarrollo, la aplicaci贸n se inicia simplemente desde la l铆nea de mandatos con node server.js o algo similar. Pero hacer esto en la producci贸n es sin贸nimo de desastre. Si la aplicaci贸n se bloquea, estar谩 fuera de l铆nea hasta que la reinicie. Para garantizar el reinicio de la aplicaci贸n si se bloquea, utilice un gestor de procesos. Un gestor de procesos es un 鈥渃ontenedor鈥 de aplicaciones que facilita el despliegue, proporciona una alta disponibilidad y permite gestionar la aplicaci贸n en el tiempo de ejecuci贸n.

Adem谩s de reiniciar la aplicaci贸n cuando se bloquea, un gestor de procesos permite:

Los gestores de procesos m谩s conocidos para Node son los siguientes:

Para ver una comparaci贸n caracter铆stica a caracter铆stica de los tres gestores de procesos, consulte http://strong-pm.io/compare/. Para ver una introducci贸n m谩s detallada de los tres, consulte Gestores de procesos para las aplicaciones Express.

El uso de cualquiera de estos gestores de procesos bastar谩 para mantener activa la aplicaci贸n, aunque se bloquee cada cierto tiempo.

No obstante, StrongLoop PM tiene muchas caracter铆sticas especialmente indicadas para el despliegue de producci贸n. Puede utilizarlo y las herramientas relacionadas de StrongLoop para:

Como se explica a continuaci贸n, cuando instala StrongLoop PM como un servicio de sistema operativo utilizando el sistema init, se reinicia autom谩ticamente cuando se reinicia el sistema. De esta forma, mantiene activos siempre los cl煤steres y los procesos de aplicaciones.

Utilizar un sistema init

La siguiente capa de fiabilidad es garantizar que la aplicaci贸n se reinicie cuando se reinicie el servidor. Los sistemas pueden bloquearse por una amplia variedad de motivos. Para garantizar que la aplicaci贸n se reinicie si se bloquea el servidor, utilice el sistema init incorporado en su sistema operativo. Los dos principales sistemas init que se utilizan hoy d铆a son systemd y Upstart.

Hay dos formas de utilizar los sistemas init con la aplicaci贸n Express:

Systemd

Systemd es un administrador de servicios y sistemas Linux. La mayor铆a de las principales distribuciones Linux han adoptado systemd como su sistema init predeterminado.

Un archivo de configuraci贸n de servicio de systemd se denomina un archivo unit, con un nombre de archivo terminado en .service. A continuaci贸n, se muestra un archivo unit de ejemplo para gestionar directamente una aplicaci贸n Node (sustituya el texto en negrita por los valores de su sistema y su aplicaci贸n):


[Unit]
Description=Awesome Express App

[Service]
Type=simple
ExecStart=/usr/local/bin/node /projects/myapp/index.js
WorkingDirectory=/projects/myapp

User=nobody
Group=nogroup

# Environment variables:
Environment=NODE_ENV=production

# Allow many incoming connections
LimitNOFILE=infinity

# Allow core dumps for debugging
LimitCORE=infinity

StandardInput=null
StandardOutput=syslog
StandardError=syslog
Restart=always

[Install]
WantedBy=multi-user.target

Para obtener m谩s informaci贸n sobre systemd, consulte systemd reference (man page).

StrongLoop PM como un servicio systemd

Puede instalar f谩cilmente StrongLoop Process Manager como un servicio systemd. A continuaci贸n, cuando se reinicie el servidor, se reiniciar谩 autom谩ticamente StrongLoop PM, que a su vez reiniciar谩 todas las aplicaciones que est茅 gestionando.

Para instalar StrongLoop PM como un servicio systemd:


$ sudo sl-pm-install --systemd

A continuaci贸n, inicie el servicio con:


$ sudo /usr/bin/systemctl start strong-pm

Para obtener m谩s informaci贸n, consulte Setting up a production host (documentaci贸n de StrongLoop).

Upstart

Upstart es una herramienta del sistema disponible en muchas distribuciones Linux para iniciar tareas y servicios durante el arranque del sistema, detenerlos durante la conclusi贸n y supervisarlos. Puede configurar la aplicaci贸n Express o el gestor de procesos como un servicio y, a continuaci贸n, Upstart lo reiniciar谩 autom谩ticamente cuando se bloquee.

Un servicio de Upstart se define en un archivo de configuraci贸n de trabajo (tambi茅n denominado un 鈥渢rabajo鈥) con un nombre de archivo terminado en .conf. El siguiente ejemplo muestra c贸mo crear un trabajo denominado 鈥渕yapp鈥 para una aplicaci贸n denominada 鈥渕yapp鈥 con el archivo principal ubicado en /projects/myapp/index.js.

Cree un archivo denominado myapp.conf en /etc/init/ con el siguiente contenido (sustituya el texto en negrita por los valores de su sistema y su aplicaci贸n):


# When to start the process
start on runlevel [2345]

# When to stop the process
stop on runlevel [016]

# Increase file descriptor limit to be able to handle more requests
limit nofile 50000 50000

# Use production mode
env NODE_ENV=production

# Run as www-data
setuid www-data
setgid www-data

# Run from inside the app dir
chdir /projects/myapp

# The process to start
exec /usr/local/bin/node /projects/myapp/index.js

# Restart the process if it is down
respawn

# Limit restart attempt to 10 times within 10 seconds
respawn limit 10 10

NOTA: este script requiere Upstart 1.4 o posterior, soportado en Ubuntu 12.04-14.10.

Como el trabajo se configura para ejecutarse cuando se inicia el sistema, la aplicaci贸n se iniciar谩 junto con el sistema operativo, y se reiniciar谩 autom谩ticamente si la aplicaci贸n se bloquea o el sistema se cuelga.

Aparte reiniciar autom谩ticamente la aplicaci贸n, Upstart permite utilizar estos mandatos:

Para obtener m谩s informaci贸n sobre Upstart, consulte Upstart Intro, Cookbook and Best Practises.

StrongLoop PM como un servicio Upstart

Puede instalar f谩cilmente StrongLoop Process Manager como un servicio Upstart. A continuaci贸n, cuando se reinicie el servidor, se reiniciar谩 autom谩ticamente StrongLoop PM, que a su vez reiniciar谩 todas las aplicaciones que est茅 gestionando.

Para instalar StrongLoop PM como un servicio Upstart 1.4:


$ sudo sl-pm-install

A continuaci贸n, ejecute el servicio con:


$ sudo /sbin/initctl start strong-pm

NOTA: en los sistemas que no dan soporte a Upstart 1.4, los mandatos son ligeramente diferentes. Consulte Setting up a production host (documentaci贸n de StrongLoop) para obtener m谩s informaci贸n.

Ejecutar la aplicaci贸n en un cl煤ster

En un sistema multin煤cleo, puede multiplicar el rendimiento de una aplicaci贸n Node iniciando un cl煤ster de procesos. Un cl煤ster ejecuta varias instancias de la aplicaci贸n, idealmente una instancia en cada n煤cleo de CPU, lo que permite distribuir la carga y las tareas entre las instancias.

IMPORTANTE: como las instancias de aplicaci贸n se ejecutan como procesos independientes, no comparten el mismo espacio de memoria. Es decir, los objetos son locales para cada instancia de la aplicaci贸n. Por lo tanto, no puede mantener el estado en el c贸digo de aplicaci贸n. No obstante, puede utilizar un almac茅n de datos en memoria como Redis para almacenar los datos y los estados relacionados con la sesi贸n. Esta advertencia se aplica b谩sicamente a todas las formas de escalado horizontal, ya sean cl煤steres con varios procesos o varios servidores f铆sicos.

En las aplicaciones en cl煤ster, los procesos de trabajador pueden bloquearse individualmente sin afectar al resto de los procesos. Aparte de las ventajas de rendimiento, el aislamiento de errores es otro motivo para ejecutar un cl煤ster de procesos de aplicaci贸n. Siempre que se bloquee un proceso de trabajador, aseg煤rese de registrar el suceso y generar un nuevo proceso utilizando cluster.fork().

Mediante el m贸dulo de cl煤ster de Node

La agrupaci贸n en cl煤steres es posible gracias al m贸dulo de cl煤ster de Node. Esto permite al proceso maestro generar procesos de trabajador y distribuir las conexiones entrantes entre los trabajadores. No obstante, en lugar de utilizar este m贸dulo directamente, es mucho mejor utilizar una de las muchas herramientas que lo hacen autom谩ticamente, por ejemplo, node-pm o cluster-service.

Mediante StrongLoop PM

Si despliega la aplicaci贸n en StrongLoop Process Manager (PM), puede aprovechar la agrupaci贸n en cl煤ster sin modificar el c贸digo de aplicaci贸n.

Cuando StrongLoop Process Manager (PM) ejecuta una aplicaci贸n, la ejecuta autom谩ticamente en un cl煤ster con un n煤mero de trabajadores igual al n煤mero de n煤cleos de CPU en el sistema. Puede cambiar manualmente el n煤mero de procesos de trabajador en el cl煤ster utilizando la herramienta de l铆nea de mandatos slc sin detener la aplicaci贸n.

Por ejemplo, suponiendo que ha desplegado la aplicaci贸n en prod.foo.com y que StrongLoop PM escucha en el puerto 8701 (el valor predeterminado), para establecer el tama帽o de cl煤ster en ocho utilizando slc:


$ slc ctl -C http://prod.foo.com:8701 set-size my-app 8

Para obtener m谩s informaci贸n sobre la agrupaci贸n en cl煤ster con StrongLoop PM, consulte Clustering en la documentaci贸n de StrongLoop.

Almacenar en la cach茅 los resultados de la solicitud

Otra estrategia para mejorar el rendimiento en la producci贸n es almacenar en la cach茅 el resultado de las solicitudes, para que la aplicaci贸n no repita la operaci贸n de dar servicio a la misma solicitud repetidamente.

Utilice un servidor de almacenamiento en memoria cach茅 como Varnish o Nginx (consulte tambi茅n Nginx Caching) para mejorar significativamente la velocidad y el rendimiento de la aplicaci贸n.

Utilizar un equilibrador de carga

Independientemente de lo optimizada que est茅 una aplicaci贸n, una 煤nica instancia s贸lo puede manejar una cantidad limitada de carga y tr谩fico. Una forma de escalar una aplicaci贸n es ejecutar varias instancias de la misma y distribuir el tr谩fico utilizando un equilibrador de carga. La configuraci贸n de un equilibrador de carga puede mejorar el rendimiento y la velocidad de la aplicaci贸n, lo que permite escalarla m谩s que con una 煤nica instancia.

Un equilibrador de carga normalmente es un proxy inverso que orquesta el tr谩fico hacia y desde los servidores y las instancias de aplicaci贸n. Puede configurar f谩cilmente un equilibrador de carga para la aplicaci贸n utilizando Nginx o HAProxy.

Con el equilibrio de carga, deber谩 asegurarse de que las solicitudes asociadas con un determinado ID de sesi贸n se conecten al proceso que las ha originado. Esto se conoce como afinidad de sesiones o sesiones adhesivas, y puede solucionarse con la recomendaci贸n anterior de utilizar un almac茅n de datos como, por ejemplo, Redis para los datos de sesi贸n (dependiendo de la aplicaci贸n). Para obtener m谩s informaci贸n, consulte Using multiple nodes.

Mediante StrongLoop PM con un equilibrador de carga Nginx

StrongLoop Process Manager se integra con un Nginx Controller, lo que simplifica las configuraciones de entornos de producci贸n de varios hosts. Para obtener m谩s informaci贸n, consulte Scaling to multiple servers (documentaci贸n de StrongLoop).

Utilizar un proxy inverso

Un proxy inverso se coloca delante de una aplicaci贸n web y realiza operaciones de soporte en las solicitudes, aparte de dirigir las solicitudes a la aplicaci贸n. Puede manejar las p谩ginas de errores, la compresi贸n, el almacenamiento en memoria cach茅, el servicio de archivos y el equilibrio de carga, entre otros.

La entrega de tareas que no necesitan saber el estado de la aplicaci贸n a un proxy inverso permite a Express realizar tareas de aplicaci贸n especializadas. Por este motivo, se recomienda ejecutar Express detr谩s de un proxy inverso como Nginx o HAProxy en la producci贸n.