Tabla de contenido:
- Una introducción al barniz
- Los fundamentos: imágenes de caché
- El estándar: imágenes y páginas de caché
- El estándar ++: aumentar la resistencia del servidor
- Uso avanzado: crear un servidor web resistente en un entorno distribuido
- Una herramienta poderosa
Cuando se trata del rendimiento del sitio web, Varnish es una tecnología de moda. Con una instalación y configuración simples, es posible aumentar el rendimiento de cualquier sitio web y servir hasta un millón de páginas con solo un pequeño servidor privado virtual., Le mostraré cuatro configuraciones posibles que lo ayudarán a mejorar el tiempo de respuesta de su sitio, ya sea que sirva cientos, miles o millones de páginas.
Una introducción al barniz
Varnish-Cache es un acelerador web con el objetivo de almacenar en caché el contenido del sitio web. Es un proyecto de código abierto que tiene como objetivo optimizar y acelerar el acceso a sitios web de manera no invasiva, sin cambiar el código, y le permite poner sus manos en su sitio web.
Fueron los creadores de Varnish Cache quienes lo llamaron un acelerador web, porque su objetivo principal es mejorar y acelerar el front-end de un sitio web. Varnish logra esto almacenando copias de las páginas servidas por el servidor web en su caché. La próxima vez que se solicite la misma página, Varnish servirá la copia en lugar de solicitar la página del servidor web, lo que generará un tremendo aumento del rendimiento.
Otra de las características clave de Varnish Cache, además de su rendimiento, es la flexibilidad de su lenguaje de configuración, VCL. VCL hace posible escribir políticas sobre cómo se deben manejar las solicitudes entrantes. En dicha política, puede decidir qué contenido desea servir, de dónde desea obtener el contenido y cómo se debe modificar la solicitud o la respuesta.
En los siguientes ejemplos de configuración, le mostraré qué reglas de VCL usar para lograr algunos objetivos, desde un simple almacenamiento en caché de imágenes y objetos estáticos, hasta usar Varnish en un entorno distribuido o hacer que actúe como un equilibrador de carga.
Todos los siguientes ejemplos son para Varnish 3.x. Tenga en cuenta que Varnish 2.x utiliza diferentes sintaxis y reglas, por lo que estos ejemplos no son compatibles con esa versión.
Los siguientes son los principales estados de Varnish, que usaremos en el archivo de configuración de VCL:
recv
Esta es la primera función que se llama al recibir una solicitud. Aquí podemos manipular la solicitud antes de verificar si está presente en el caché. Si una solicitud no se puede poner en una memoria caché, el servidor de fondo al que se enviará la solicitud también se puede elegir en esta fase.
pasar
Podemos usar esta función cuando queremos pasar la solicitud al servidor web y guardar la respuesta en caché.
tubo
Esta función omite Varnish y envía la solicitud al servidor web.
buscar
Con una búsqueda, Varnish solicita verificar si la respuesta está presente y es válida en el caché.
ir a buscar
Se llama a esta función después de que un pase o una falla invoca la recuperación de contenido del back-end.
Los fundamentos: imágenes de caché
Así que veamos un ejemplo de configuración. En este primer ejemplo, solo almacenaremos en caché las imágenes y los archivos estáticos como archivos CSS. Esta configuración es realmente útil cuando no conoce el sitio web que desea impulsar, por lo que puede decidir que todas las imágenes, CSS y JavaScript son iguales para todos los usuarios. Para distinguir a los usuarios, el protocolo HTTP utiliza cookies, por lo que tenemos que eliminarlos en este tipo de solicitud para que todos sean iguales para Varnish:
sub vcl_recv{
if(req.url ~ " * \.(png|gif|jpg|swf|css|js)"{
unset req.http.cookie;
unset req.http.Vary;
return(lookup);
}
# strip the cookie before the image is inserted into cache.
sub vcl_fetch {
if (req.url ~ "\.(png|gif|jpg|swf|css|js)$") {
unset beresp.http.set-cookie;
}
Y eso es. Con este archivo VCL puede almacenar fácilmente en caché el contenido estático.
El estándar: imágenes y páginas de caché
Por lo general, no solo desea almacenar en caché el contenido estático de su sitio web, sino que también desea almacenar en caché algunas páginas dinámicas generadas por su servidor web, pero que son las mismas para todos los usuarios, o al menos para todos sus anónimos usuarios. En esta fase, debe saber elegir qué páginas se pueden almacenar en caché y cuáles no.
Un buen ejemplo es Wordpress, uno de los sistemas de gestión de contenido más utilizados. Wordpress genera páginas de sitios web dinámicamente con PHP y consultas a una base de datos MySQL. Esto es bueno porque puede actualizar fácilmente su sitio web desde la interfaz de administración con unos pocos clics, pero también es costoso en términos de recursos utilizados. ¿Por qué ejecutar el mismo script PHP y la consulta MySQL cada vez que un usuario llega a la página de inicio? Podemos usar Varnish para almacenar en caché las páginas más visitadas y lograr resultados increíbles.
Estas son algunas reglas que pueden ser útiles en una instalación de Wordpress:
sub vcl_recv{
# Let's make sure we aren't compressing already compressed formats.
if (req.http.Accept-Encoding) {
if (req.url ~ "\.(jpg|png|gif|gz|tgz|bz2|mp3|mp4|m4v)(\?. * |)$") {
remove req.http.Accept-Encoding;
} elsif (req.http.Accept-Encoding ~ "gzip") {
set req.http.Accept-Encoding = "gzip";
} elsif (req.http.Accept-Encoding ~ "deflate") {
set req.http.Accept-Encoding = "deflate";
} else {
remove req.http.Accept-Encoding;
}
}
if (req.url ~ "^/$") {
unset req.http.cookie;
}
# Unset all cookies if not Wordpress admin - otherwise login will fail
if (!(req.url ~ "wp-(login| admin )")) {
unset req.http.cookie;
return(lookup);
}
# If you request the special pages go directly to them
if (req.url ~ "wp-(login| admin )") {
return (pipe);
}
}
sub vcl_miss {
if (!(req.url ~ "wp-(login| admin )")) {
unset req.http.cookie;
}
if (req.url ~ "^/+.(jpeg|jpg|png|gif|ico|js|css|txt|gz|zip|lzma|bz2|tgz|tbz|html|htm)(\?.|)$") {
unset req.http.cookie;
set req.url = regsub(req.url, "\?.$", "");
}
if (req.url ~ "^/$") {
unset req.http.cookie;
}
}
sub vcl_fetch {
if (req.url ~ "^/$") {
unset beresp.http.set-cookie;
}
# Unset all cookies if not Wordpress admin - otherwise login will fail
if (!(req.url ~ "wp-(login| admin )")) {
unset beresp.http.set-cookie;
}
}
Puede ver que en este ejemplo, almacenamos en caché todas las páginas de nuestro sitio web, pero para las que tienen "wp-admin" o "wp-login" en la url, las cadenas son ubicaciones "especiales" que se utilizan para iniciar sesión en Wordpress como administrador. Como tal, queremos hablar directamente con el servidor web y omitir el caché de Varnish.
Naturalmente, si usa Drupal, Joomla o un sitio web personalizado, debe cambiar estas reglas, pero el objetivo es siempre el mismo: para enviar todas las páginas dinámicas y la memoria caché que pueda a su back-end.
El estándar ++: aumentar la resistencia del servidor
En algún momento, los servidores web se vuelven lentos porque tienen una gran carga. El barniz también puede ayudar con esto. Podemos usar algunas directivas especiales para decirle a Varnish que evite hablar con el back-end si está inactivo o si responde demasiado lento. Para estos casos, Varnish utiliza la directiva de "gracia".
La gracia en el alcance de Varnish significa entregar objetos expirados cuando las circunstancias lo requieren. Esto puede suceder porque:
- El director de back-end seleccionado está inactivo
- Un subproceso diferente ya ha realizado una solicitud al back-end que aún no está terminado.
sub vcl_recv {
if (req.backend.healthy) {
set req.grace = 30s;
} else {
set req.grace = 1h;
}
}
sub vcl_fetch {
set beresp.grace = 1h;
}
Esta configuración le dice a Varnish que pruebe el back-end y aumente el período de gracia si tiene algunos problemas. El ejemplo anterior también presenta la directiva "req.backend.healthy", que se usa para verificar un back-end. Esto es realmente útil cuando tiene múltiples back-end, así que echemos un vistazo a un ejemplo más avanzado.
Uso avanzado: crear un servidor web resistente en un entorno distribuido
Este es nuestro archivo de configuración final con todas las opciones que hemos visto hasta ahora y la definición de dos back-end con alguna directiva especial para la sonda. Así es como Varnish determina si un servidor web está vivo o no.
.url
Varnish realizará solicitudes al back-end con esta URL.
.se acabó el tiempo
Determina qué tan rápido debe terminar la sonda. Debe especificar una unidad de tiempo con un número, como "0.1 s", "1230 ms" o incluso "1 h".
.intervalo
Cuánto tiempo esperar entre las encuestas. Debe especificar una unidad de tiempo aquí también. Tenga en cuenta que esto no es una "tasa" sino un "intervalo". La tasa de sondeo más baja es (.timeout + .interval).
.ventana
Cuántas de las últimas encuestas a tener en cuenta al determinar si el back-end es saludable.
.límite
¿Cuántas de las últimas encuestas de .window deben ser buenas para que el back-end se declare saludable?
Ahora podemos usar la directiva "req.backend.healthy" y obtener un resultado booleano que nos diga si los back-end están vivos o no.
#
# Customized VCL file for serving up a Wordpress site with multiple back-ends.
#
# Define the internal network subnet.
# These are used below to allow internal access to certain files while not
# allowing access from the public internet .
acl internal {
"10.100.0.0"/24;
}
# Define the list of our backends (web servers), they Listen on port 8080
backend web1 { .host = "10.100.0.1"; .port = "8080"; .probe = { .url = "/status.php"; .interval = 5s; .timeout = 1s; .window = 5;.threshold = 3; }}
backend web2 { .host = "10.100.0.2"; .port = "8080"; .probe = { .url = "/status.php"; .interval = 5s; .timeout = 1s; .window = 5;.threshold = 3; }}
# Define the director that determines how to distribute incoming requests.
director default_director round-robin {
{ .backend = web1; }
{ .backend = web2; }
}
# Respond to incoming requests.
sub vcl_recv {
set req.backend = default_director;
# Use anonymous, cached pages if all backends are down.
if (!req.backend.healthy) {
unset req.http.Cookie;
set req.grace = 6h;
} else {
set req.grace = 30s;
}
# Unset all cookies if not Wordpress admin - otherwise login will fail
if (!(req.url ~ "wp-(login| admin )")) {
unset req.http.cookie;
return(lookup);
}
# If you request the special pages go directly to them
if (req.url ~ "wp-(login| admin )") {
return (pipe);
}
# Always cache the following file types for all users.
if (req.url ~ "(?i)\.(png|gif|jpeg|jpg|ico|swf|css|js|html|htm)(\?+)?$") {
unset req.http.Cookie;
}
}
# Code determining what to do when serving items from the web servers.
sub vcl_fetch {
# Don't allow static files to set cookies.
if (req.url ~ "(?i)\.(png|gif|jpeg|jpg|ico|swf|css|js|html|htm)(\?+)?$") {
# beresp == Back-end response from the web server.
unset beresp.http.set-cookie;
}
# Allow items to be stale if needed.
set beresp.grace = 6h;
}
Una herramienta poderosa
Estos son solo algunos ejemplos que pueden ayudarlo a comenzar a usar Varnish. Esta herramienta es realmente poderosa y puede ayudarlo a lograr un gran aumento de rendimiento sin comprar más hardware o máquinas virtuales. Para muchos administradores de sitios web, eso es un beneficio real.
