Comandos para manejar Varnish

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.

16636213747_326548d6a8_z
shellac surgeon (Todd F Niemand)

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

Un par de comandos útiles podrían ser saber cuales son los “greates hits” o las URL más pedidas:

# varnishtop -i RxURL

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

captura-de-pantalla-2016-11-01-a-las-20-07-19

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.

Anuncios

Comenta la entrada

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s