Varnish Cache

Introducción a la instalación y despliegue de 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
2. ¿Qué es Varnish Cache?
¿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.
✔ …
4. Versiones de Varnish Cache
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
Versiones de 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 wheezy por squeeze

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.0 por
varnish-2.1
Instalación de Varnish Cache
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
Instalación de Varnish Cache
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 Es normal que al ejecutar “make check”
de uno o dos errores.
• # make install
Instalación de Varnish Cache
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.
Conceptos Teóricos Previos
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.
Conceptos Teóricos Previos
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).
Conceptos Teóricos Previos
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
Conceptos Teóricos Previos
VCL - (Varnish Configuration Language)

https://www.varnish-cache.org/docs/trunk/reference/vcl.html

• Operadores
• Condicionales
• Tipos de datos
• Expresiones regulares
• Includes
• Imports
• ...
Conceptos Teóricos Previos

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

• 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.
Conceptos Teóricos Previos

• 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.
Conceptos Teóricos Previos
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.
Conceptos Teóricos Previos
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
Conceptos Teóricos Previos
Directors

• Un director puede referenciar los backend o

definirlos inline.
• Ejemplo:
Conceptos Teóricos Previos
Directors – Random Directors

• Random 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.

Conceptos Teóricos Previos
Directors – Random Directors

• Client Director
– Escoge un backend basado en la “identity” del
cliente. Se puede establecer la variable VCL
client.identity para identificar al cliente.
– 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.

Conceptos Teóricos Previos
Directors – Random Directors

• Hash Director
– Escoge un backend en base al valor hash de la
URL. Útil para realizar balanceo de carga. Usa
el valor de req.hash.
– 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.

Conceptos Teóricos Previos
Directors – Round-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.
– Opciones Director:
●Ninguna.
– Opciones Backends:
● Ninguna.
Conceptos Teóricos Previos
Directors – DNS Director

• Puede usar los backends en modo random /

round-robin o usando .list.
– Opciones Director:
● .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.
Conceptos Teóricos Previos
Directors – DNS 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.
Conceptos Teóricos Previos
Directors – Fallback Director

• Coge el primer backend saludable. Los toma en

el orden en que se han definido.
– Opciones Director:
● Ninguna.

• Ejemplo:
Conceptos Teóricos Previos
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.
Conceptos Teóricos Previos
Health Checks – Backend Probes

• .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 \r\n
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.
Conceptos Teóricos Previos
Health Checks – Backend Probes

• .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.
Conceptos Teóricos Previos
Health Checks – Backend Probes

• Ejemplos:
Conceptos Teóricos Previos
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.
Conceptos Teóricos Previos
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.
Conceptos Teóricos Previos
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
Introducción a la Gestión Interna de Varnish Cache y sus Flujos
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.
Introducción a la Gestión Interna de Varnish Cache y sus Flujos
Máquina de Estados - Modos

• 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.
– 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.
● pipe
– Procede con el modo pipe.
Introducción a la Gestión Interna de Varnish Cache y sus Flujos
Máquina de Estados - Modos

• 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é
– 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
– 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”.
Introducción a la Gestión Interna de Varnish Cache y sus Flujos
Máquina de Estados - Modos

• hash (vcl_hash)
– Debe invocarse hash_data() sobre los datos que quieren
incorporarse al hash.
– Termina con una llamada a return() con alguna de las siguientes
palabras clave:
● hash
– Procede.
Introducción a la Gestión Interna de Varnish Cache y sus Flujos
Máquina de Estados - Modos

• hit (vcl_hit)
– Se invoca después de una búsqueda (lookup) si el documento
solicitado se encuentra en la caché.
– 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.
● 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.
Introducción a la Gestión Interna de Varnish Cache y sus Flujos
Máquina de Estados - Modos

• 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.
– 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.
● fetch
– Recupera el objeto solicitado del backend. Transmitirá el
contorl a vcl_fetch.
Introducción a la Gestión Interna de Varnish Cache y sus Flujos
Máquina de Estados - Modos

• 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:
● error code [reason]
– Devuelve un código de error al cliente y abandona la petición.
● esi
– Realiza un procesamiento ESI sobre el documento que ha sido
recuperado del backend.
● pass
– Cambia a modo pass. Transmitiá el control a vcl_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.
Introducción a la Gestión Interna de Varnish Cache y sus Flujos
Máquina de Estados - Modos

• deliver (vcl_deliver)
– Se invoca antes de que un documento sea entregado al cliente.
– 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.
● 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 al cliente.
Introducción a la Gestión Interna de Varnish Cache y sus Flujos
Máquina de Estados - Modos

• error (vcl_error)
– Se invoca cuando se encuentra un error, tanto implícita como
exlícitamente, sea por errores internos o del backend.
– Termina con una llamada a return() con alguna de las siguientes
palabras clave:
● 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 al cliente.
Introducción a la Gestión Interna de Varnish Cache y sus Flujos
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
Obtención de Estadísticas

• varnishlog
– 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
Obtención de Estadísticas

• varnishlog
Obtención de Estadísticas

• varnishhist
– Lee los registros que Varnish está generando y muestra un
histograma que se actualiza continuamente mostrando la
distribución de las últimas N peticiones.
– 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.
● -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
Obtención de Estadísticas

• varnishhist
Obtención de Estadísticas

• varnishtop
– Lee los registros que Varnish está generando y muestra una lista
actualizada con las entradas de registro más frecuentes.
– Opciones más comunes:
● -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
Obtención de Estadísticas

• varnishtop
Obtención de Estadísticas

• varnishsizes
– 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.
– Opciones más comunes:
● -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
Obtención de Estadísticas

• varnishsizes
Obtención de Estadísticas

• varnishstat
– Muestra estadísticas de la instancia de Varnish que está en
ejecución.
– Opciones más comunes:
● -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
Obtención de Estadísticas

• varnishstat
Obtención de Estadísticas

• varnishncsa
– Lee los registros generados por Varnish en memoria en el
formato de registro “combined” Apache/NCSA.
– Opciones más comunes:
● -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.
Configuración de Varnish Cache
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.
Configuración de Varnish Cache
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.
Configuración de Varnish Cache
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.
Configuración de Varnish Cache
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
Configuración de Varnish Cache
Varnish Configuration Language

● Repasemos un poco VCL:

● Ejemplos:
Configuración de Varnish Cache
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/
Configuración de Varnish Cache
Lograr un Ratio Elevado de Hits

• 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
Configuración de Varnish Cache
Lograr un Ratio Elevado de Hits

• Otras opciones para incrementar el ratio de hits:

– Incrementar el TTL

– Forzar el cacheo de ciertas peticiones y

respuestas (NO RECOMENDADO)
– Normalizar el namespace
Configuración de Varnish Cache
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.

Para muchas aplicaciones web

pueden descartarse completamente
las cookies salvo para
determinadas secciones.

MUY CONSERVATIVO
Configuración de Varnish Cache
Cookies

• Del cliente:
cliente
Configuración de Varnish Cache
Cookies

• Del servidor de backend:

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.
Configuración de Varnish Cache
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 Normalizar con VCL la cabecera Accept-Encoding de manera que haya tan
mantendrá una variante diferente de la pocas variantes como sea posible. El ejemplo comprueba si el cliente acepta
página por cada uno de ellos. gzip, en cuyo caso prevalece, si no deflate.
Configuración de Varnish Cache
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
Configuración de Varnish Cache
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é.
Configuración de Varnish Cache
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
– <!--esi ... -->

http://www.akamai.com/html/support/esi.html
Configuración de Varnish Cache
ESI (Edge Side Includes)

• Ejemplo:

• Ejemplo:
Configuración de Varnish Cache
Detección de Dispositivo

• 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.

https://github.com/varnish/varnish-devicedetect/
Configuración de Varnish Cache
Detección de Dispositivo

• Ejemplo:
Establecemos la cabecera.

• 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.
Configuración de Varnish Cache
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/
Configuración de Varnish Cache
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
Configuración de Varnish Cache
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.
● ¿OTRAS
Determinar CLAVES?
si existen redirecciones 301/302.
● Determinar si existe la necesidad de identificar la IP del cliente.
● ...
10. Monitorización de Varnish Cache
Monitorización de Varnish
Integrar Varnish con Munin (Debian)

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

Munin viene, out-of-the-box, con un plugin para

generar gráficas en base al comando varnishstat
Monitorización de Varnish
Integrar Varnish con Nagios

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...
11. Configuraciones Específicas para
WordPress
Configuraciones Específicas para WordPress
WordPress Varnish as a Service

● Plugin para WordPress que purga/banea la cache del servidor

Varnish cuando:
✔ Hay nuevo contenido
✔ Se borra contenido
✔ Se edita contenido

http://wordpress.org/plugins/wordpress-varnish-as-a-service
Configuraciones Específicas para WordPress
WP Super Cache

● 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”.

http://wordpress.org/plugins/wp-super-cache/
Configuraciones Específicas para WordPress
Plantillas de Configuración de Varnish

● 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

https://github.com/mattiasgeniar/varnish-3.0-configuration-templates
Configuraciones Específicas para WordPress
Problema con la Cabecera X-Forwarded-For

● 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.

https://www.varnish-cache.org/trac/ticket/203
12. Conclusiones
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)
Gracias por vuestra atención