Pregunta node.js en sí o frontend nginx para servir archivos estáticos?


¿Hay algún punto de referencia o comparación que sea más rápido: coloque nginx delante del nodo y permita que sirva archivos estáticos directamente o use solo el nodo y sirva archivos estáticos usando el mismo?

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


74
2018-04-01 20:09


origen


Respuestas:


Tendré que estar en desacuerdo con las respuestas aquí. Mientras que Node funcionará bien, nginx definitivamente será más rápido si se configura correctamente. nginx se implementa de manera eficiente en C siguiendo un patrón similar (volviendo a una conexión solo cuando es necesario) con una huella de memoria pequeña. Por otra parte, es compatible con el enviar archivo syscall para servir esos archivos lo más rápido posible en los archivos de servicio, ya que es el núcleo del sistema operativo el que hace el trabajo.

En este momento, nginx se ha convertido en el estándar de facto como servidor frontend. Puede usarlo para su rendimiento en el servicio de archivos estáticos, gzip, SSL, e incluso equilibrio de carga más adelante.

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


103
2018-04-02 18:42



Hice una rápida ab -n 10000 -c 100 para servir un byte 1406 estático favicon.ico, comparando nginx, Express.js (middleware estático) y clúster Express.js. Espero que esto ayude:

enter image description here

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

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

enter image description here


64
2018-05-19 14:10



De cualquier manera, configuraría Nginx para almacenar en caché los archivos estáticos... verás una ENORME diferencia allí. Entonces, tanto si los atiende desde un nodo como si no, básicamente obtiene el mismo rendimiento y el mismo alivio de carga en la aplicación de su nodo.

Personalmente, no me gusta la idea de que mi interfaz Nginx sirva para activos estáticos en la mayoría de los casos, en ese

1) El proyecto ahora debe estar en la misma máquina, o debe dividirse en activos (en la máquina nginx) y aplicación web (en varias máquinas para escalar)

2) La configuración de Nginx ahora tiene que mantener las ubicaciones de ruta para activos estáticos / recarga cuando cambian.


9
2017-07-30 15:11



Tengo una interpretación diferente de los gráficos de @ gremo. Me parece que tanto el nodo como la escala nginx tienen el mismo número de solicitudes (entre 9 y 10 k). Claro que la latencia en la respuesta para nginx es menor en una constante de 20 ms, pero no creo que los usuarios necesariamente perciban esa diferencia (si su aplicación está bien construida). Dado un número fijo de máquinas, tomaría una cantidad bastante importante de carga antes de convertir una máquina de nodos a nginx, considerando que ese nodo es donde la mayor parte de la carga ocurrirá en primer lugar. El único contrapunto a esto es si ya está dedicando una máquina a nginx para el equilibrio de carga. Si ese es el caso, es mejor que también sirva su contenido estático.


9
2018-03-21 19:12



Esa es una pregunta difícil de responder. Si escribiste un servidor de nodos realmente liviano para solo servir archivos estáticos, lo más probable es que funcione mejor que nginx, pero no es tan simple. (Aquí hay un "punto de referencia" comparar un servidor de archivos nodejs y lighttpd, que es similar en rendimiento a ngingx cuando se sirven archivos estáticos).

El rendimiento con respecto a la prestación de archivos estáticos a menudo se reduce a algo más que el servidor web que hace el trabajo. Si desea el máximo rendimiento posible, utilizará una CDN para servir sus archivos para reducir la latencia de los usuarios finales y beneficiarse de la memoria caché de borde.

Si no le preocupa, el nodo puede servir archivos estáticos bien en la mayoría de las situaciones. Node se presta a un código asíncrono, que también se basa en que es de subproceso único y cualquier bloqueo de E / S puede bloquear todo el proceso y degradar el rendimiento de las aplicaciones. Lo más probable es que esté escribiendo su código de forma no bloqueante, pero si está haciendo algo sincrónicamente, puede causar bloqueo, lo que degradaría la rapidez con que otros clientes pueden obtener sus archivos estáticos. 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 aplicar.


0
2018-04-01 22:14



Estoy seguro de que puramente node.js puede superar a nginx en muchos aspectos.

Todo dicho, tengo que quedarme. Nginx tiene una memoria caché incorporada, mientras que node.js no viene con la instalación de fábrica (USTED TIENE QUE CONSTRUIR SU PROPIO ARCHIVO DE ARCHIVOS). La caché de archivos personalizada supera a nginx y a cualquier otro servidor en el mercado, ya que es super simple.

También Nginx se ejecuta en múltiples núcleos. Para utilizar todo el potencial de Node, debe agrupar los servidores de nodos. Si está interesado en saber cómo, entonces por favor pm.

Necesitas excavador profundo para lograr el rendimiento nirvana con nodo, ese es el único problema. Una vez hecho el infierno, sí ... es mejor que Nginx.


-9
2017-11-24 13:02