49 votos

JS en sí mismo o nginx frontend para servir archivos estáticos?

¿Hay algún punto de referencia o comparación que sea más rápido: colocar nginx delante del nodo y dejar que sirva archivos estáticos directamente o usar sólo el nodo y servir archivos estáticos usándolo?

La solución de nginx parece ser más manejable para mí, ¿alguna idea?

69voto

m33lky Puntos 1608

Tendré que estar en desacuerdo con las respuestas aquí. Mientras que Node lo hará bien, nginx será definitivamente más rápido cuando esté configurado correctamente. nginx se implementa eficientemente en C siguiendo un patrón similar (volviendo a una conexión sólo cuando sea necesario) con una pequeña huella de memoria. Además, soporta el sendfile para servir esos archivos, que es lo más rápido que se puede conseguir al servir archivos, ya que es el propio núcleo del sistema operativo el que hace el trabajo.

Por ahora nginx se ha convertido en el estándar de facto como servidor de frontend. Puedes usarlo por su rendimiento en servir archivos estáticos, gzip, SSL, e incluso balanceo de carga más adelante.

P.D.: Esto supone que los archivos son realmente "estáticos" como en reposo en el disco en el momento de la solicitud.

42voto

gremo Puntos 7116

Hice un rápido ab -n 10000 -c 100 para servir a un byte estático de 1406 favicon.ico comparando nginx, Express.JS (middleware estático) y el Express.JS agrupado. Espero que esto ayude:

enter image description here

Desafortunadamente no puedo probar 1000 o incluso 10000 peticiones simultáneas ya que nginx, en mi máquina, empezará a arrojar errores.

EDITAR como sugiere artvolk, aquí están los resultados del cluster + static middleware (más lento):

enter image description here

7voto

Will Stern Puntos 1727

De cualquier manera, configuraría a Nginx para que almacene los archivos estáticos ...verás una ENORME diferencia allí. Entonces, tanto si los sirves desde el expreso como si no, básicamente obtienes el mismo rendimiento y la misma carga en tu aplicación del expreso.

1voto

freakish Puntos 20067

Nodo. JS puede estar solo. Ya no necesitas usar nginx con Node.JS (ver esta entrada para los detalles). Por lo tanto, no tiene sentido usar nginx sólo para esta simple tarea. En cuanto al rendimiento, no lo sé realmente, pero no creo que haya ninguna diferencia notable.

Por cierto: ¿hay alguna diferencia notable (en el rendimiento) entre dos entornos cualquiera en la prestación de servicios de archivos estáticos? Leer archivos es un trabajo del sistema operativo y enviarlos al cliente depende (mayormente) de la conexión, ¿no es así?

0voto

Brad Harris Puntos 1274

Es una pregunta difícil de responder. Si escribieras un servidor de nodos realmente ligero para servir sólo archivos estáticos, lo más probable es que funcionara mejor que nginx, pero no es tan simple. ( Aquí hay un "punto de referencia" comparando un servidor de archivos nodejs y lighttpd - que es similar en rendimiento a ngingx cuando sirve archivos estáticos).

El rendimiento en lo que respecta a servir archivos estáticos a menudo se reduce a algo más que el servidor web que hace el trabajo. Si desea obtener el mayor rendimiento posible, utilizará una CDN para servir sus archivos con el fin de reducir la latencia para los usuarios finales y beneficiarse del almacenamiento en caché de bordes.

Si no te preocupa eso, el nodo puede servir archivos estáticos muy bien en la mayoría de las situaciones. Node se presta a código asíncrono, en el que también se basa ya que es de un solo hilo y cualquier bloqueo puede bloquear todo el proceso, y degradar el rendimiento de tus aplicaciones. Es más que probable que estés escribiendo tu código de forma no bloqueante, pero si estás haciendo algo de forma sincronizada, puedes causar el bloqueo, lo que degradaría la rapidez con la que otros clientes pueden conseguir que sus archivos estáticos sean servidos. La solución fácil es no escribir código de bloqueo, pero a veces eso no es una posibilidad, o no siempre se puede hacer cumplir.

Iteramos.com

Iteramos es una comunidad de desarrolladores que busca expandir el conocimiento de la programación mas allá del inglés.
Tenemos una gran cantidad de contenido, y también puedes hacer tus propias preguntas o resolver las de los demás.

Powered by:

X