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.
fuente
if (req.url ~ "\.(png|gif|jp(e?)g|avi|flv|mp(e?)g|mp4|mp3)"){return(pass);}en vcl_recv (). Esencialmente, no quiero almacenar en caché los medios, pero definitivamente quiero almacenar en caché html (php) e incluso js / css (la teoría es que las imágenes contribuyen menos al tiempo de carga de página percibido que el diseño).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?
fuente
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 abackend server), pero podrían consultarse aún más a menudo (por decenas de miles desubscription clients):En este caso, el almacenamiento en caché de la
SaaS serveractualización por segundobackend serverspermite satisfacer las consultas de decenas de miles desubscription users.Sin un caché en el servidor SaaS, este modelo simplemente no funcionaría.
fuente
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
fuente