Cómo utilizar Varnish para acelerar mi sitio web

Debido a que la caché de Symfony2 utiliza las cabeceras de caché HTTP estándar, el Delegado inverso de Symfony2 se puede sustituir fácilmente por cualquier otro delegado inverso. Varnish es un potente acelerador HTTP, de código abierto, capaz de servir contenido almacenado en caché de forma rápida y es compatible con Inclusión del borde lateral.

Configurando

Como vimos anteriormente, Symfony2 es lo suficientemente inteligente como para detectar si está hablando con un delegado inverso que entiende ESI o no. Funciona fuera de la caja cuando utilizas el delegado inverso de Symfony2, pero necesita una configuración especial para que funcione con Varnish. Afortunadamente, Symfony2 se basa en otra norma escrita por Akamaï (Arquitectura límite), por lo que el consejo de configuración en este capítulo te puede ser útil incluso si no utilizas Symfony2.

Nota

Varnish sólo admite el atributo src para las etiquetas ESI (los atributos onerror y alt se omiten).

En primer lugar, configura Varnish para que anuncie su apoyo a ESI añadiendo una cabecera Surrogate-Capability a las peticiones remitidas a la interfaz administrativa de tu aplicación:

sub vcl_recv {
    set req.http.Surrogate-Capability = "abc=ESI/1.0";
}

Entonces, optimiza Varnish para que sólo analice el contenido de la respuesta cuando al menos hay una etiqueta ESI comprobando la cabecera Surrogate-Control que Symfony2 añade automáticamente:

sub vcl_fetch {
    if (beresp.http.Surrogate-Control ~ "ESI/1.0") {
        unset beresp.http.Surrogate-Control;

        // para Varnish >= 3.0
        set beresp.do_esi = true;
        // para Varnish < 3.0
        // esi;
    }
}

Prudencia

La compresión con ESI no cuenta con el apoyo de Varnish hasta la versión 3.0 (lee GZIP y Varnish). Si no estás utilizando Varnish 3.0, coloca un servidor web frente a Varnish para llevar a cabo la compresión.

Invalidando la caché

Nunca debería ser necesario invalidar los datos almacenados en caché porque la invalidación ya se tiene en cuenta de forma nativa en los modelos de caché HTTP (consulta Invalidando la caché).

Sin embargo, Varnish se puede configurar para aceptar un método HTTP especial PURGE que invalida la caché para un determinado recurso:

sub vcl_hit {
    if (req.request == "PURGE") {
        set obj.ttl = 0s;
        error 200 "Purged";
    }
}

sub vcl_miss {
    if (req.request == "PURGE") {
        error 404 "Not purged";
    }
}

Prudencia

De alguna manera, debes proteger el método PURGE de HTTP para evitar que alguien aleatoriamente purgue los datos memorizados.

Bifúrcame en GitHub