Etiquetas de caché

Etiquetas de caché = dependencias de datos

Las etiquetas de caché describen las dependencias de los datos gestionados por Drupal

¿Por qué?

Las etiquetas cacheadas proporcionan una manera declarativa de rastrear qué elementos de caché dependen de ciertos datos gestionados por Drupal.

Esto es importante para un CMS/Framework como Drupal, porque el mismo contenido puede ser reutilizado de múltiples maneras. En otras palabras: es imposible saber de antemano dónde se usará cierto contenido. En cualquier lugar donde se use el contenido, puede ser cacheado. Esto significa que el mismo contenido puede ser cacheado en decenas de sitios diferentes. Lo que nos lleva a la conocida cita: en informática sólo hay dos problemas serios: invalidación de caché y nombrado. Es decir, ¿cómo invalidarás todos los elementos de caché donde se use cierto contenido?

Nota: Drupal 7 ofrece tres formas de invalidar elementos de caché: invalidar un CID específico, invalidar el uso de un prefijo CID o invalidar todo en un bin de caché. Ninguno de estos métodos permite invalidar elementos de caché que contienen una entidad modificada, porque ¡era imposible saberlo!

¿Qué es?

Una etiqueta de caché es una cadena de texto.

Las etiquetas cacheadas se pasan en conjuntos (el orden no importa) de cadenas, por lo que se representan como string[]. Son conjuntos porque un elemento de caché puede depender de muchas etiquetas de caché.

Sintaxis

Por convención, tienen la forma cosa:identificador, y cuando no existe el concepto de múltiples instancias de esa cosa, tiene la forma cosa. La única regla es que no pueden contener espacios.

No hay una sintaxis estricta.

Ejemplos:

• node:5 - etiqueta de caché para el nodo con ID 5 (se invalida cada vez que se modifica)
• user:3 - etiqueta de caché para el usuario con ID 3 (se invalida cada vez que se modifica)
• node_list - etiqueta de caché para la lista de nodos (se invalida cuando cualquier nodo es creado, actualizado o eliminado). Aplica para cualquier tipo de entidad con la forma {entity_type}_list.
• config:system.performance - etiqueta de caché para la configuración system.performance
• library_info - etiqueta de caché para las bibliotecas de recursos

Etiquetas de caché comunes

Los datos gestionados por Drupal se dividen en tres categorías:

• entidades – tienen etiquetas de caché en la forma <entity type ID>:<entity ID>, así como <entity type ID>_list y <entity type ID>_list:<bundle> para invalidar listas de entidades. Los tipos de objetos de configuración usan la etiqueta de caché del objeto base de configuración.
• configuración – tienen etiquetas de caché en la forma config:<configuration name>
• personalizado (por ejemplo, library_info)

Drupal proporciona etiquetas de caché automáticamente para entidades y configuración – véase la clase base Entity y la clase base ConfigBase. (Todos los tipos específicos de entidades y objetos de configuración heredan de estas clases.)

Aunque muchos tipos de objetos siguen el formato predecible de etiquetas <entity type ID>:<entity ID>, el código externo no debe depender de esto. En su lugar, debe obtener las etiquetas de caché para invalidar un objeto individual usando el método ::getCacheTags(), por ejemplo, $node->getCacheTags(), $user->getCacheTags(), $view->getCacheTags(), etc.

También puede ser necesario invalidar cachés basados en listas que dependen de los datos de la entidad en cuestión (por ejemplo, actualizar el HTML renderizado para un listado cuando se crea una nueva entidad para él): esto se hace con EntityTypeInterface::getListCacheTags(), que invalida cualquier etiqueta devuelta junto con las propias etiquetas del objeto. Desde Drupal 8.9 (nota de cambio), las entidades con paquetes también tienen automáticamente etiquetas de caché más específicas que incluyen su paquete, para una invalidación de listas más dirigida.

También es posible definir etiquetas de caché personalizadas y más específicas basadas en valores que tienen los objetos, por ejemplo, un campo de referencia a un término para listas que muestran objetos con un término específico. La invalidación para esas etiquetas puede ponerse en ganchos personalizados de pre-guardado/eliminación:

function yourmodule_node_presave(NodeInterface $node) {
  $tags = [];
  if ($node->hasField('field_category')) {
    foreach ($node->get('field_category') as $item) {
      $tags[] = 'mysite:node:category:' . $item->target_id;
    }
  }
  if ($tags) {
    Cache::invalidateTags($tags);
  }
}

Estas etiquetas se pueden usar en código y en vistas usando el módulo proporcionado Views Custom Cache Tag.

Nota: actualmente no existe una API para obtener etiquetas específicas de paquetes ni etiquetas más concretas de un objeto u otro objeto, porque no es el objeto quien decide qué etiquetas de caché de lista son relevantes para una lista/consulta dada, sino la propia consulta. Las futuras versiones del núcleo de Drupal probablemente mejorarán el soporte integrado de etiquetas de caché para cada paquete e integrarán, por ejemplo, en el constructor de consultas de entidades y vistas.

¿Cómo?

Configuración

Cualquier servidor de caché debe implementar CacheBackendInterface, así que al establecer un elemento de caché con ::set() se deben indicar el tercer y cuarto argumento, por ejemplo:

$cache_backend->set(
  $cid, $data, Cache::PERMANENT, ['node:5', 'user:7']
);

Esto guarda el elemento de caché con el ID $cid de forma permanente (es decir, indefinidamente), pero lo hace vulnerable a la invalidación por las etiquetas de caché node:5 o user:7.

Invalidación

Los elementos con etiquetas de caché se invalidan mediante sus etiquetas, usando cache_tags.invalidator:invalidateTags() (o cuando no se puede inyectar este servicio: Cache::invalidateTags()), que acepta un conjunto de etiquetas de caché (string[]).

Nota: esto invalida elementos marcados con dichas etiquetas en todos los bins de caché, porque no tiene sentido invalidar etiquetas de caché por separado para bins distintos, ya que los datos modificados que tienen etiquetas inválidas pueden depender de elementos cacheados en otros bins.

Depuración

Todo lo anterior es útil para depurar lo que sea que esté siendo cacheado. Pero hay otra cosa: suponga que algo se cachea con etiquetas ['foo', 'bar']. Entonces el elemento cacheado tendrá una columna de etiquetas (si suponemos brevemente que es la caché de base de datos) con el siguiente valor:

bar foo

En otras palabras:

• las etiquetas de caché están separadas por espacios
• las etiquetas de caché están ordenadas alfabéticamente

Esto facilita el análisis y depuración de cachés.

Encabezados (depuración)

Finalmente: es fácil ver de qué etiquetas de caché depende una respuesta dada (y, por tanto, se invalida) con solo mirar el encabezado X-Drupal-Cache-Tags!

(Por eso los espacios están prohibidos: porque el encabezado X-Drupal-Cache-Tags, como muchos encabezados HTTP, usa espacios para separar valores.)

Nota: Si no ve estos encabezados, debe configurar Drupal para desarrollo.

Integración con proxies inversos

En lugar de cachear respuestas en Drupal y luego invalidarlas con etiquetas de caché, también puede cachear respuestas en proxies inversos (Varnish, CDN, etc.) y luego invalidar las respuestas cacheadas usando las etiquetas de caché asociadas con esas respuestas. Para que estos proxies inversos sepan qué etiquetas de caché están asociadas con cada respuesta, puede enviar las etiquetas de caché junto con un encabezado.

Así como Drupal 8 puede enviar el encabezado X-Drupal-Cache-Tags para depuración, también puede enviar el encabezado Surrogate-Keys con valores separados por espacios, como esperan algunos CDN, o el encabezado Cache-Tag con valores separados por comas, como esperan otros CDN. Y esto también puede ser un proxy inverso que usted ejecute, no un servicio CDN comercial.

En general, se recomienda que tanto su servidor web como su proxy inverso soporten encabezados de respuesta con valores de hasta 16 KB.

1. HTTP es texto. Por lo tanto, las etiquetas cacheadas también se basan en texto. Los proxies inversos pueden representar libremente las etiquetas de caché dentro de otra estructura de datos. El límite de 16 KB se eligió basado en dos factores: A) asegurar que funciona en el 99% de los casos, B) que sea prácticamente alcanzable. Los servidores web típicos (Apache) y CDN comunes (Fastly) soportan encabezados de respuesta de 16 KB. Esto significa alrededor de 1000 etiquetas de caché, que es suficiente para el 99% de los casos.
2. La cantidad de etiquetas de caché varía mucho según el sitio y la respuesta específica. Si la respuesta depende de muchas cosas, habrá muchas etiquetas. Más de 1000 etiquetas por respuesta son raras.
3. Por supuesto, esta guía (~1000 etiquetas por respuesta) puede y evolucionará con el tiempo, a medida que A) más aplicaciones reales la usen, y B) los sistemas diseñados específicamente usen/ construyan sobre esta capacidad.

Finalmente, todo lo que esté más allá de 1000 etiquetas probablemente indica un problema más profundo: que la respuesta es demasiado compleja y debería ser dividida. No hay nada que le impida superar este número en Drupal, pero puede requerir configuración manual. Esto es aceptable para casos de uso extremadamente complejos. Puede que incluso aplique para menos de 1000 etiquetas.

Lea la documentación sobre el uso de Varnish con etiquetas de caché.

Se sabe que CDN soportan invalidación/borrado basado en etiquetas:

CloudFlare
Fastly
KeyCDN
Akamai

Caché interno de página

El uso extensivo de etiquetas de caché en Drupal 8 permite que Drupal 8 incluya el caché interno de página habilitado por defecto. Esto no es más que un proxy inverso integrado.

Véase también

• Cacheabilidad de arrays de renderizado
• Contextos de caché
• Max-age de caché