Tengo un sistema que ejecuta nginx / php-fpm / varnish / wordpress y amazon s3.

Ahora he visto muchos archivos de configuración mientras configuraba el sistema, y ​​en todos encontré algo como esto:

    /* If the request is for pictures, javascript, css, etc */
    if (req.url ~ "\.(jpg|jpeg|png|gif|css|js)$") {
        /* Remove the cookie and make the request static */
        unset req.http.cookie;
        return (lookup);
    }

No entiendo por qué se hace esto. La mayoría de los ejemplos también ejecutan NginX como servidor web. Ahora la pregunta es, ¿por qué usaría el caché de barniz para almacenar en caché estos archivos estáticos?

Para mí tiene mucho más sentido almacenar en caché solo los archivos dinámicos para que php-fpm / mysql no se vea afectado demasiado.

¿Estoy en lo cierto o me falta algo aquí?

ACTUALIZAR

Quiero agregar información a la pregunta basada en la respuesta dada.

Si tiene un sitio web dinámico, donde el contenido realmente cambia mucho, chatear no tiene sentido. Pero si usa WordPress para un sitio web estático, por ejemplo, esto puede almacenarse en caché durante largos períodos de tiempo.

Dicho esto, lo más importante para mí es el concepto estático . He encontrado un enlace con algunas pruebas y puntos de referencia en diferentes aplicaciones de caché y aplicaciones de servidor web.

http://nbonvin.wordpress.com/2011/03/14/apache-vs-nginx-vs-varnish-vs-gwan/

NginX es realmente más rápido en obtener su contenido estático, por lo que tiene más sentido simplemente dejarlo pasar. NginX funciona muy bien con archivos estáticos.

-

Aparte de eso, la mayoría de las veces el contenido estático ni siquiera está en el servidor web. La mayoría de las veces este contenido se almacena en un CDN en algún lugar, tal vez AWS S3, algo así. Creo que el caché de barniz es el último lugar donde desea tener su contenido estático almacenado.

Varnish tiene algunas ventajas. El primero que observa es reducir la carga en un servidor de fondo. Por lo general, almacena en caché el contenido que se genera dinámicamente pero que rara vez cambia (en comparación con la frecuencia con la que se accede). Tomando su ejemplo de Wordpress, presumiblemente la mayoría de las páginas no cambian muy a menudo, y existen algunos complementos que invalidan un caché de barniz cuando cambia la página (es decir, nueva publicación, edición, comentario, etc.). Por lo tanto, almacena en caché indefinidamente e invalida en el cambio, lo que resulta en la carga mínima en su servidor de fondo.

A pesar del artículo vinculado, la mayoría de las personas sugeriría que Varnish funciona mejor que Nginx si se configura correctamente, aunque (y realmente odio admitirlo), mis propias pruebas parecen coincidir en que nginx puede servir un archivo estático más rápido que el barniz ( Afortunadamente, no uso barniz para ese propósito). Creo que el problema es que si terminas usando Varnish, has agregado una capa adicional a tu configuración. Pasar a través de esa capa adicional al servidor de fondo siempre será más lento que simplemente servir directamente desde el backend, y es por eso que permitir que Varnish se almacene en caché puede ser más rápido: ahorra un paso. La otra ventaja está en el frente del disco io. Si configura el barniz para usar malloc, no golpea el disco en absoluto, lo que lo deja disponible para otros procesos (y generalmente aceleraría las cosas).

Creo que uno necesitaría un mejor punto de referencia para medir realmente el rendimiento. Solicitar repetidamente el mismo archivo único desencadena cachés del sistema de archivos que comienzan a desviar la atención de los propios servidores web. Un punto de referencia mejor usaría el sitio con unos pocos miles de archivos estáticos aleatorios (posiblemente incluso de los registros de su servidor) para simular tráfico realista. Sin embargo, como mencionó, se ha vuelto cada vez más común descargar contenido estático en un CDN, lo que significa que Varnish probablemente no lo servirá para empezar (usted menciona S3).

En un escenario del mundo real, es probable que priorice el uso de su memoria: primero el contenido dinámico, ya que es el más costoso de generar; luego pequeño contenido estático (por ejemplo, js / css) y, por último, imágenes: probablemente no almacenaría en caché otros medios en la memoria, a menos que tenga una buena razón para hacerlo. En este caso, con Varnish cargando archivos desde la memoria y nginx cargándolos desde el disco, Varnish probablemente superará a nginx (tenga en cuenta que los cachés de nginx son solo para proxy y fastCGI, y esos, por defecto, están basados ​​en disco, aunque es posible usar nginx con memcached).

(Mi prueba rápida, muy áspera, para no tener ninguna credibilidad, mostró que nginx (directo) fue el más rápido, llamémoslo 100%, el barniz (con malloc) fue un poco más lento (aproximadamente 150%) y nginx detrás del barniz ( con pase) fue el más lento (alrededor del 250%). Eso habla por sí mismo, todo o nada, agregando el tiempo adicional (y el procesamiento) para comunicarse con el back-end, simplemente sugiere que si está utilizando Varnish y tiene la RAM de sobra , también puede almacenar en caché todo lo que pueda y servirlo desde Varnish en lugar de pasarlo a nginx).

Creo que te puedes estar perdiendo algo.

Por definición, los archivos dinámicos cambian. Por lo general, cambian al realizar algún tipo de consulta en la base de datos que afecta el contenido de la página que se sirve al usuario. Por lo tanto, no desea almacenar en caché el contenido dinámico. Si lo hace, simplemente se convierte en contenido estático y probablemente en contenido estático con contenido incorrecto.

Como ejemplo simple, supongamos que tiene una página con el nombre de usuario del usuario conectado en la parte superior de la página. Cada vez que se carga esa página, se ejecuta una consulta en la base de datos para determinar qué nombre de usuario pertenece al usuario conectado que solicita la página, lo que garantiza que se muestre el nombre correcto. Si tuviera que almacenar en caché esta página, la consulta de la base de datos no se realizaría y todos los usuarios verían el mismo nombre de usuario en la parte superior de la página y probablemente no será su nombre de usuario. Necesita que se realice esa consulta en cada carga de la página para asegurarse de que se muestre el nombre de usuario adecuado a cada usuario. Por lo tanto, no se puede almacenar en caché.

Extienda esa lógica a algo un poco más problemático como los permisos de usuario y podrá ver por qué el contenido dinámico no debe almacenarse en caché. Si la base de datos no se ve afectada por el contenido dinámico, el CMS no tiene forma de determinar si el usuario que solicita la página tiene permisos para ver esa página.

El contenido estático es, por definición, el mismo para todos los usuarios. Por lo tanto, no es necesario realizar una consulta de la base de datos para personalizar esa página para cada usuario, por lo que tiene sentido almacenar en caché para eliminar consultas innecesarias de la base de datos. Las imágenes son un gran ejemplo de contenido estático: desea que todos los usuarios vean la misma imagen de encabezado, los mismos botones de inicio de sesión, etc., por lo que son excelentes candidatos para el almacenamiento en caché.

En su fragmento de código anterior, está viendo un fragmento VCL de Varnish muy típico que obliga a almacenar en caché las imágenes, CSS y JavaScript. De manera predeterminada, Varnish no almacenará en caché ninguna solicitud que contenga una cookie. La lógica es que si hay una cookie en la solicitud, entonces debe haber alguna razón por la cual el servidor necesita esa cookie, por lo que es necesaria en el back-end y debe pasar a través de la caché. En realidad, muchos CMS (Drupal, Wordpress, etc.) adjuntan cookies a casi todo lo que sea necesario o no, por lo que es común escribir VCL para quitar las cookies del contenido que se sabe que es estático, lo que a su vez hace que Varnish se almacene en caché eso.

¿Tener sentido?

En el caso de los contenidos dinámicos , algunos tipos de cotizaciones de valores cambian con frecuencia (se actualizan cada segundo en un SaaS serverde a backend server), pero podrían consultarse aún más a menudo (por decenas de miles de subscription clients):

[stock calculation / backend server] ----- [SaaS server] ------ [subscription clients]

En este caso, el almacenamiento en caché de la SaaS serveractualización por segundo backend serverspermite satisfacer las consultas de decenas de miles de subscription users.

Sin un caché en el servidor SaaS, este modelo simplemente no funcionaría.

El almacenamiento en caché de archivos estáticos con Varnish se beneficiaría en términos de descargar Nginx. Por supuesto, si tiene muchos archivos estáticos para almacenar en caché, desperdiciará RAM. Sin embargo, Varnish tiene una buena característica: admite múltiples backends de almacenamiento para su caché.

Para archivos estáticos: caché a HDD Para todo lo demás: caché a RAM.

Esto debería darle más información sobre cómo implementar este escenario: http://www.getpagespeed.com/server-setup/varnish-static-files-cache