Dándole una vuelta de tuerca más a las optimizaciones para WordPress, podemos querer instalar también al gran Varnish para el cacheado de front, y así seguir rascando esos milisegundos en la velocidad de la web.
Este post es una continuación del post anterior sobre el cacheado de back, en este caso con un sistema de cacheado de front. Esto es un howto o tutorial para instalar Varnish, y una review de un plugin para WordPress que funciona muy bien, el Purge Varnish Cache.
Un poco de teoría
Varnish es un proxy inverso, que se pone entre el servidor que procesa las visitas, y el navegador de los visitantes. Una vez configurado, se encargará de devolver los contenidos que almacenará en memoria RAM muy rápido. Las primeras cargas serán a velocidad normal, pero según se repitan visitas a contenidos cacheados en Varnish, se aumentará mucho la velocidad.
Varnish almacena en RAM los contenidos ya procesados de ficheros de estilo, JavaScript, HTML, imágenes.. Sirve para contenidos completos o también puede dividir las páginas en bloques.
Dispone de un lenguaje de programación propio llamado VCL, con el que se definirá su comportamiento. Si queremos el máximo rendimiento, también se pueden programar las plantillas para usar los ESI blocks de Varnish.
Instalando Varnish
Para instalarlo en servidores con APT bastaría con ejecutar lo siguiente:
sudo apt install varnishEsto dejaría una configuración por defecto escuchando en el puerto 6081 para cachear, y en el puerto 6082 para para el terminal de control de Varnish.
Para el caso de Apache hay que configurar los módulos de proxy:
sudo a2enmod proxy proxy_httpEn las configuraciones de puertos para Apache luego las cito.
Varnish necesita de una forma de configuración extra para el caso de querer ponerle HTTPS con su certificado SSL delante. Esto es así porque Varnish no es compatible con los certificados SSL, pero la forma de implementarlo es simplemente poner delante al servidor web.
Cómo enlazar Apache y Varnish
Para el caso de este post, la idea a seguir, es que las peticiones de los visitantes van a seguir estas capas:
- Petición desde el navegador a Apache en el puerto 80, hace de proxy inverso en dirección a Varnish, es decir Apache escucha en el puerto 80 y redirige al 6081 donde está Varnish.
- Varnish escucha en el puerto 6081 cacheando las peticiones que corresponda, redirige (o más bien hace las peticiones) al puerto 8080 en donde está escuchando Apache de nuevo procesando WordPress.
- Apache escucha en el puerto 8080, en donde procesa WordPress, ejecuta PHP con la configuración que tenga, Redis si lo tiene, etc.. devolviendo a Varnish los resultados.
Por temas de seguridad, conviene cerrar los puertos 6081 y 6082 al exterior, o sólo dejarlos accesibles a los servidores del sistema informático de la aplicación.
Configurando un host virtual de Apache con Varnish
Lo siguiente es configurar es este sistema de proxys de Apache + Varnish. Con un host virtual que tengo aquí de pruebas, se podría hacer lo que cito en el apartado anterior, con algo parecido a lo siguiente:
<VirtualHost *:80>
ServerName work-wordpress.local
ProxyPreserveHost On
ProxyPass / http://www.eldominiodetuhost.com:6081/
ProxyPassReverse / http://www.eldominiodetuhost.com:6081/
</VirtualHost>
<VirtualHost *:8080>
DocumentRoot "/home/usuario_host/public_html/"
ServerName www.eldominiodetuhost.com
<Directory "/home/usuario_host/public_html/">
Options Indexes FollowSymLinks ExecCGI Includes
AllowOverride All
Require all granted
</Directory>
<FilesMatch \.php$>
# Apache 2.4.10+ can proxy to unix socket
SetHandler "proxy:unix:/var/run/php/php7.3-fpm.sock|fcgi://localhost/"
</FilesMatch>
</VirtualHost>Simplemente hace una redirección del puerto 80 de Apache al 6081 de Varnish. A su vez, hay que configurar Varnish para que haga las consultas a Apache de nuevo al puerto 8080. Con algo parecido a lo siguiente en su fichero de configuración /etc/varnish/default.vlc quedaría hecho:
backend server1 {
.host = "127.0.0.1";
.port = "8080";
}Hasta este punto, si todo ha ido bien, se debe de poder navegar en la web. Hay que ir reiniciando Varnish y Apache para aplicar las configuraciones.
Ahora mismo, si reinciamos Varnish y Apache ya debería de poderse navegar en el puerto 80, el por defecto de la web. Pero hasta aquí todavía Varnish no empezará a cachear, necesitará de las siguientes configuraciones..
Instalando Purge Varnish Cache en WordPress
Lo siguiente entonces es configurar WordPress para que maneje la purga de los contenidos que tienen que actualizarse en la caché de Varnish. Esto es necesario, porque de lo contrario, Varnish devolvería continuamente contenidos sin actualizar cuando no corresponde. O simplemente ni siguiera cachearía si no está bien configurado.
Conviene entonces no cachear el backend de administración, cuando se producen comentarios flushear, en las actualizaciones de los posts, etcétera..
Estas cosas con Purge Varnish Cache se puede hacer sin demasiadas configuraciones. Hay que poner las configuraciones de donde está el servidor de Varnish, y el secreto que está en el fichero /etc/varnish/secret .
Configurando el comportamiento de cacheado de Varnish
Dentro del directorio del plugin anterior hay ficheros de configuración de Varnish para las versiones 3, 4 y 5. He encontrado esta configuración siguiente y funciona bien con Varnish 6:
https://gist.github.com/fevangelou/84d2ce05896cab5f730a
Ahora podremos copiar los ficheros de:
wp-content/plugins/purge-varnish/vcl/3.x
wp-content/plugins/purge-varnish/vcl/4.x
wp-content/plugins/purge-varnish/vcl/5.x
..a los directorios de configuración.
Ya sólo queda ponernos a programar en VCL dichos ficheros o configurar el plugin. Si todo va bien tenemos que ver inspeccionando la web, en la sección de la red, que los contenidos se van cacheando y tienen una edad (Age) en las cabeceras de respuesta. Como en la imagen siguiente:
Si miramos los tiempos, cuando el fichero pedido no está cacheado tardará lo normal de siempre. Pero cuando el fichero ya está cacheado en Varnish veremos que la respuesta del servidor se devuelve directamente por Varnish muchísimo más rápido. Una respuesta cacheada es mucho más rápido porque ni siquiera tiene que procesar el PHP, ni hacer consultas a la base de datos.
Por ejemplo en la imagen de pruebas anterior, si nos fijamos en las cabeceras de la respuesta de /, la petición ha hecho HIT, que quiere decir que la página estaba cacheada, ha hecho hit 3 veces en concreto, y está cacheado en Varnish con una edad de 20 segundos, por eso la cabecera de la respuesta Age: 20.
