Seguimos con nuestra serie de Varnish. Ya conocemos bastante sobre este acelerador web, somos capaces de instalarlo, conocemos más o menos como funciona y ahora es hora de sacarle partido a los comandos de Varnish.
Varnish Cache es bastante flexible, ya que ofrece la posibilidad de configurar todas las etapas del proceso de la petición http con un lenguaje parecido a C. Del mismo modo y gracias a las herramientas proporcionadas por la propia herramienta , podemos monitorizar, medir el rendimiento y sobre todo controlar la tasa de aciertos (hit rate) de la memoria cache.
A veces todo esto de medir puede sernos un poco complicado, ya que por defecto los archivos de logs no se escriben en disco (por razones de rendimiento obviamente). Varnish lo que hace es almacenar/generar los logs en una memoria intermedia circular que reside en un segmento de la memoria compartida. Este buffer circular puede leerse en cualquier momento, pero pasado un tiempo los logs desaparecen. Si necesitamos guardar los logs en disco para un análisis a posteriori, es necesario que lo configuremos a tal efecto.
La mejor manera para monitorizar todo esto es usando las propias herramientas que Varnish nos proporciona:
- varnishlog: este comando muestra las peticiones que están llegando en este momento a Varnish, como los ficheros vcl podemos incluir mensajes de log, también aparecerán.
* << Request >> 12
- Begin req 11 rxreq
- Timestamp Start: 1477816777.233167 0.000000 0.000000
- Timestamp Req: 1477816777.233167 0.000000 0.000000
- ReqStart 192.168.99.1 52251
- ReqMethod GET
- ReqURL /
- ReqProtocol HTTP/1.1
- ReqHeader Host: docker.dev
- ReqHeader Connection: keep-alive
- ReqHeader Cache-Control: max-age=0
- ReqHeader Upgrade-Insecure-Requests: 1
- ReqHeader User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36
- ReqHeader Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
- ReqHeader Accept-Encoding: gzip, deflate, sdch
- ReqHeader Accept-Language: es-ES,es;q=0.8,en;q=0.6
- ReqHeader X-Forwarded-For: 192.168.99.1
- VCL_call RECV
- VCL_return hash
- ReqUnset Accept-Encoding: gzip, deflate, sdch
- ReqHeader Accept-Encoding: gzip
- VCL_call HASH
- VCL_return lookup
- Hit 3
- VCL_call HIT
- VCL_return deliver
- RespProtocol HTTP/1.1
- RespStatus 200
- RespReason OK
- RespHeader Server: nginx/1.11.1
- RespHeader Date: Sun, 30 Oct 2016 08:01:52 GMT
- RespHeader Content-Type: text/html; charset=UTF-8
- RespHeader X-Powered-By: PHP/7.0.7
- RespHeader X-Varnish: 12 3
- RespHeader Age: 2265
- RespHeader Via: 1.1 varnish-v4
- VCL_call DELIVER
- VCL_return deliver
- Timestamp Process: 1477816777.233228 0.000062 0.000062
- RespHeader Accept-Ranges: bytes
- RespHeader Content-Length: 82061
- Debug "RES_MODE 2"
- RespHeader Connection: keep-alive
- Timestamp Resp: 1477816777.233773 0.000607 0.000545
- ReqAcct 414 0 414 261 82061 82322
- End- varnishtop: Este comando muestra la distribución de la CPU dentro de los procesos de Varnish, puede utilizarse para optimizar la configuración si estamos gastando mucho tiempo en unas pocas funciones.
opt # varnishtop -1
16.00 VCL_return deliver
8.00 ReqMethod GET
8.00 VCL_call HASH
8.00 VCL_call RECV
8.00 VCL_return hash
8.00 ReqProtocol HTTP/1.1
8.00 RespProtocol HTTP/1.1
8.00 VCL_call DELIVER
8.00 VCL_return lookup
8.00 Begin sess 0 HTTP/1
...
2.00 VCL_call BACKEND_FETCH
2.00 SessClose RX_TIMEOUT 5.004
2.00 SessClose RX_TIMEOUT 5.005
2.00 ReqAcct 413 0 413 257 82059 82316
2.00 VCL_call BACKEND_RESPONSE
2.00 BackendReuse 25 boot.default
2.00 BereqHeader Host: docker.dev
2.00 BerespHeader Server: nginx/1.11.1
2.00 ObjHeader Server: nginx/1.11.1
2.00 BereqHeader Accept-Encoding: gzip
2.00 BereqHeader X-Forwarded-For: 192.168.99.1
2.00 BerespHeader Connection: keep-alive
2.00 BackendOpen 25 boot.default 172.21.0.5 8888 172.21.0.6 42042
2.00 BereqHeader Accept-Language: es-ES,es;q=0.8,en;q=0.6
2.00 BereqHeader User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.71 Safari/537.36Un par de comandos útiles podrían ser saber cuales son los «greates hits» o las URL más pedidas:
# varnishtop -i RxURLLo mismo sería interesante conocer URL que más entran al servidor
# varnishtop -i TxURL- varnishhist: Este comando muestra una gráfica por el terminal que puede servirnos para optimizar Varnish. Nos muestra en texto el histograma de distribución del tiempo en las respuestas.
- varnishstat: Nos muestra información estadística relevante, como hit rates, total cache hits, … a veces podemos utilizar la opción -j para ver la información en json
- varnishadm: Este comando nos abre un CLI con el que podemos interactuar con Varnish, enviarle comandos y ver su respuesta.
opt # varnishadm
200
-----------------------------
Varnish Cache CLI 1.0
-----------------------------
Linux,4.4.16-boot2docker,x86_64,-junix,-smalloc,-smalloc,-hcritbit
varnish-4.1.2 revision 0d7404e
Type 'help' for command list.
Type 'quit' to close CLI session.
varnish>Un comando útil comprobar la lista de backends configurados y si están activos
varnish> backend.list
200
Backend name Admin Probe
boot.default probe Healthy (no probe)Si escribimos help obtendremos la lista de comandos disponibles y con el comando quit podemos salir
¿Y todo esto funciona?
La verdad es que sí, aunque a veces da quebraderos de cabeza funciona muy bien. Para demostrarlo en el repositorio tenemos unos containers de docker configurados para tener Varnish y un nginx.
Como prueba de concepto hemos puesto un simple phpinfo() seguido de un sleep de 2 segundos. Hemos hecho 2 peticiones seguidas y como podemos ver la 2º solo ha tardado 5ms. Una velocidad impresionante.
¿Por qué usar Varnish?
Se entiende que si estamos buscando información sobre Varnish, es que tenemos muchas peticiones y la máquina ya que tenemos tiene mucha carga. Aunque bien es cierto, que no es necesario llegar al limite de carga del servidor para plantearnos usar Varnish.
- Si necesitamos liberar recursos del servidor porque esta trabajando a tope, esta opción es muy viable si tenemos un VPS y no queremos añadir «más leña».
- Si queremos balancear, es decir, repartir la carga entre varios servidores Varnish puede ayudarnos con esta tarea.
- Como ganamos mucha velocidad en el sitio web, eso nos premiará con «puntos SEO» y con una mejor experiencia de usuario.
También es cierto que todas estas mejoras tienen un precio, que no tiene por qué ser económico, sino de diseño del sitio, de la personalización, de las cookies, de los A/B Test, entonces antes de ponernos como locos a instalar Varnish y configurarlo debemos sopesar si nos compensa. Y para eso hay que poner sobre la mesa todas las variables y variantes del sitio.
Jesús L.C. - Apuntes de un aprendiz 