Varnish-Request

Probablemente muchos de los que están leyendo este artículo se han dado cuenta que en ocasiones WordPress puede ser lento. Con cada solicitud tienen que leerse miles de líneas de código y varias consultas SQL para presentar una página. Una de las configuraciones más populares para un sitio de WordPress es Apache, mod_rewrite, mod_php, PHP y MySQL. Ciertamente es una muy buena configuración, pero no se puede considerar la más rápida (al menos sin ningún ajuste adicional).

La buena noticia es que WordPress no tiene que ser un demonio de la velocidad. En la mayoría de los casos es sólo un CMS para producir páginas estáticas. Si el contenido es estático, no tiene ningún sentido perder ciclos de CPU para volver a presentar el mismo HTML una y otra vez.

En este artículo vamos a explicar como implementar un recurso conocido como el Varnish caché que puede mejorar significativamente la velocidad de nuestro sitio web o blog de WordPress.

Así que ¿Porqué es importante que un sitio web sea rápido? Hay por lo menos 3 razones:

– Para sobrevivir los picos de tráfico repentinos que son una de las mayores causas de caídas de sitios.

– Mejor ranking en Google

– Según la investigación de Google existe una correlación entre el tiempo de respuesta del sitio web y el contenido visitado. En otras palabras, el sitio web más rápido es el que presenta mayores probabilidades de recibir otro clic y de realizar ventas de productos.

El Varnish caché es un acelerador de aplicaciones web también conocido como un proxy inverso HTTP de almacenamiento en caché. Se instala frente a cualquier servidor de tipo HTTP y se configura para almacenar el contenido en el caché. El Varnish caché es muy, muy rápido. Por lo general acelera la entrega de contenido con un factor de 300 – 1000x, dependiendo de la arquitectura.

Procedimiento para utilizar el Varnish caché en WordPress

Varnish se mantiene delante de un servidor web lo que significa que tendrá que escuchar en el puerto 80. Por defecto este puerto ya está tomado por Apache. Lo primero es cambiar la configuración de su servidor web.

$ vim /etc/apache2/ports.conf

Luego hay que cambiar el puerto 80 al puerto 8080.

NameVirtualHost *:8080
Listen 8080
<IfModule mod_ssl.c>
    Listen 443
</IfModule>
<IfModule mod_gnutls.c>
    Listen 443
</IfModule>

A continuación se edita la configuración de la máquina virtual.

$ vim /etc/apache2/sitesavailable/architect

Finalmente alteramos el puerto de 80 a 8080.

<VirtualHost *:8080>

Ahora instalamos Varnish. Dependiendo de la distribución es posible obtener una versión diferente del software. Este artículo fue creado para el uso de Varnish 3.x.

$ aptget install varnish
$ varnishd V
varnishd (varnish3.0.2 revision cbf1284)
Copyright (c) 2006 Verdens Gang AS
Copyright (c) 20062011 Varnish Software AS

Una vez que está instalado, se edita la configuración de Varnish y se establece el puerto y el tamaño del caché.

$ vim /etc/default/varnish

La memoria en mi servidor es limitada, así que utilizo sólo 64 MB. El valor por defecto es 254, pero un cuarto de ese valor es suficiente para un pequeño blog.

DAEMON_OPTS=«-a :80 \
                              -T localhost:6082 \
                              -f /etc/varnish/default.vcl \
                              -S /etc/varnish/secret \
                              -s malloc,64m»

Posteriormente editamos la configuración de Varnish.

$ vim /etc/varnish/default.vcl

Cambiamos el script VLC a:

backend default {
    .host = «127.0.0.1»;
    .port = «8080»;
}

sub vcl_recv {
    if (req.restarts == 0) {
        if (req.http.xforwardedfor) {
            set req.http.XForwardedFor =
            req.http.XForwardedFor + «, « + client.ip;
        } else {
            set req.http.XForwardedFor = client.ip;
        }
    }
    if (req.request == «PURGE») {
        if ( client.ip != «54.276.48.25») {
            error 405 «Not allowed.»;
        }
        return (lookup);
    }
    if (req.request != «GET» &&
        req.request != «HEAD» &&
        req.request != «PUT» &&
        req.request != «POST» &&
        req.request != «TRACE» &&
        req.request != «OPTIONS» &&
        req.request != «DELETE») {
            return (pipe);
    }
    if (req.request != «GET» && req.request != «HEAD») {
        return (pass);
    }
    if (!(req.url ~ «wp-(login|admin)») &&
        !(req.url ~ «&preview=true» ) ) {
        unset req.http.cookie;
    }

    if (req.http.Authorization || req.http.Cookie) {
        return (pass);
    }
    return (lookup);
}

sub vcl_hit {
    if (req.request == «PURGE») {
        purge;
        error 200 «Purged.»;
    }
    return (deliver);
}

sub vcl_miss {
    if (req.request == «PURGE») {
        purge;
        error 200 «Purged.»;
    }
    return (fetch);
}

sub vcl_fetch {
    if (!(req.url ~ «wp-(login|admin)»)) {
        unset beresp.http.setcookie;
        set beresp.ttl = 96h;
    }

    if (beresp.ttl <= 0s ||
        beresp.http.SetCookie ||
        beresp.http.Vary == «*») {
            set beresp.ttl = 120 s;
            return (hit_for_pass);
    }
    return (deliver);
}

En este caso tendrán que cambiar la IP 54.276.48.25 a la dirección de su servidor. Una vez que todo esté instalado y configurado correctamente lo que falta es reiniciar el servidor.

$ sudo /etc/init.d/apache2 restart
$ sudo /etc/init.d/varnish restart

Para asegurarse de que el almacenamiento en caché está trabajando ejecute el comando tail contra todos los logs de apache y actualice su sitio web algunas veces.

$ tail f /var/log/apache2/*

La primera solicitud llegará al servidor Apache y debería ver las nuevas entradas en el registro. Varnish pondrá todos los recursos para esa URL en la memoria caché. Cada petición siguiente no debería ser incluida en los nuevos registros.

La configuración VCL crea el Varnish caché en cada solicitud GET durante 96 horas. Hay una excepción para wp-login y wp-admin. Esas son páginas dinámicas y es mejor que queden almacenadas en la memoria caché. Los visitantes del sitio no tienen ninguna razón para ir allí de todos modos.

De esta manera, Varnish va a guardar todo en una memoria caché por 96 horas. Si crea un nuevo artículo o edita uno ya existente los cambios no serán visibles. Varnish no sabe que algo ha cambiado y seguirá sirviendo contenido obsoleto. Sin embargo, el usuario puede reiniciar el servicio para limpiar todos los datos.

$ /etc/init.d/varnish restart

No es el enfoque más fácil de usar. También borra más de lo que debería. No hay que preocuparse, es WordPress. Hay plugins para todo. Podemos instalar la extensión «Varnish HTTP Purge«. No se requiere ninguna configuración. El archivo Default.vcl maneja las solicitudes de purga.