Tag di cache
Tag di cache = dipendenze dai dati
I tag di cache descrivono le dipendenze dai dati gestiti da Drupal
Perché?
I tag di cache forniscono un modo dichiarativo per tenere traccia di quali elementi della cache dipendono da determinati dati gestiti da Drupal.
Questo è importante per un CMS/Framework come Drupal, perché lo stesso contenuto può essere riutilizzato in modi diversi. In altre parole: è impossibile sapere in anticipo dove verrà utilizzato un certo contenuto. Ovunque venga utilizzato, può essere messo in cache. Ciò significa che lo stesso contenuto può essere memorizzato in cache in decine di luoghi diversi. Il che ci porta alla famosa citazione: in informatica ci sono solo due problemi difficili — invalidare la cache e dare i nomi. Ovvero: come invalidare tutti gli elementi di cache che contengono quel contenuto?
Nota: Drupal 7 offre 3 modi per invalidare gli elementi di cache: invalidare un determinato CID, invalidare usando un prefisso CID o invalidare tutto in un bin della cache. Nessuno di questi tre metodi ci permetteva di invalidare gli elementi di cache che contenevano un'entità modificata, perché non era possibile saperlo!
Cosa?
Un tag di cache è una stringa.
I tag di cache vengono passati come insiemi (l’ordine non conta) di stringhe, quindi sono stampati come string[]. Sono insiemi perché un singolo elemento di cache può dipendere da molti tag di cache.
Sintassi
Per convenzione, hanno la forma thing:identifier — e quando non esiste il concetto di più istanze di una cosa, hanno la forma thing. L’unica regola è che non può contenere spazi.
Non esiste una sintassi stretta.
Esempi:
- node:5 — tag di cache per il nodo 5 (invalidato ogni volta che cambia)
- user:3 — tag di cache per l’utente 3 (invalidato ogni volta che cambia)
- node_list — tag di cache per la lista dei nodi (invalidato ogni volta che un nodo viene aggiornato, eliminato o creato). Valido per qualsiasi tipo di entità: {entity_type}_list.
- config:system.performance — tag di cache per la configurazione system.performance
- library_info — tag di cache per le librerie di asset
Tag di cache comuni
I dati gestiti da Drupal rientrano in 3 categorie:
- entities — hanno tag di cache nella forma <entity type ID>:<entity ID>, oltre a <entity type ID>_list e <entity type ID>_list:<bundle> per invalidare le liste di entità. Gli entity type di configurazione usano il tag di cache dell’oggetto di configurazione base.
- configuration — hanno tag di cache nella forma config:<configuration name>
- custom — ad esempio library_info
Drupal fornisce automaticamente tag di cache per entità e configurazioni — vedi classe base Entity e classe base ConfigBase. (Tutti i tipi di entità e oggetti di configurazione estendono questi.)
Potrebbe anche essere necessario invalidare le cache basate su liste che dipendono dai dati di una determinata entità (ad esempio aggiornare un HTML renderizzato di una lista quando viene creata una nuova entità per essa): questo si può fare con EntityTypeInterface::getListCacheTags(). Da Drupal 8.9 (change record), le entità con bundle hanno anche tag di cache più specifici.
È anche possibile definire tag di cache custom, più specifici, basati su valori negli oggetti, ad esempio un campo reference a un termine per liste che mostrano oggetti legati a quel termine. L’invalidazione per tali tag può essere fatta negli hook presave/delete:
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);
}
}
Questi tag possono essere usati anche nelle Views con il modulo Views Custom Cache Tag.
Nota: al momento non esiste un API per ottenere i tag di cache bundle-specific o più granulari da un oggetto. Questo perché dipende dalla query o dalla lista, non dall’oggetto stesso. Futuri aggiornamenti di Drupal probabilmente miglioreranno il supporto.
Come
Impostazione
Qualsiasi backend di cache deve implementare CacheBackendInterface, quindi quando imposti un elemento con ::set() puoi passare i tag come quarto argomento:
$cache_backend->set( $cid, $data, Cache::PERMANENT, ['node:5', 'user:7'] );
In questo esempio, l’elemento viene salvato permanentemente, ma invalidato se node:5 o user:7 vengono modificati.
Invalidazione
Gli elementi di cache possono essere invalidati tramite i loro tag con cache_tags.invalidator:invalidateTags() (o Cache::invalidateTags() se non puoi iniettare il servizio). Questo accetta un array di stringhe (tag).
Nota: invalida gli elementi marcati con quei tag in tutti i bin di cache, perché ha senso invalidare i dati in ogni posto in cui sono stati usati.
Debug
Supponiamo che qualcosa sia memorizzato in cache con i tag ['foo', 'bar']. L’elemento avrà i suoi tag memorizzati (ad esempio nel database) come:
bar foo
- i tag di cache sono separati da spazi
- i tag di cache sono ordinati alfabeticamente
Questo rende più facile analizzare e fare debug!
Header (debug)
Puoi facilmente vedere da quali tag di cache dipende una risposta guardando l’header X-Drupal-Cache-Tags.
(Ecco perché gli spazi sono proibiti: perché l’header usa spazi per separare i valori.)
Nota: se non vedi questi header, devi configurare Drupal in modalità sviluppo.
Integrazione con reverse proxy
Invece di memorizzare in cache le risposte in Drupal, puoi farlo in reverse proxy (Varnish, CDN, …) e invalidare usando i tag di cache associati a quelle risposte. Per far sì che i proxy sappiano i tag associati, Drupal invia gli header di risposta con i tag.
Drupal 8 può inviare X-Drupal-Cache-Tags per debug, ma può anche inviare header come Surrogate-Keys (con valori separati da spazi) per Fastly o Cache-Tag (con valori separati da virgole) per Cloudflare e altri CDN.
Si raccomanda che il tuo web server e proxy supportino header fino a 16 KB di valori.
1. HTTP è testuale. I tag di cache quindi sono testuali. I proxy possono rappresentarli in strutture dati diverse. Il limite di 16 KB è stato scelto perché realistico e supportato da Apache e CDN come Fastly. Circa 1000 tag di cache = sufficiente nel 99% dei casi.
2. Il numero di tag di cache varia molto a seconda del sito e della risposta. Più dipendenze = più tag. Oltre 1000 è raro.
3. Oltre 1000 tag di cache indica di solito un problema architetturale: la risposta è troppo complessa e andrebbe spezzata. Drupal non vieta di superare quel numero, ma può richiedere configurazioni manuali.
Leggi la documentazione su usare Varnish con i tag di cache.
CDN che supportano invalidazione basata su tag:
CloudFlare
Fastly
KeyCDN
Akamai
Cache interna delle pagine
L’uso esteso dei tag di cache in Drupal 8 permette di avere attivata di default la cache interna delle pagine, che funziona come un reverse proxy integrato.