Introducción a Varnish Cache

Introducción a la instalación y despliegue de Varnish Cache
Varnish Cache

“No tienes que ser mejor que todos los
demás. Tienes que ser mejor de lo que
nunca pensaste que podrías ser.”
Ken Venturi

Índice
1. Algunos datos sobre Irontec
2. ¿Qué es Varnish Cache?
3. Escenarios Típicos para el Despliegue de Varnish Cache
4. Versiones de Varnish Cache
5. Instalación de Varnish Cache
6. Conceptos Teóricos Precios
7. Introducción a la Gestión Interna de Varnish Cache y sus Flujos
8. Obtención de Estadísticas
9. Configuración de Varnish Cache
10. Monitorización de Varnish Cache
11. Configuraciones Específicas para WordPress
12. Conclusiones

algunos datos sobre Irontec
10 años de experiencia en el mundo del Software Libre
30 puestos de trabajo centrados 100% en Software
Libre
Desarrollo de aplicaciones para Internet, Sistemas y
Telefonía IP como ejes corporativos
Diversificación en clientes y servicios
Empresa fundadora de ESLE

¿Qué es Varnish Cache?
• Según la página oficial: https://www.varnish-cache.org/
• Acelerador de aplicaciones web.
• Se instala delante de cualquier servidor HTTP. Introduce el concepto
de servidor de backend.
• Caché de proxy HTTP inverso.
• Software libre licenciado bajo la licencia FreeBSD.

¿Qué es Varnish Cache?
• “Intercepta” las peticiones que los clientes realizan sobre una
aplicación web, utilizando una serie de mecanismos para
acelerar la gestión de dichas peticiones.

3. Escenarios Típicos para el Despliegue de
Varnish Cache

Escenarios Típicos para el Despliegue de Varnish Cache
✔ Aplicaciones web que responden lentamente a las peticiones de
usuario.
✔ Aplicaciones web disponibles en varios servidores diferentes.
✔ Aplicaciones web con diferentes versiones según el tipo de
dispositivo y
✔ Aplicaciones web con gran carga de transacciones.
✔ Aplicaciones web con excesivo tráfico.
✔ …

Versiones de Varnish Cache
• Versión “OS”
– Es software libre, ¿acaso podría ser mejor?
– ¿Hemos comentado ya que es software libre?
– Lo dicho, OpenSource.
• Version “Subscription” (http://www.varnish-software.com)
– Incluye soporte de Varnish Software
– Incluye productos propietarios
– Añade soluciones que proporcionan valor añadido a Varnish
Cache

5. Instalación de Varnish Cache

Instalación de Varnish Cache
Usando el gestor de paquetes (Debian)
• # curl http://repo.varnish-cache.org/debian/GPG-key.txt| apt-key add -
• # echo "deb http://repo.varnish-cache.org/debian/wheezy varnish-3.0” >>
/etc/apt/sources.list
• # apt-get update
• # apt-get install varnish
Puede sustituirse wheezywheezy por squeezesqueeze
dependiendo de la versión de Debian
sobre la que quiera instalarse Varnish.
Puede instalarse la versión 2.1 de Varnish
sustituyendo varnish-3.0varnish-3.0 por
varnish-2.1varnish-2.1

Usando el gestor de paquetes (Debian)
• Los ficheros de configuración se ubican en:
– /etc/varnish
• El fichero con la configuración principal es:
– /etc/varnish/default.vcl
• Se añade automáticamente la configuración para
el inicio del servicio en posteriores reinicios. Los
parámetros pueden modificarse editando el
fichero:
– /etc/default/varnish

Compilando el Código Fuente (Debian)
• # wget http://repo.varnish-cache.org/source/varnish-3.0.5.tar.gz
• # apt-get install build-essential automake libtool
pkg-config libpcre3-dev libncurses-dev xsltproc
groff-base libedit-dev1
• # cd varnish-cache
• # sh autogen.sh
• # sh configure
• # make
• # make check
• # make install
Es normal que al ejecutar “make check”
de uno o dos errores.

Compilando el Código Fuente (Debian)
• Los ficheros de configuración se ubican en:
– /usr/local/etc/varnish
• El fichero con la configuración principal es:
– /usr/local/etc/varnish/default.vcl
• No se instala la configuración necesaria para el
inicio del servicio. Debe crearse manualmente o
realizarse desde el CLI.
– Ej: # varnish -f /usr/local/etc/varnish/default.vcl -s malloc,1G -T 127.0.0.1:6081
-a :6081

6. Conceptos Teóricos Previos

En esta sección...
Trataremos los conceptos teóricos básicos
necesarios para comprender como funciona
Varnish; de donde toma los datos, como se
lleva a cabo su configuración, como realiza
determinados controles y como mantiene su
contenido cacheado “fresco”.

Conceptos Teóricos Previos
Servidor de Backend
• Servidor HTTP que provee el contenido que
Varnish debe acelerar.
• Se indica en el fichero de configuración de
Varnish mediante su IP y el puerto donde sirve el
contenido.

Servidor de Backend
• host
– Host que se usará como servidor de backend. Puede ser una IP o un hostname que
resuelva sobre una única IP.
• port
– El puerto del servidor de backend al que se conectará Varnish. El puerto por defecto para el
servicio HTTP es el 80.
• host_header
– Cabecera para añadir al host.
• connect_timeout
– El timeout para las conexiones.
• first_byte_timeout
– El timeout para el primer byte.
• between_bytes_timeout
– El timeout entre bytes.
• probe
– Pruebas de salud del host. Se detalla más adelante.
• max_connections
– Número máximo de conexiones que pueden abrirse contra el backend.

Servidor de Backend
• El servicio Varnish y el servicio HTTP que ofrece el contenido a acelerar pueden
estar en la misma máquina (1) o en máquinas diferentes (2).

VCL - (Varnish Configuration Language)
• Lenguaje específico para configurar Varnish.
• Se traduce en código binario que se ejecuta
cuando se reciben peticiones.
• Se organiza en subrutinas que se ejecutan en
diferentes etapas del proceso.
• En algún momento de la subrutina se invoca una
acción y la ejecución de la subrutina finaliza.
• Si no se invoca una acción y la subrutina llega a
su fin se ejecuta una lógica incluida con Varnish.
El código VCL correspondiente puede consultarse
en el fichero default.vcl

VCL - (Varnish Configuration Language)
https://www.varnish-cache.org/docs/trunk/reference/vcl.html
• Operadores
• Condicionales
• Tipos de datos
• Expresiones regulares
• Includes
• Imports
• ...

• vcl_recv
• vcl_pipe
• vcl_pass
• vcl_hash
• vcl_hit
• vcl_miss
• vcl_fetch
• vcl_deliver
• vcl_error
vcl_recv y vcl_fetch permiten el 99%
de las configuraciones que puedan
Requerirse.
Todas estas subrutinas se explican más
adelante en detalle.

• pass
– Hace que la solicitud y las consecuentas respuestas pasen hacia y
desde el servidor directamente sin ser cacheadas.
• lookup
– Indica a Varnish que entregue contenido de la caché.
• pipe
– Cortocircuita la conexión entre el cliente y el servidor de backend, de
manera que Varnish sólo mueve bytes entre uno y otro extremo hasta
que la conexión se cierra.
• deliver
– Remite el objeto cacheado al cliente.
• esi
– Lleva a cabo el procesamiento ESI sobre el documento recuperado.

• req
– Proviene del cliente.
– Cuando Varnish recibe una petición este objeto es creado y poblado.
– La mayor parte del trabajo en vcl_recv se hace sobre este objeto.
• beresp
– Respuesta que proviene del servidor de backend.
– Contiene las cabeceras y el objeto proveniente del servidor de
backend.
– La mayor parte del trabajo en vcl_fetch se hace sobre este objeto.
• obj
– El objeto cacheado.
– Es un objeto parcialmente de sólo lectura (excepto obj.ttl) que reside
en memoria.

Directors
• Consiste en un grupo lógico de servidores de
backend que proporcionan redundancia.
• Su rol principal es que Varnish pueda elegir entre
varios backend si alguno falla.

Directors
• Existen diferentes tipos de “Directors”, y cada uno
usa diferentes algoritmos para determinar qué
backend usar:
1. Random Directors
• El tráfico se distribuye entre los backend
asignados al director distribuyéndolo entre
ellos aleatoriamente según una “semilla”.
2. Round-Robin Director
3. DNS Director
4. Fallback Director

Directors
• Un director puede referenciar los backend o
definirlos inline.
• Ejemplo:

Directors – Random DirectorsRandom Directors
• Random DirectorRandom Director
– Usa un número generado aleatoriamente para
determinar el backend.
– Opciones Director:
● .retries: Opcional. Veces que intentará el
director localizar un backend saludable si el
primer intento falla.
– Opciones Backends:
● .weight: Indica la cantidad de tráfico que
tendrá un backend en relación a otros.

• Client DirectorClient Director
– Escoge un backend basado en la “identity” del
cliente. Se puede establecer la variable VCL
client.identity para identificar al cliente.

• Hash DirectorHash Director
– Escoge un backend en base al valor hash de la
URL. Útil para realizar balanceo de carga. Usa
el valor de req.hash.

Directors – Round-Robin DirectorRound-Robin Director
• Usa el primer backend para la primera petición,luego el segundo y
así hasta el último. Después vuelve al primero y otra vez a empezar.
• Si un backend no está sano, Varnish pasa al siguiente.
● Ninguna.
● Ninguna.

Directors – DNS DirectorDNS Director
• Puede usar los backends en modo random /
round-robin o usando .list.
● .list: Determina las lista IPs de los backend
que Varnish creará internamente. No soporta
IPv6.
● .ttl: Opcional. Duración de la caché de las
búsquedas (lookup) DNS.
● .suffix: Opcional. Sufijo que se añadirá a la
cabecera del host de entrada proporcionada
por el cliente.

Directors – DNS DirectorDNS Director
• Ejemplo:
• Se especifican 384 backends, todos usando el
puerto 80, con un timeout para la conexión de 0.4ms.
• Las opciones de los backend deben
especificarse antes de las lista de IPs.

Directors – Fallback DirectorFallback Director
• Coge el primer backend saludable. Los toma en
el orden en que se han definido.
● Ninguna.
• Ejemplo:

Health Checks – Backend Probes
• Pueden establecerse pruebas para determinar si
un backend está sano o no.
• El estado de un backend puede consultarse
usando req.backend.healthy.

• .url
– URL que Varnish solicitará para probar el backend. Por defecto
es “/”.
• .request
– Tiene precedencia sobre .url. Especifica una petición HTTP
usando varias cadenas de caracteres. Se inserta rn
automáticamente después de cada cadena de caracteres.
• .window
– Ventana con los últimos X resultados. Se sobrescriben los más
antiguos conforme se realizan nuevas pruebas. Por defecto es 8.
• .threshold
– Determina el número de entradas de .window que deben ser
positivas para que el backend sea declarado saludable. Por
defecto es 3.

• .initial
– Determina el número de entradas de .window que se
consideran positivas cuando Varnish se inicia. Por defecto
toma el valor de .threshold.
• .expected_response
– Respuesta que se espera recibir del backend. Por defecto
200.
• .interval
– Con qué frecuencia se realizan las pruebas. Por defecto
cada 5 segundos.
• .timeout
– Velocidad con que una prueba da un timeout. Por defecto
2 segundos.

• Ejemplos:

ACLs
• Las declaraciones de ACL (Access Control List)
crean e inicializan una lista de control de acceso
basado en nombres que pueden usarse
posteriormente para comprobar direcciones de
clientes.

Purging
• Una purga es lo que
sucede cuando se obtiene
un objeto de la caché y se
deshecha junto con todas
sus variantes.
• Se invoca a través de HTTP
con el método PURGE.

7. Introducción a la Gestión Interna de Varnish
Cache y sus Flujos

En esta sección...
Aprenderemos como es el flujo interno de
Varnish, como gestiona las peticiones que
recibe de los clientes hasta que les entrega el
contenido solicitado, pasando por como lo
obtiene del servidor de backend, como lo
cachea o que hace en caso de error.

Introducción a la Gestión Interna de Varnish Cache y sus Flujos
Máquina de Estados

Máquina de Estados - Modos
• recv (vcl_recv)
– Se invoca al comienzo de una petición, después de que la petición
haya sido recibida y parseada.
– Decide si se sirve o no a la petición, cómo se sirve y, dado el caso,
desde qué backend.
– Termina con una llamada a return() con alguna de las siguientes
palabras clave:
● error code [reason]
– Devuelve un código de error al cliente y abandona la petición.
● pass
– Cambia a modo pass. Transmitiá el control a vcl_pass.
● pipe
– Cambia a modo pipe. Transmitirá el control a vcl_pipe.
● lookout
– Busca el objeto en la caché. Transmitirá el control a vcl_hit o
vcl_miss dependiendo de si el objeto esa en la caché o no.

• pipe (vcl_pipe)
– Se invoca al entrar en modo pipe.
– En este modo la solicitud es remitida al servidor de backend y
cualquier dato intercambiado entre el cliente y el backend es
transmitido sin alterarse hasta que se cierra la conexión.
palabras clave:
– Devuelve un código de error al cliente y abandona la
petición.
● pipe
– Procede con el modo pipe.

• pass (vcl_pass)
– Se invoca al entrar en modo pass.
– En este modo la petición se pasa al backend y la respuesta del
backend se manda al cliente sin entrar en la caché
palabras clave:
petición.
● pass
– Procede con el modo pass.
● restart
– Reinicia la transacción e incrementa el contador de
reinicios. Si dicho contador supera max_restarts Varnish
arroja un error de “guru meditation”.

• hash (vcl_hash)
– Debe invocarse hash_data() sobre los datos que quieren
incorporarse al hash.
palabras clave:
● hash
– Procede.

• hit (vcl_hit)
– Se invoca después de una búsqueda (lookup) si el documento
solicitado se encuentra en la caché.
palabras clave:
● pass
● restart
– Reinicia la transacción e incrementa el contador de reinicios.
Si dicho contador supera max_restarts Varnish arroja un error
de “guru meditation”.
● deliver
– Entrega el objeto en caché al cliente. Transmitirá el control a
vcl_deliver.

• miss (vcl_miss)
– Se invoca después de una búsqueda (lookup) si el documento
solicitado no se encuentra en la caché.
– Su funcionalidad consiste en decidir si se intenta recuperar o no
el documento desde el backend y desde qué backend.
palabras clave:
petición.
● pass
● fetch
– Recupera el objeto solicitado del backend. Transmitirá el
contorl a vcl_fetch.

• fetch (vcl_fetch)
– Se invoca después de que un documento haya sido satisfactoriamente
recuperado del backend.
– Termina con una llamada a return() con alguna de las siguientes palabras
clave:
● esi
– Realiza un procesamiento ESI sobre el documento que ha sido
recuperado del backend.
● pass
● restart
– Reinicia la transacción e incrementa el contador de reinicios. Si dicho
contador supera max_restarts Varnish arroja un error de “guru
meditation”.
● deliver
– Incorpora el objeto a la caché y lo entrega al cliente. Transmitirá el
control a vcl_deliver.

• deliver (vcl_deliver)
– Se invoca antes de que un documento sea entregado al cliente.
palabras clave:
petición.
● restart
● deliver
– Entrega el objeto al cliente.

• error (vcl_error)
– Se invoca cuando se encuentra un error, tanto implícita como
exlícitamente, sea por errores internos o del backend.
palabras clave:
● restart
● deliver
– Entrega el objeto al cliente.

Flujos

8. Obtención de Estadísticas

Obtención de Estadísticas
• Varnish no logea en ficheros, lo hace en segmentos de memoria
que, llegado un tamaño, se sobrescriben.
¡CUIDADO! Esto es muy rápido. Varnish es rápido, pero si
no se escriben los logs a disco desaparecerán

• varnishlogvarnishlog
– Lee y muestra por consola los logs que el servicio de Varnish
está generando en memoria.
– Opciones más comunes:
● -b: Muestra sólo registros del tráfico transmitido entre Varnish
y el backend.
● -c: Muestra sólo los registros del tráfico transmitido entre
Varnish y el cliente.
● -m tag:regex: Muestra sólo las transacciones donde la
etiqueta concuerda con una expresión regular.
– https://www.varnish-cache.org/docs/3.0/reference/varnishlog.html

• varnishlogvarnishlog

• varnishhistvarnishhist
– Lee los registros que Varnish está generando y muestra un
histograma que se actualiza continuamente mostrando la
distribución de las últimas N peticiones.
● -b: Muestra sólo registros del tráfico transmitido entre Varnish
y el backend.
● -c: Muestra sólo los registros del tráfico transmitido entre
Varnish y el cliente.
● -d: Procesa entradas de registro viejas cuando se inicia. Por
defecto toma los datos que se generan a partir del inicio de
su ejecución.
● -m tag:regex: Muestra sólo las transacciones donde la
etiqueta concuerda con una expresión regular.
– https://www.varnish-cache.org/docs/3.0/reference/varnishhist.html

• varnishhistvarnishhist

• varnishtopvarnishtop
– Lee los registros que Varnish está generando y muestra una lista
actualizada con las entradas de registro más frecuentes.
● -1: No actualiza la lista, muestra las estadísticas una vez y
sale (implica -d).
● -b, -c, -d: Estas opciones realizan la misma función que con
el comando anterior (varnishhist).
– https://www.varnish-cache.org/docs/3.0/reference/varnishtop.html

• varnishtopvarnishtop

• varnishsizesvarnishsizes
– Lee los registros que Varnish está generando y muestra un
histograma que se actualiza continuamente mostrando la
distribución de las últimas N peticiones en una escala logarítmica
que representa los bytes.
● -b, -c, -d: Estas opciones realizan la misma función que en
comandos anteriores (varnishhist).
– https://www.varnish-cache.org/docs/3.0/reference/varnishsizes.html

• varnishsizesvarnishsizes

• varnishstatvarnishstat
– Muestra estadísticas de la instancia de Varnish que está en
ejecución.
● -1: No actualiza la lista, muestra las estadísticas una vez por
la salida estándar y finaliza.
● -x: Muestra los resultados en formato XML (-j para hacerlo en
formato JSON).
– https://www.varnish-cache.org/docs/3.0/reference/varnishstat.html

• varnishstatvarnishstat

• varnishncsavarnishncsa
– Lee los registros generados por Varnish en memoria en el
formato de registro “combined” Apache/NCSA.
● -a: En caso de escribirse a un fichero anexa la información,
no la sobrescribe.
● -d: Procesa entradas de registro viejas cuando se inicia. Por
defecto toma los datos que se generan a partir del inicio de
su ejecución.
● -f: Hace que prevalezca la cabecera HTTP X-Forwarded-For
frente a client.ip en el registro.
● -D: Ejecuta el comando como un demonio.
● -F format: Especifica el formato usado para el registro.
– https://www.varnish-cache.org/docs/3.0/reference/varnishncsa.html

9. Configuración de Varnish Cache

En esta sección...
Haremos una pequeña introducción a la
configuración básica de Varnish, tanto desde
un acercamiento teórico como su aplicación
práctica usando el VCL.

Configuración de Varnish Cache
Iniciar Varnish (/etc/default/varnish)
• # pkill varnishd
• # varnishd -f /etc/varnish/default.vcl -s malloc,1G -T 127.0.0.1:2000 -a 0.0.0.0:8080
– -f: Ruta al fichero de la configuración que usará Varnish.
– -s: Tipo y cantidad de almacenamiento que usará Varnish.
– -T: Activa la consola de administración en modo texto de Varnish (accesible
mediante telnet). Permite manejar Varnish sin detener el servicio.
– -a: Especifica el puerto en que Varnish escuchará peticiones HTTP entrantes.

Determinar el Tipo de Almacenamiento
• Asociado al parámetro -s existen los siguientes tipos de almacenamiento:
1. malloc[,size]
• Los objetos cacheados se almacenan en la memoria.
• Si el sistema se queda sin memoria usará el swap (¡OJO!)
• Añade una sobrecarga de 1K por cada objeto.
• El tamaño puede expresarse en K(ibibytes), M(ebibytes), G(ibibytes), T(ebibytes). Por
defecto es ilimitado.
2. file[,path[,size[,granularity]]]
• Los objetos cacheados se almacenan en un fichero de disco con mmap.
• Es la opción usada por defecto si no se especifica otra.
• El tamaño puede expresarse igual que en el caso de malloc, pero se añade la opción %,
que indica usar un determinado porcentaje del espacio libre en disco.
3. persistent,path,size {experimental}
• Almacenamiento persistente. Los objetos cacheados se almacenan en un fichero de
manera que la mayoría pueda sobrevivir en caso de una parada de Varnish.
• El tamaño puede expresarse igual que en el caso de malloc.

Determinar el Algoritmo de Hash
• Asociado al parámetro -h existen los siguientes algoritmos de hash:
1. simple_list
• Lista simple con doble enlace.
• No es recomendable usarlo en entornos de producción.
2. classic[,buckets]
• Tabla estándar de hash. Es la opción por defecto.
• La llave hash es el CRC32 de la URL del objeto. Cada entrada de la tabla apunta a un
conjunto de objetos que comparten las misma llave hash.
• El bucket determina el número de entradas de la tabla hash. Por defecto es 16383.
3. critbit
• Estructura de árbol autoescalable.
• El árbol Crit-Bit es comparativamente mejor que el típico árbol B.

Determinar el Tamaño de la Caché
• Determinar el tamaño de la caché es uno de los pasos más
importantes de la configuración de Varnish.
• Cuestiones a tener en cuenta:
– El tamaño de la información “viva”
Por ejemplo: Página principal + un nivel con todos sus objetos
– El coste de generar un objeto
Por ejemplo: Imágenes, fáciles de servir desde el backend
– El valor del contador n_lru_nuked de varnishstat
Mucha actividad LRU indica que se están eliminando objetos por problemas de espacio, así que habría que incrementar es espacio
de caché)
¡CUIDADO! Varnish añade una sobrecarga
de 1Kb a cada objeto que almacena en
Memoria. Si hay mucho objetos pequeños
puede suponer un problema.

Poner Varnish a Escuchar en el Puerto 80
1. Si el servidor de backend y Varnish están en la misma
máquina y el servidor de backend escucha en el
puerto estándar (80), habrá que modificarlo.
2. Nos aseguramos de que el servicio de Varnish no está
en ejecución.
● # pkill varnishd
3. O bien modificamos la configuración del servicio de
Varnish (/etc/default/varnish) y lo reiniciamos (service
varnishd restart), o ejecutamos el comando para iniciar
el servicio con los parámetros adecuados.
● # varnishd -f /etc/varnish/default.vcl -s malloc,1G -T 127.0.0.1:2000

Varnish Configuration Language
● Repasemos un poco VCL:
● Ejemplos:

Lograr un Ratio Elevado de Hits
• Analizar las peticiones de los clientes y las
cabeceras que se transmiten.
– varnishtop -i txurl
– varnishlog -c -m 'RxURL:^/foo/bar
– lwp-request (Perl)
– Live HTTP Headers
https://addons.mozilla.org/es/firefox/addon/live-http-headers/

• Con cada petición HTTP vienen cabeceras con
metadatos que le dicen a Varnish qué hacer con el
contenido. Algunas de las más importantes son:
– Cache-Control
– Age
– Pragma
– Authorization

• Otras opciones para incrementar el ratio de hits:
– Incrementar el TTL
– Forzar el cacheo de ciertas peticiones y
respuestas (NO RECOMENDADO)
– Normalizar el namespace

Cookies
• Varnish, por defecto, no cacheará objetos
provinientes del backend con la cabecera
Set-Cookie.
• Igualmente, si el cliente manda una cabecera
Cookie, Varnish hará un bypass y enviará la
petición directamente al servidor de backend.
MUY CONSERVATIVO
Para muchas aplicaciones web
pueden descartarse completamente
las cookies salvo para
determinadas secciones.

Cookies
• Del clientecliente:

Cookies
• Del servidor de backendservidor de backend:
– Si el servidor de backend pone una cookie
usando la cabecera Set-Cookie, Varnish no
cacheará la página.
– Se crea un objeto hit-for-pass.

Vary
• La cabecera Vary, enviada por el servidor web, indica qué es
lo que hace a un objeto HTTP “cambiar su apariencia” (vary).
• Varnish cachea versiones separadas de un objeto por cada
Vary.
Ejemplo / PROBLEMA SOLUCIÓN
“Vary: Accept-Encoding” le dice a Varnish
que guarde una versión diferente por
cada Accept-Encoding, pero ese campo
puede contener un montón de
codificaciones diferentes.
Cuando diferentes navegadores manden
diferentes Accept-Encoding (ejemplo),
aunque sólo en apariencia, Varnish
mantendrá una variante diferente de la
página por cada uno de ellos.
Normalizar con VCL la cabecera Accept-Encoding de manera que haya tan
pocas variantes como sea posible. El ejemplo comprueba si el cliente acepta
gzip, en cuyo caso prevalece, si no deflate.

Vary
• Si hay errores de parseo de la cabecera Vary o la cabecera
supera los 65Kb caracteres:
– Página de error 503 (internal server error)
– Se añade entrada SLT_Error al registro
• Muchas veces se envía “Vary: User-Agent” con el contenido:
– Problema: Algunas aplicaciones o servidores de aplicaciones
mandan un Vary: User-Agent con su contenido
– Solución: Normalizar las cabeceras User-Agent

Compresión
• Varnish tiene soporte nativo para compresión usando gzip.
• Activado por defecto, puede desactivarse con el parámetro
http_gzip_support a false (varnishd).
• Comportamiento:
1. Varnish comprueba si el cliente acepta la compresión gzip.
2. Si lo hace desprecia el valor de la cabecera
Accept-Encoding y la establece en “gzip”.
3. Realiza entonces la solicitud al servidor de backend del
contenido comprimido en gzip. Varnish almacenará el
objeto en caché tal y como se lo entregue el backend.
¡CUIDADO! Hay que evitar intentar
comprimir contenido que no es
comprimible (JPG, GIF, MP3, etc).
Hace que Varnish comprima el contenido antes de
almacenarlo en caché.

ESI (Edge Side Includes)
• ESI es un lenguaje para incluir fragmentos de páginas
web dentro de páginas web. Es una sentencia include
para HTML que funciona sobre HTTP.
• Implementación parcial de ESI en Varnish:
– esi:include
– esi:remove
– 
http://www.akamai.com/html/support/esi.html

ESI (Edge Side Includes)
• Ejemplo:
• Ejemplo:

Detección de Dispositivo
https://github.com/varnish/varnish-devicedetect/
• La detección de dispositivo consiste en determinar el
contenido que el servidor debe proporcionar al cliente
basándose en la cabecera User-Agent proporcionada
en la solicitud.

Detección de Dispositivo
• Ejemplo:
• Ejemplo:
Varnish añade la cabecera
HTTP X-UA-Device a la solicitud
al servidor de backend, el
cual indica en la cabecera Vary
de la respuesta que el contenido
es dependiente de dicha
cabecera.
Establecemos la cabecera.

Websockets
• Tecnología que proporciona un canal de
comunicación bidireccional y full-duplex sobre un
único socket TCP diseñada para ser
implementada en navegadores y servidores web.
• Para ejecutar websockets a través de Varnish hay
que hacer lo siguiente.
http://www.websocket.org/ - http://dev.w3.org/html5/websockets/

VMOD (Extensiones y Módulos de Varnish)
• Las VMOD son extensiones para Varnish.
• Disponibles en un directorio, donde se indica su estado (en desarrollo,
prueba de concepto, en producción), la licencia bajo la que se ofrecen y si
disponen o no de soporte comercial.
• Algunas son:
– Cookie
– Dclass Apache DeviceMap
– cURL
– Soft purge
– Header manipulation
– Digest
– Shield
– ...
https://www.varnish-cache.org/vmods

CLAVES
● Conocer si la instalación de Varnish se va a realizar en donde se ubicará el
servidor de backend y si se trata de un entorno virtualizado.
● Determinar todos los dominios que sirven el mismo contenido.
● Determinar si existen diferentes versiones de la web para diferentes
dispositivos.
● Conocer el peso de la página principal con todos sus objetos mas el primer
nivel de enlaces.
● Conocer el uso que se hace de las sesiones y las cookies en la aplicación web.
● En base al tipo de contenido, determinar las opciones de compresión del
mismo.
● Ver si existen grandes flujos de datos que deban pasar directamente entre el
cliente y el backend.
● Determinar si algunas partes de la aplicación web no deben cachearse.
● Determinar si existen redirecciones 301/302.
● Determinar si existe la necesidad de identificar la IP del cliente.
● ...
¿OTRAS CLAVES?

10. Monitorización de Varnish Cache

Monitorización de Varnish
1. Seleccionar el servidor a monitorizar (IP: E.F.G.H) e instalar el nodo de munin:
● # apt-get install munin-node
2. Seleccionar el servidor donde se van a recolectar los datos (IP: A.B.C.D) e instalar
munin (puede ser la misma máquina):
● # apt-get install munin
3. Configurar munin en el nodo y reiniciar el servicio:
● # echo allow ^A.B.C.D$ >> /etc/munin/munin-node.conf
● # service munin-node restart
4. Configurar munin en el servidor:
● Añadir al fichero /etc/munin/munin.conf
[Domain;ServerA]
address E.F.G.H
use_node_name yes
Integrar Varnish con Munin (Debian)
Munin viene, out-of-the-box, con un plugin para
generar gráficas en base al comando varnishstat

Monitorización de Varnish
1. Descargar el plugin de Varnish para Nagios:
– https://www.varnish-cache.org/utility/nagios-varnish-plugin
2. Si hubiese que explicar aquí Nagios... No acabábamos nunca...
Integrar Varnish con Nagios

11. Configuraciones Específicas para
WordPress

Configuraciones Específicas para WordPress
● Plugin para WordPress que purga/banea la cache del servidor
Varnish cuando:
✔ Hay nuevo contenido
✔ Se borra contenido
✔ Se edita contenido
WordPress Varnish as a Service
http://wordpress.org/plugins/wordpress-varnish-as-a-service

● Plugin para WordPress que genera ficheros HTML estáticos a partir
de los ficheros PHP. Ahorra una gran carga de trabajo.
● Varnish usa las cabeceras del servidor de backend para determinar
el TTL de un objeto. WP Super Cache establece el TTL por defecto
en 3 segundos, puede modificarse en
“wp-content/cache/.htaccess”.
WP Super Cache
http://wordpress.org/plugins/wp-super-cache/

● Plantillas con ejemplos de configuraciones para WordPress y varias
configuraciones para:
➢ Reescritura de URLs desde el servidor
➢ Páginas de error limpias para debugging
➢ Implementación de host virtuales
➢ Normalización de varias cabeceras
➢ Manipulación de cookies
➢ Gestión de redirecciones 301/302 con Varnish
Plantillas de Configuración de Varnish
https://github.com/mattiasgeniar/varnish-3.0-configuration-templates

● Varnish siempre incluye una cabecera X-Forwarded-For cuando
“habla” con el backend. Problemas:
➢ Debería omitirse en las peticiones normales que no sean de tipo
pass o pipe.
➢ En el caso de pass, si está presente, debería añadírse la IP del
cliente separada por una coma.
Problema con la Cabecera X-Forwarded-For
https://www.varnish-cache.org/trac/ticket/203

Conclusiones
✔ Gran rendimiento y portabilidad.
✔ Completo lenguaje propio, VCL: veloz, robusto y flexible.
✔ Balanceo de carga embebido.
✔ Registro de transacciones a coste cero: rapidísimo, completo y sin
ocupación en disco.
✔ Gestión del servicio sin downtimes.
✔ Edge Side Includes.
✔ ¡¡¡OpenSource!!! (y versión de subscripción)

Introducción a Varnish Cache

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (19)

Similar to Introducción a Varnish Cache

Similar to Introducción a Varnish Cache (20)

More from Irontec

More from Irontec (20)

Recently uploaded

Recently uploaded (16)

Introducción a Varnish Cache