Si NginX se ejecuta como un proxy inverso con Apache, ¿cómo NginX servirá los archivos estáticos más rápido si Apache está entregando todos los archivos PHP?

Si NGINX simplemente está enrutando a Apache, no acelerará la transferencia de archivos estáticos.

Hay 2 modelos que hemos usado para esto en el pasado:

  1. Un servidor Varnish entre NGINX y Apache que almacena en caché la respuesta de Apache y la sirve de manera mucho más eficiente (también hay otros tipos de servidores de almacenamiento en caché disponibles), o
  2. Un CDN

En general, la mejor práctica es usar un CDN cuando sea posible, un servidor de almacenamiento en caché cuando el CDN sea inapropiado. Varnish tiene la ventaja de encajar sobre una pila Apache estándar que le permite servir archivos dinámicos en caché, así como archivos estáticos (se complica, pero es bastante impresionante una vez que lo ha configurado correctamente). CDN tiene la ventaja de nunca llegar a su servidor web, ser distribuido, redundante, etc. Realmente no hay forma de que ninguna solución del lado del servidor compita contra un CDN.

Información sobre el barniz:

Varnish es un acelerador HTTP diseñado para sitios web dinámicos con mucho contenido, así como API muy consumidas. A diferencia de otros aceleradores web, como Squid, que comenzó su vida como un caché del lado del cliente, o Apache y nginx, que son principalmente servidores de origen, Varnish fue diseñado como un acelerador HTTP. Varnish se centra exclusivamente en HTTP, a diferencia de otros servidores proxy que a menudo admiten FTP, SMTP y otros protocolos de red.

Varnish es utilizado por sitios web de alto perfil y alto tráfico, incluyendo Wikipedia, sitios de periódicos en línea como The New York Times, The Guardian, The Hindu, Corriere della Sera, redes sociales y sitios de contenido como Facebook, Twitter, Vimeo y Tumblr . En 2012, el 5% de los 10.000 sitios principales en la web usaban el software. [2]

De: Varnish (software) – Wikipedia


Nota al margen sobre NGINX: en el pasado utilizamos NGINX para terminar SSL antes de enrutar solicitudes a Apache en el mismo servidor. Esto fue eficiente por varias razones. La mayoría de los entornos de nube ahora ofrecen terminación SSL en el nivel de equilibrador de carga virtual. Esto es superior cuando está disponible porque:

  • Reduce la carga del servidor web;
  • Si tiene un entorno de servidor web con equilibrio de carga, solo tiene que finalizar SSL en un punto, lo que da como resultado una infraestructura más simple de configuración y soporte.

La desventaja es que probablemente pagará por un equilibrador de carga virtual para cada dominio (esto puede ser costoso si está sirviendo a varios sitios web en una sola pila).

NGINX todavía cumple un hermoso papel como Proxy / Proxy inverso; y puede hacer muchas cosas además cuando se requieren casos de uso especializados.

Usar Nginx frente a apache para archivos estáticos seguirá siendo más rápido en el escenario que mencionó. Vamos a ejecutar el escenario con ambas configuraciones.

supongamos que tiene una página php llamada index.php que realiza un procesamiento dinámico de php y genera un html. este html incluía 5 archivos css, 3 archivos javascript y 20 imágenes png para mostrar en la página.

Caso 1: Apache Sirviendo contenido estático y dinámico

Paso 1: Apache procesará el archivo PHP y generará HTML que contiene las inclusiones.

Paso 2: el navegador recibe el html y realiza solicitudes para recuperar los archivos estáticos incluidos

Paso 3: Apache nuevamente recibe solicitudes para servir estos archivos estáticos. Apache servirá estos archivos estáticos.

Caso 2: nginx que sirve contenido estático mientras que apache proxy inverso para php

Paso 1: Nginx recibirá una solicitud de archivo php que se enviará a Apache. apache procesará el archivo php y generará el html que contiene las inclusiones para archivos estáticos.

Paso 2: el navegador recibe el html y realiza solicitudes para recuperar los archivos estáticos incluidos

El rendimiento en ambos casos hasta el paso 2 seguirá siendo el mismo.

Paso 3: NGinx recibe solicitudes para el servidor de estos archivos estáticos. NGinx servirá los archivos estáticos en sí. Este paso es lo que realmente hace la diferencia. En este escenario, los archivos estáticos se servirán más rápido que el caso 1, lo que dará como resultado una representación rápida de la página.


Si sacamos la conclusión. el navegador recibirá html para la página al mismo tiempo en ambos casos, pero para representar realmente la página, también necesita archivos estáticos, que luego se servirán más rápido en el caso de Nginx. Así es como Nginx aún debería brindarle un mejor rendimiento incluso si los archivos php son procesados ​​por apache en segundo plano.

Nginx almacena en caché todos los archivos estáticos. Por lo tanto, es capaz de manejar las solicitudes de estos archivos sin tener que pasar la solicitud a Apache.

Dicho esto, nunca tendría contenido dinámico y estático servido desde el mismo dominio. Idealmente, servir el contenido estático de un subdominio tiene sentido ya que podría almacenar en caché el contenido estático en el navegador sin tener que presionar un proxy inverso.

El principio general es que nginx está configurado para servir archivos estáticos y Apache httpd realiza el procesamiento de PHP, por lo que nginx en realidad maneja la solicitud HTTP (S) y simplemente pasa la página de PHP a httpd para su procesamiento. Una solución mucho mejor es eliminar por completo httpd y usar php-fpm.