Varnish transforma un sitio de medios: 90% de caché de acceso, origen casi inactivo, factura del procesador dividida por tres. Luego, un editor inicia sesión, publica una solución urgente y las personas anónimas todavía ven el título anterior porque la purga solo afectó a la URL del artículo, no a la página de inicio etiquetada como "listing-news".
Este escenario ilustra la naturaleza de Varnish: no es una CDN administrada, es un motor de políticas HTTP. Escribes en VCL cuál es lo mismo, cuál es diferente y qué sucede cuando aparece una cookie session_id. Mal dominado, es el caché más rápido para servir la mala verdad.
Antes de Varnish, la pregunta no es "¿cuánta RAM?" » pero “¿un usuario que ha iniciado sesión es una variante de caché o una excepción?”
En un sitio de medios o de comercio electrónico, la respuesta varía página por página: artículo público almacenable en caché, encabezado de miembro en un fragmento privado, carrito de compras siempre omitido. Sin esta matriz escrita, la VCL se convierte en una serie de correcciones posteriores al incidente.
Modelo mental: hash, pass, miss
| Decisión VCL | Efecto |
|---|---|
retorno (hash) | Buscar/almacenar en caché |
regresar (pasar) | Origen, no ciego |
retorno (tubería) | Túnel en bruto |
retorno (sintetizador) | Respuesta sintética (mantenimiento) |
Flujo actual: consulta → vcl_recv; cookie de sesión → pasar; POST/PONER → pasar; de lo contrario → hash con clave URL + idioma + segmento anónimo; golpear → entregar; señorita → origen → TTL en vcl_backend_response.
Varnish te obliga a responder: ¿un usuario que ha iniciado sesión es una variante de caché o una excepción?
Usuarios conectados: tres patrones
Patrón 1: omisión total si hay sesión de cookies
if (req.http.Cookie ~ "PHPSESSID") {
regresar(pase);
}
Origen sencillo, seguro y más transitado para los socios.
Patrón 2: segmentación hash
Misma URL, dos entradas role=member vs anon. Riesgo: demasiadas variaciones.
Patrón 3: ESI (el lado del borde incluye)
Shell almacenable en caché más fragmento <esi:include src="/private/header"> en la pasada. Potente, complejo.
PURGE, BAN y claves sustitutas
| Operación | Alcance | Uso |
|---|---|---|
| PURGAR URL | Un objeto | Artículo modificado |
| Expresión de prohibición | Patrón | prohibición("req.url ~ /noticias/") |
| Prohibición de claves sustitutas | Etiqueta lógica | prohibición("obj.http.Surrogate-Key ~ artículo-123") |
Encabezado original: Clave-sustituta: artículo-123 listado-casa. En la publicación de CMS → prohibir la etiqueta artículo-123 más listing-home. Sin etiquetas, PURGAS a mano: olvido garantizado.
TTL, gracia y rancio
TTL: frescura nominal. Grace: ofrece una versión caducada a bajo precio: útil en su punto máximo, peligrosa en el precio de las acciones. Para comercio electrónico: gracia corta o cero en las páginas de precios.
La gracia le permite ofrecer una versión desactualizada mientras el origen es lento: útil en medios pico, peligroso en precio o stock. Documente la política por tipo de página: la publicación del blog tolera diez segundos de estancamiento; ficha de producto con stock limitado no.
Alojamiento y dimensionamiento
Varnish consume mucha RAM: planifique entre 1 y 2 GB más el tamaño del objeto de caché. En VPS: instancia dedicada si la tasa de aciertos es superior al 70 %; monitorear varnishstat - cache_hit, n_lru_nuked. Compartido: Barniz no disponible; CDN de borde parcial sin control VCL detallado. Consulte Caché de página dinámica y CDN u optimización de origen. Sin un equipo para mantener la VCL, una CDN administrada con reglas predefinidas puede ser más segura que un Varnish mal ajustado.
The Summit: Varnish premia a quienes conocen a su audiencia
Decide y avanza sin puntos ciegos
Empiece por hacer un inventario de las cookies y las rutas que siempre deben evitarse. Versione la VCL en Git y pruebe la recarga antes de cada lanzamiento. Conecte las claves sustitutas del CMS para realizar la purga sin PURGA manual. Finalmente, valide el comportamiento anónimo frente a los miembros en la página de inicio, la cuenta y la cesta, luego supervise la tasa de aciertos y prohíba los errores durante una semana.
Preguntas frecuentes
¿Varnish oculta páginas con cookies de sesión?
De forma predeterminada, no: la presencia de una cookie de sesión debería activar una omisión o un hash segmentado. Nunca proporcione una página de miembro a un visitante anónimo, incluso si la VCL parece "casi" correcta.
¿Diferencia entre paso, canalización y caché?
El modo caché almacena la respuesta. El modo Pass consulta el origen sin almacenar. El modo de tubería crea un túnel en la conexión sin formato, lo que resulta útil para flujos típicos que no son HTTP.
¿Cómo purgar después de la actualización?
Utilice PURGE o BAN específicos, o mejor, una prohibición automática de claves sustitutas del CMS en cada publicación. Evite las purgas globales que vacían todo el caché durante las horas pico.
¿Barniz delante de nginx o al revés?
La arquitectura clásica coloca Varnish en el front-end, luego nginx y luego PHP-FPM. El barniz absorbe el tráfico repetitivo; nginx administra los detalles y encabezados de la aplicación que el VCL no debe romper.
Varnish acelera lo que usted decide que sea igual; el resto es su responsabilidad de VCL, documentado y probado antes de cada gran campaña editorial.