Come si scopre perché una pagina Drupal non è andata in cache?

Si legge il motivo che Drupal stesso scrive sulla risposta, a patto di averlo conservato. La page cache e la dynamic page cache scrivono il loro esito nelle intestazioni X-Drupal-Cache e X-Drupal-Dynamic-Cache: HIT, MISS oppure UNCACHEABLE con la regola che l'ha deciso fra parentesi. Quelle intestazioni arrivano al browser e lì finiscono. Il giorno dopo, quando qualcuno chiede perché una pagina era lenta, la risposta è già persa.

Native Observability è un modulo Drupal che registra dall'interno che cosa succede a ogni richiesta. Il sottomodulo Cache Observer, native_observability_cache_observer, salva nel database l'esito di ogni strato di cache, i metadati di cacheabilità della risposta e le invalidazioni di tag, legati alla rotta e alla traccia della stessa richiesta. Le query lente della stessa richiesta sono nell'articolo sulle query che rallentano una rotta, le chiamate verso servizi esterni in quello sul servizio esterno che rallenta una rotta.

Le righe riportate qui vengono da un ambiente di misura che ho costruito io, con Drupal 11.4.5 in DDEV. Come rifarlo sta in fondo, nella sezione «Come rifare la misura».

Che cosa registra Cache Observer per ogni richiesta

Tre tipi di evento, ognuno nella tabella native_observability_cache_event con l'identificativo della richiesta che l'ha prodotto.

I metadati di cacheabilità vengono letti dalla risposta, dagli stessi dati da cui core ricava i debug header. Il parametro http.response.debug_cacheability_headers resta quindi a false, come chiede il commento di default.services.yml: «Enabling cacheability debugging is not recommended in production environments». Tutte le prove di questa pagina sono state fatte con quel parametro spento.

Una pagina che non va in cache: le tre righe che lo spiegano

Una GET /node/XXX/edit fatta da un utente autenticato lascia tre righe con lo stesso identificativo di richiesta, XXXXXXXXXXXXXXXXXXXXXXMJ7M, e la stessa rotta, entity.node.edit_form:

Ogni etichetta corrisponde a una regola precisa del core.

• REQUEST POLICY sulla page cache: la richiesta ha una sessione. La page cache serve solo gli

anonimi, e la decisione avviene prima ancora di cercare la pagina.

• POOR CACHEABILITY sulla dynamic page cache: la risposta rientra in una delle

auto_placeholder_conditions di renderer.config. Il metodo shouldCacheResponse() la scarta quando il max-age è 0, quando c'è un contesto ad alta cardinalità come user o session, oppure un tag che si invalida troppo spesso.

• La riga di cacheabilità dice quale delle tre condizioni è scattata: max-age 0. Nel campo

payload ci sono anche i nomi, fra cui i contesti user e session.exists.

Altri due esiti visti nella stessa misura completano il quadro. user.reset.login, il link di accesso monouso, dà UNCACHEABLE (RESPONSE POLICY): la pagina è stata prodotta, e una regola sulla risposta ne ha impedito il salvataggio. Una risposta che non porta metadati di cacheabilità dà UNCACHEABLE (NO CACHEABILITY) su entrambi gli strati.

Il HIT della page cache, che Drupal non vede

Una pagina servita dalla page cache viene registrata anche se Drupal non l'ha mai gestita. La page cache è il middleware http_middleware.page_cache, a priorità 200, e su un HIT restituisce la risposta salvata prima che il kernel HTTP parta: niente routing, niente kernel.response, niente kernel.terminate. Per il resto di Drupal quella richiesta non è esistita.

Cache Observer si mette sopra, con un middleware a priorità 210, CachePageObserverMiddleware, legge X-Drupal-Cache sulla risposta che torna indietro e scrive la riga. Visto che il kernel non ha assegnato un identificativo, lo conia il middleware e lo mette sulla risposta in X-Native-Observability-Request-Id.

Due richieste anonime alla stessa pagina, una dopo l'altra:

a1.txt:x-drupal-cache: MISS
a1.txt:x-native-observability-request-id: XXXXXXXXXXXXXXXXXXXXXXP9EJ
a2.txt:x-drupal-cache: HIT
a2.txt:x-native-observability-request-id: XXXXXXXXXXXXXXXXXXXXXXP40A

E nel database, con il numero di righe di traccia che ogni identificativo ritrova:

id    request_id                  status  path                                 route_name             trace_rows
XXXX  XXXXXXXXXXXXXXXXXXXXXXP9EJ  MISS    /review/what-changed-in-drupal-11-4  entity.node.canonical  1
XXXX  XXXXXXXXXXXXXXXXXXXXXXP40A  HIT     /review/what-changed-in-drupal-11-4                         0

Il HIT ha zero righe di traccia e la rotta vuota, ed è la risposta esatta: Drupal non ha instradato quella richiesta e non l'ha tracciata. Per un HIT il dato che resta è il percorso. Contare i HIT di una pagina si fa quindi per path, perché route_name c'è solo sulle richieste arrivate al kernel.

L'identificativo di un'altra richiesta, dentro una risposta in cache

La page cache salva la risposta intera, intestazioni comprese. Un sito che aggiunge a ogni risposta un identificativo di correlazione, per ritrovare la richiesta nei log, se lo ritrova salvato insieme alla pagina: al secondo visitatore arriva l'identificativo del primo. Cercandolo nei log si trova la richiesta di un'altra persona, magari di ore prima.

Cache Observer lo toglie. Il middleware riconosce una risposta servita dalla cache dall'assenza dell'attributo che il kernel mette su ogni richiesta gestita, rimuove l'intestazione vecchia e scrive quella nuova. Le due richieste qui sopra lo mostrano: identificativi diversi, uno per richiesta.

Lo stesso effetto tocca un'intestazione di core. Sul HIT la risposta riporta ancora x-drupal-dynamic-cache: MISS, che è l'esito della dynamic page cache per la richiesta che ha riempito la page cache. Su un HIT la dynamic page cache non ha lavorato affatto. Chi legge le intestazioni a mano per capire la cache di una pagina anonima deve saperlo: su un HIT della page cache, X-Drupal-Dynamic-Cache descrive un'altra richiesta.

Quale invalidazione ha svuotato la pagina

Cache Observer affianca agli invalidatori di core un suo invalidatore, ObservedCacheTagsInvalidator, che per ogni chiamata a invalidateTags() scrive una riga con i tag e la richiesta che li ha invalidati. Salvando un nodo dal form, lo stesso POST produce queste righe:

tag_count  tags
1          node:XXX:revisions
4          node_list, node_list:article, 4xx-response, node:XXX
1          native_observability_trace:list

La seconda riga è quella che spiega perché le liste di articoli e la pagina del nodo sono state ricostruite alla visita successiva. La terza è del modulo stesso, e se ne parla fra i limiti.

Le invalidazioni hanno un tetto per richiesta, max_stored_invalidations_per_request, 50 di default. Il tetto conta le chiamate, non i tag, e tiene le prime: l'invalidazione avviene sempre, si ferma solo la registrazione. Lo stesso salvataggio con il tetto a 1 e a 50:

Con il tetto a 1 sono spariti proprio node:XXX e node_list, cioè i tag utili.

Il totale vero non viene registrato da nessuna parte. Per le query lente il modulo conserva anche quante ne ha viste, e il confronto fra righe salvate e righe viste prova la troncatura. Per le invalidazioni quel confronto manca. L'unico indizio è una richiesta con esattamente tante righe quante ne consente il tetto, e la prova si ottiene soltanto rifacendo la misura con un tetto più alto. È un limite di Cache Observer, e lo scrivo qui invece di lasciarlo scoprire a chi ci si affida.

I limiti di Cache Observer

Ognuno è stato osservato nella stessa misura.

• Un POST lascia solo la riga di cacheabilità. Il core mette X-Drupal-Cache soltanto sulle

richieste con metodo cacheabile, come prescrive la RFC 7231 §4.2.3, e senza intestazione il middleware non scrive la riga della page cache.

• CACHEABLE è la cacheabilità dichiarata. L'etichetta della riga di cacheabilità guarda

soltanto tag, contesti e max-age. Un POST sul form di login esce CACHEABLE, benché un POST resti sempre fuori dalla cache. L'esito vero sta nelle righe response_cache.

• Il HIT ha il percorso e la rotta vuota, per il motivo spiegato sopra.
• Le invalidazioni da drush e da cron lanciato da riga di comando restano fuori. L'invalidatore

scrive solo quando la richiesta corrente ha un identificativo di correlazione, e sotto drush quella richiesta è sintetica e l'identificativo manca. Un drush cr svuota tutto e lascia la tabella com'era.

• Il modulo registra le proprie invalidazioni. Ogni richiesta che scrive una traccia invalida

native_observability_trace:list, e quella chiamata finisce in tabella come le altre: nella misura erano 8 righe di invalidazione su 12. Con un tetto basso occupano posti che spetterebbero ai tag del sito.

• Il tetto sulle invalidazioni taglia in silenzio, come descritto nella sezione precedente.

Confronto con gli altri strumenti

Ognuno risponde a una domanda diversa. La tabella riporta quello che ogni progetto dichiara sulla sua pagina: gli altri strumenti non sono stati provati nell'ambiente di misura.

I debug header e WebProfiler servono quando la pagina è davanti a te. I moduli di log sulle invalidazioni servono quando la domanda è solo «chi ha svuotato la cache». Nessuno dei primi cinque registra i HIT della page cache, che sono proprio le richieste di cui Drupal non sa niente.

Come si comincia

1. Installa il sottomodulo: drush en native_observability_cache_observer -y. Richiede

native_observability e funziona su Drupal 10 e 11.

1. Dai il permesso access native observability cache observer a chi deve leggere i dati, e

administer native observability cache observer a chi deve cambiare le impostazioni o cancellare le righe.

1. Controlla le impostazioni su /admin/config/development/native-observability/settings/cache-observer.

Tutte le catture sono accese per default, il tetto sulle invalidazioni è 50 e le righe restano 72 ore.

1. Verifica con due richieste anonime alla stessa pagina: la seconda deve rispondere

X-Drupal-Cache: HIT con un X-Native-Observability-Request-Id diverso dalla prima.

Il rapporto si legge su /admin/reports/native-observability/cache-observer, filtrabile per strato e per stato, con il dettaglio di ogni evento e il suo payload.

Le impostazioni stanno nell'oggetto di configurazione native_observability_cache_observer.settings:

drush cget native_observability_cache_observer.settings
drush cset native_observability_cache_observer.settings max_stored_invalidations_per_request 50 -y

Come rifare la misura

Le due richieste della page cache, da anonimo e senza cookie:

URL=https://example.ddev.site/some-published-page
curl -sk -D a1.txt -o /dev/null "$URL"
curl -sk -D a2.txt -o /dev/null "$URL"
grep -iE 'x-drupal-cache:|x-drupal-dynamic-cache:|x-native-observability-request-id' a1.txt a2.txt

La query che lega ogni evento della page cache alla sua traccia, se esiste:

SELECT c.id, c.request_id, c.status, c.path, c.route_name,
       (SELECT COUNT(*) FROM native_observability_trace t
         WHERE t.request_id = c.request_id) AS trace_rows
FROM native_observability_cache_event c
WHERE c.cache_layer = 'page_cache'
ORDER BY c.id;

Le invalidazioni salvate per ogni richiesta, da confrontare con il tetto configurato:

SELECT request_id, method, route_name,
       COUNT(*) AS stored_rows, SUM(tag_count) AS stored_tags
FROM native_observability_cache_event
WHERE event_type = 'tag_invalidation'
GROUP BY request_id, method, route_name
ORDER BY MIN(id);

Per il salvataggio del nodo serve una richiesta HTTP vera, fatta dal form: un salvataggio lanciato con drush resterebbe fuori, per il motivo scritto fra i limiti.

Che cosa questa prova non dimostra

• È una misura fatta a mano, una richiesta alla volta, in un ambiente DDEV. Mostra il meccanismo, non

il comportamento con il traffico di un sito vero.

• L'ambiente di misura gira in modalità sviluppo. Per la prova ho spento a mano

debug_cacheability_headers e il debug di Twig, e li ho riaccesi alla fine.

• Le tabelle del modulo avevano già righe di prove precedenti e non sono state svuotate. Tutti i

conteggi sono filtrati sulle righe scritte dopo l'inizio della prova.

Fonti e riferimenti

Tutte le fonti sono state consultate il 27 settembre 2026.

1. Pagina di progetto di Native Observability (si apre in una nuova scheda). Ramo 2.0.x, sottomoduli e requisiti. Fonte primaria.
2. Sorgente del modulo, ramo 2.0.x (si apre in una nuova scheda). CachePageObserverMiddleware per i HIT e l'identificativo, CacheResponseObserverSubscriber per la cacheabilità e la dynamic page cache, ObservedCacheTagsInvalidator per le invalidazioni e il tetto, config/install per i valori di default. Fonte primaria.
3. Sorgente del core di Drupal 11: PageCache per le etichette UNCACHEABLE della page cache e la regola sui metodi non cacheabili, DynamicPageCacheSubscriber::shouldCacheResponse() per POOR CACHEABILITY, default.services.yml per l'avvertenza sui debug header. Fonte primaria.
4. Improve X-Drupal-Cache and X-Drupal-Dynamic-Cache headers, even for responses that are not cacheable (si apre in una nuova scheda), issue di core #2951814, aperta. Letta dal DOM reso.
5. Cache tags, guida di Drupal (si apre in una nuova scheda). Letta dal DOM reso.
6. Pagina di progetto di Log Cache Tags (si apre in una nuova scheda). Letta dal DOM reso.
7. Pagina di progetto di Trace Cache Tags (si apre in una nuova scheda). Letta dal DOM reso.
8. Pagina di progetto di Cache review (si apre in una nuova scheda). Letta dal DOM reso.
9. Pagina di progetto di WebProfiler (si apre in una nuova scheda). Letta dal DOM reso.
10. I numeri di questa pagina vengono da un ambiente di misura che ho costruito io, con Drupal 11.4.5 in DDEV e Native Observability 2.0.x. Chi vuole controllarli li rifà con i comandi e le query riportati sopra.

Come si scopre quale servizio esterno rallenta una pagina Drupal?

Si scopre misurando ogni chiamata in uscita mentre la pagina è in corso, e scrivendo accanto alla misura il nome della pagina. Il servizio esterno non lo sa, perché vede arrivare una richiesta da un indirizzo IP, e Drupal di suo non conserva niente di quello che ha chiamato.

Native Observability è un modulo Drupal che registra dall'interno che cosa succede a ogni richiesta. Il sottomodulo Spans cronometra le chiamate HTTP in uscita, e il Dashboard le raggruppa per pagina: per ogni rotta dice quali servizi ha chiamato, quante volte, con quale durata media e quanti errori. Lo stesso problema, per le query al database, è nell'articolo sulle query che rallentano una rotta.

Le misure di questa pagina vengono da un ambiente di misura che ho costruito io, con un servizio lento finto di cui decido il ritardo. Come riprodurlo sta in fondo, nella sezione «Come rifare la misura».

Perché vede le chiamate di tutti i moduli senza modificarli

Perché si aggancia al punto da cui passano tutte. Drupal crea il suo client HTTP, il servizio http_client, da una fabbrica che gli consegna una pila di gestori condivisa, http_handler_stack. Ogni modulo che chiama un servizio esterno attraverso http_client, o attraverso un client creato con http_client_factory, passa da quella pila.

Il modulo aggiunge alla pila un suo middleware Guzzle, GuzzleSpanMiddleware, dichiarato con il tag http_client_middleware. Il middleware fa partire il cronometro prima della chiamata e lo ferma quando arriva la risposta, oppure l'errore. Il codice dei moduli che chiamano resta com'è.

Resta fuori solo chi si costruisce il client da sé:

<?php

// Measured: goes through Drupal's shared handler stack.
$response = \Drupal::httpClient()->request('GET', $url);

// Not measured: a hand-built client has its own handler stack.
$client = new \GuzzleHttp\Client();
$response = $client->request('GET', $url);

La scelta di aggiungere un middleware invece di sostituire il servizio http_client è voluta, e il motivo è scritto nella definizione del servizio: alcuni moduli pretendono proprio la classe GuzzleHttp\Client, e un servizio sostituito li romperebbe.

Dare un nome a una chiamata del proprio modulo

Un modulo che integra un servizio esterno può dare un nome alle sue chiamate con l'opzione Guzzle native_observability, che accetta subtype e name:

<?php

$response = \Drupal::httpClient()->request('POST', $url, [
  'json' => $payload,
  'native_observability' => [
    'subtype' => 'payments',
    'name' => 'Payment gateway: authorize',
  ],
]);

Senza opzione la chiamata si chiama GET <host> e sta nella categoria http.client. Con l'opzione porta il nome scelto e la categoria http.client.payments, e resta fra le dipendenze esterne della rotta. Nel ramo 2.0.x la ripartizione dei tempi della panoramica conta solo la categoria http.client esatta, quindi una chiamata con sottotipo lì non compare.

Quanto tempo passa fuori una rotta, e verso chi

La risposta sta nella tabella External Dependency Signals della Forensic Route Analysis, sotto /admin/reports/native-observability/dashboard/forensic-route-analysis. Una riga per ogni destinazione, con metodo, indirizzo, numero di chiamate, durata media ed errori.

Nell'ambiente di misura la pagina /nos-bench/http fa tre chiamate: una verso un servizio che risponde dopo 800 millisecondi, una verso lo stesso servizio che risponde dopo 20, e una verso un dominio che non esiste. Dopo quattro visite la tabella dice questo:

La pagina risponde in circa un secondo, e la riga da 813 millisecondi spiega da sola quasi tutto quel tempo. È la risposta alla domanda del titolo: su questa rotta il tempo se ne va lì, verso quel servizio.

L'ultima riga non è una chiamata della pagina. È il modulo stesso che spedisce le tracce a un collettore OpenTelemetry, attivo in questo ambiente di misura, e anche quella spedizione passa dal client HTTP di Drupal. Chi usa l'esportazione se la ritroverà fra le dipendenze di ogni rotta.

Per leggere il dashboard serve il permesso access native observability dashboard.

Dal servizio lento alle pagine che lo chiamano

La Forensic Route Analysis accetta anche l'indirizzo di un servizio esterno al posto di una pagina. Nel campo in cui si aggiunge il soggetto da analizzare si incolla l'indirizzo del servizio, e il modulo risale a tutte le rotte che lo hanno chiamato nell'intervallo di tempo scelto.

Incollando 127.0.0.1:8099 nel campo, la risposta è questa:

The search term "127.0.0.1:8099" matched 1 candidates.
/nos-bench/http · nos_bench_http.page (4 requests)

Serve quando si conosce il servizio e non si sa chi lo usa: si parte dall'indirizzo e si arriva alle pagine.

La ricerca scorre i dati salvati di ogni chiamata, che non hanno un indice, e si ferma alle prime mille richieste trovate (SPAN_PAYLOAD_SEARCH_REQUEST_ID_CAP). Durante la misura le richieste erano quattro, quindi il tetto non è entrato in gioco. Su un sito con molto traffico e una finestra di giorni, il risultato può essere tagliato.

Una chiamata fallita per DNS non ha codice di stato

Una chiamata che fallisce prima di arrivare al servizio non riceve risposta, quindi non ha nessun codice di stato. Il modulo la conta come errore lo stesso, perché la riconosce dal campo outcome che scrive accanto a ogni chiamata, e non dal codice.

Le quattro chiamate verso il dominio inesistente sono salvate così:

status_code   null
outcome       error
error         cURL error 6: Could not resolve host: this-host-does-not-resolve.invalid

Un conteggio degli errori basato sui codici 4xx e 5xx queste chiamate le perde senza avvisare. Un fallimento DNS, una connessione rifiutata e un timeout sono proprio i casi in cui un servizio esterno fa più danni, perché la pagina aspetta fino allo scadere del tempo massimo.

Le chiamate fatte da cron e da drush non appartengono a nessuna pagina

Una chiamata partita da cron o da drush viene misurata, ma non ha una pagina a cui appartenere, perché dietro non c'è nessuna richiesta HTTP. Il modulo la salva senza identificativo di richiesta.

Una chiamata lanciata con drush php:eval compare così: una sola riga da 67 millisecondi, con l'identificativo della richiesta vuoto. Non si trova sotto nessuna traccia e non entra nella tabella di nessuna rotta. Entra soltanto nella ripartizione dei tempi della panoramica generale.

Vale la pena saperlo prima di confrontare i numeri: un'importazione notturna che chiama un servizio esterno migliaia di volte non comparirà in nessuna pagina.

Che cosa il modulo non fa

Misura soltanto quello che succede dentro Drupal: quanto ha aspettato, chi ha chiamato, com'è finita. Tutto il resto lo lascia ad altri strumenti.

• Non collega la traccia di Drupal a quella del servizio chiamato. Sulle chiamate in uscita non aggiunge nessuna intestazione, né traceparent né una sua. Per seguire una richiesta attraverso più sistemi serve il distributed tracing, cioè OpenTelemetry (si apre in una nuova scheda) con un backend che raccoglie le tracce di tutti i servizi.
• Raggruppa per indirizzo intero, non per host. Nella tabella qui sopra lo stesso servizio occupa due righe, perché la query string è diversa. Un servizio chiamato con un parametro che cambia a ogni richiesta si spezza in tante righe quante sono le chiamate.
• Salva l'indirizzo con la query string, chiavi comprese. La chiave finta api_key=BENCH-KEY-12345 usata nella misura si legge nel database e nella tabella del dashboard. Il modulo toglie le credenziali dalle intestazioni e dal corpo, non dall'indirizzo. Se un servizio vuole la chiave nell'URL, quella chiave finisce nei dati di osservabilità.
• Una pagina servita dalla cache non chiama nessuno. Nell'ambiente di misura la prima visita anonima ha impiegato circa 3,3 secondi, le due successive circa 0,5 e 0,1, e solo la prima ha lasciato una traccia. La Internal Page Cache ha servito le altre senza eseguire il codice della pagina. È il comportamento giusto, ma chi prova a misurare ricaricando la stessa pagina da anonimo vede una chiamata sola dove si aspettava di vederne tre.

Confronto con gli altri strumenti

Ognuno risponde a una domanda diversa, e la scelta dipende dalla domanda. La tabella riporta quello che ogni progetto dichiara sulla sua pagina: gli altri strumenti non sono stati provati nell'ambiente di misura.

Un log serve quando vuoi leggere il corpo di una risposta sbagliata. Una toolbar serve quando hai la pagina davanti. Un backend OpenTelemetry serve quando hai più servizi e qualcuno che li amministra. Nessuno dei primi tre raggruppa le chiamate per rotta, e nessuno parte dal servizio per arrivare alle pagine.

Come si comincia

Tre passi.

1. Installa il dashboard, che si porta dietro Spans e gli altri sottomoduli di cui ha bisogno: drush en native_observability_dashboard -y.
2. Dai il permesso access native observability dashboard a chi deve leggere i dati.
3. Verifica che le chiamate vengano misurate con il comando di prova del modulo, che fa cinque chiamate verso destinazioni note, compreso un dominio che non si risolve:

drush native-observability-span:http-test

Dopo il comando, le cinque chiamate si leggono su /admin/reports/native-observability/execution. Il comando chiama anche httpbin.org, quindi serve la rete. Da lì in avanti ogni chiamata del sito finisce in tabella, e la Forensic Route Analysis mostra le dipendenze di ogni rotta.

Come rifare la misura

Il servizio lento è un file PHP che dorme per il numero di millisecondi chiesto. Non serve internet, e il ritardo lo decide chi fa la prova:

<?php

// Bench-only stub of a slow third party service.
// ?ms=800 sleeps for 800 milliseconds, ?status=500 answers with an error.
$ms = isset($_GET['ms']) ? max(0, (int) $_GET['ms']) : 0;
$status = isset($_GET['status']) ? (int) $_GET['status'] : 200;

usleep($ms * 1000);

http_response_code($status);
header('Content-Type: application/json');
echo json_encode(['slept_ms' => $ms, 'status' => $status]);

php -S 127.0.0.1:8099 /tmp/slow-service.php

La pagina misurata è un controller che fa le tre chiamate con \Drupal::httpClient(). Dopo qualche visita, questa query conferma sul database quello che mostra il dashboard:

SELECT t.route_name,
       COUNT(*) AS calls,
       ROUND(AVG(s.duration_ms), 1) AS avg_ms,
       MAX(s.duration_ms) AS max_ms
FROM native_observability_spans s
JOIN native_observability_trace t ON t.request_id = s.request_id
WHERE s.category LIKE 'http.client%'
GROUP BY t.route_name;

E questa rifà a mano la ricerca inversa, dall'indirizzo del servizio alla rotta:

SELECT DISTINCT t.route_name, t.path
FROM native_observability_spans s
JOIN native_observability_trace t ON t.request_id = s.request_id
WHERE s.category LIKE 'http.client%'
  AND CAST(s.payload AS CHAR) LIKE '%127.0.0.1:8099%';

Con la cattura spenta, capture.enabled a zero in native_observability.settings, una nuova visita alla pagina non aggiunge nessuna riga. È il controllo che conferma che le righe le scrive il modulo.

Che cosa questa prova non dimostra

Il servizio lento è finto, ed è giusto saperlo.

• Il ritardo è un usleep deciso da me. La prova mostra il meccanismo, non il comportamento di un servizio vero sotto carico, con le sue code e i suoi timeout variabili.
• Una richiesta alla volta, in un ambiente di misura DDEV con Xdebug acceso. I tempi assoluti non vanno letti come misura di prestazioni.
• Le tabelle del modulo avevano già righe di prove precedenti e non sono state svuotate. Tutti i conteggi sono filtrati sulle righe scritte dopo l'inizio della prova, alle 19:07:50 UTC del 27 settembre 2026.
• Quattro visite, non un giorno di traffico. La media su quattro chiamate descrive l'ambiente di misura, non un sito in produzione.

Fonti e riferimenti

Tutte le fonti sono state consultate il 27 settembre 2026.

1. Pagina di progetto di Native Observability (si apre in una nuova scheda). Ramo 2.0.x, sottomoduli e requisiti. Fonte primaria.
2. Sorgente del modulo, ramo 2.0.x (si apre in una nuova scheda). GuzzleSpanMiddleware per la misura delle chiamate e il campo outcome, ForensicRouteAnalysisBuilder per la tabella delle dipendenze e la ricerca inversa con il suo tetto di mille richieste, docs/usage/spans.md per le chiamate da cron e drush e per il comando di prova. Fonte primaria.
3. Sorgente del core di Drupal 11, core.services.yml e Drupal\Core\Http\ClientFactory: http_client e http_client_factory condividono http_handler_stack. Fonte primaria.
4. Pagina di progetto di HTTP Client Logs (si apre in una nuova scheda). Letta dal DOM reso.
5. Pagina di progetto di HTTP Client logger (si apre in una nuova scheda). Letta dal DOM reso.
6. Pagina di progetto di WebProfiler (si apre in una nuova scheda). Letta dal DOM reso.
7. Pagina di progetto di OpenTelemetry (si apre in una nuova scheda). Letta dal DOM reso.
8. Trace Context, W3C Recommendation del 23 novembre 2021 (si apre in una nuova scheda). Definisce l'intestazione traceparent. Fonte primaria.
9. I numeri di questa pagina vengono da un ambiente di misura che ho costruito io, con Drupal 11 in DDEV e Native Observability 2.0.x. Le misure sono state rilette sul database con le query riportate sopra. Chi vuole controllarla la rifà con il codice e le query riportati in questa pagina.

Questo articolo non è un parere legale. Riporta che cosa dicono il Regolamento (UE) 2024/1689 e la FAQ della Commissione europea, e che cosa fa il modulo con quelle regole. Se un contenuto va etichettato lo decide chi lo pubblica.

Che cosa sia AI Disclosure e come sia costruito sta nella scheda del progetto. Qui si guarda solo come il modulo traduce l'articolo 50(4) in dati e in un'etichetta sulla pagina.

Come decide AI Disclosure se un contenuto va etichettato?

AI Disclosure tiene separate due informazioni: quanto l'AI è entrata nel contenuto e se la norma si applica a quel contenuto.

La prima è il grado, uno su nove. Sei gradi dicono che l'AI ha generato o manipolato il contenuto pubblicato: traduzione, riassunto, riscrittura parziale, testo prodotto con una persona che guida, testo prodotto senza nessuno, deep fake. Solo per questi sei la domanda sulla norma ha senso. Gli altri tre, cioè nessuna AI, metadati scelti dall'AI e contenuto valutato dall'AI, restano fuori.

La seconda sono le quattro risposte di ambito:

Ogni risposta vale sì, no o non valutato. Il modulo non ne deduce nessuna: né dal tipo di contenuto, né dal grado.

Che cosa chiede l'articolo 50(4) dell'AI Act?

L'articolo 50(4) contiene due obblighi per chi pubblica, con presupposti diversi.

Il primo riguarda immagini, audio e video che costituiscono un deep fake: chi li diffonde deve dichiarare che sono stati generati o manipolati artificialmente. La revisione umana non esime dall'obbligo. Quando il deep fake fa parte di un'opera palesemente artistica, creativa, satirica o di finzione, l'obbligo si riduce a segnalare che il contenuto è generato o manipolato, in un modo che non ostacoli la fruizione dell'opera.

Il secondo riguarda i testi generati o manipolati con l'AI e pubblicati per informare il pubblico su questioni di interesse pubblico. Qui c'è un'esenzione, che richiede due condizioni insieme: il testo è passato da una revisione umana o da un controllo editoriale, e una persona fisica o giuridica ne ha la responsabilità editoriale. Secondo la FAQ della Commissione, responsabilità editoriale significa la responsabilità legale ultima della pubblicazione.

Da quando si applica l'articolo 50 dell'AI Act?

L'articolo 50 si applica dal 2 agosto 2026, la data generale fissata dall'articolo 113 del Regolamento. I contenuti generati prima di quella data non vanno etichettati retroattivamente, anche se la Commissione invita a farlo dove possibile.

Il Regolamento (UE) 2026/1744, il Digital Omnibus sull'AI pubblicato in Gazzetta il 24 luglio 2026, non ha spostato questa data per chi pubblica. Ha aggiunto all'articolo 111 un paragrafo che vale solo per i fornitori: i sistemi generativi immessi sul mercato prima del 2 agosto 2026 devono rispettare l'articolo 50(2), cioè la marcatura del file, entro il 2 dicembre 2026. È questa la data che circola spesso come rinvio generale. L'articolo 50(4) non compare fra le modifiche, e chi pubblica contenuti resta sulla data di agosto.

Che cosa significa «non valutata» nel verdetto?

Il verdetto di AI Disclosure ha tre valori: etichetta richiesta, non richiesta, non valutata. Un no su una qualsiasi condizione chiude la questione anche se le altre risposte mancano, e lo stesso vale per l'esenzione dei testi. «Non valutata» compare solo quando manca una risposta che cambierebbe l'esito.

Sulla pagina un contenuto non valutato mostra comunque la scheda, con una dicitura dedicata e un bordo tratteggiato. Nasconderla direbbe al lettore che nessuna etichetta è dovuta, cioè proprio la cosa che il sito non ha ancora stabilito.

Come si risponde una volta sola per un intero tipo di contenuto?

Le risposte si danno sul profilo, e ogni contenuto eredita il profilo di default del suo tipo. Il singolo contenuto interviene solo per le eccezioni. Grado e quattro risposte arrivano sempre dallo stesso livello: il modulo non mescola risposte prese da livelli diversi.

Un profilo che dichiara la revisione umana senza un responsabile non si salva, né dal form né da un import di configurazione.

Su questo sito il profilo editorial_default, impostato il 20 settembre 2026, dichiara testo, pubblicato per informare, con revisione umana e responsabile nominato.

Alla domanda sull'interesse pubblico il profilo risponde no, ed è una scelta mia, non un dato. La FAQ della Commissione fa rientrare nell'interesse pubblico anche gli sviluppi economici, scientifici o culturali che possono diventare oggetto di dibattito pubblico, e un articolo tecnico sull'AI Act potrebbe starci dentro. Il verdetto non cambierebbe: con un sì, revisione umana e responsabile nominato fanno comunque scattare l'esenzione.

Con queste risposte il verdetto è «non richiesta», e la pagina lo scrive nel meta tag:

<meta name="ai-disclosure" content="ai_assisted_hitl; required=not-required; icon=ai_modified">

La scheda si vede lo stesso, perché la policy del sito è impostata su «mostra sempre».

Che cosa succede quando l'etichetta è dovuta?

Quando l'etichetta è dovuta compaiono l'icona ufficiale UE e la frase del grado, e il sito non può nasconderle: la visibilità della scheda si configura, ma un'etichetta richiesta si mostra comunque. Il resto della scheda, cioè dicitura legale, descrizione e link alla policy editoriale, segue le impostazioni del sito.

Che cosa succede se cambio la configurazione dei gradi?

I contenuti in eredità leggono grado e profilo dalla configurazione al momento della visualizzazione. Cambiare la frase di un grado cambia quindi ciò che mostrano tutti i contenuti che lo usano, anche quelli pubblicati mesi prima. Il sottomodulo Audit esiste per questo: a ogni salvataggio copia nel registro il significato del grado in quel momento, e le modifiche successive alla configurazione non riscrivono la storia.

Che cosa AI Disclosure non fa?

AI Disclosure non decide se un contenuto va etichettato e non controlla le risposte. Accetta il nome inserito come responsabile editoriale senza giudicarlo: un ruolo generico come «la redazione» non regge un audit. Non marca il file: il JSON-LD è un segnale a livello di pagina, e la marcatura dell'articolo 50(2) spetta al fornitore del sistema di AI, non a chi pubblica.

Fonti e riferimenti

Tutte le fonti sono state consultate il 27 settembre 2026.

1. Regolamento (UE) 2024/1689, testo in Gazzetta ufficiale (si apre in una nuova scheda), EUR-Lex. Articolo 50, paragrafo 4, e articolo 113 sulla data di applicazione. Letto dal DOM reso, fonte primaria.
2. Regolamento (UE) 2026/1744, Digital Omnibus sull'AI (si apre in una nuova scheda), EUR-Lex, Gazzetta ufficiale del 24 luglio 2026. Il punto 39 aggiunge all'articolo 111 il paragrafo 4 sul 2 dicembre 2026 per l'articolo 50(2). Dell'articolo 50 è modificato solo il paragrafo 7. Letto dal DOM reso, fonte primaria.
3. FAQ sugli obblighi di trasparenza dell'articolo 50 (si apre in una nuova scheda), Commissione europea, aggiornata il 24 luglio 2026. I tre criteri dei testi, gli ambiti di interesse pubblico, che cosa conta come revisione umana, la responsabilità editoriale, il 2 dicembre 2026 limitato al 50(2), l'etichettatura retroattiva. Letta dal DOM reso, fonte primaria.
4. AI Disclosure, pagina di progetto (si apre in una nuova scheda), drupal.org. Release 1.0.0-alpha2 del 12 settembre 2026, per Drupal 10.4 e 11. Letta dal DOM reso.
5. Documentazione di AI Disclosure sull'articolo 50 (si apre in una nuova scheda), pagina «Article 50, and what this module does not do», aggiornata l'11 settembre 2026. Fonte primaria sul comportamento del modulo.
6. AI Disclosure Module Adds Article 50 Labelling Tools for Drupal (si apre in una nuova scheda), The Drop Times, 16 settembre 2026. La notizia sull'uscita delle due alpha e sulle funzioni del modulo. Letta dal DOM reso.
7. Il meta tag citato nella sezione sul profilo è quello che questa stessa pagina scrive nel suo <head>: si verifica aprendo il sorgente.

Quale query rallenta una pagina Drupal, e come si scopre?

Si scopre solo se qualcosa ha scritto il nome della pagina accanto alla query mentre la richiesta era in corso. Dopo non si ricostruisce più: il database conserva le query lente, ma per lui sono istruzioni arrivate da una connessione, non pagine di un sito.

Native Observability è un modulo Drupal che registra dall'interno che cosa succede a ogni richiesta. Il suo sottomodulo Database Observer fa una cosa sola: quando una query supera una soglia di durata, salva una riga con due informazioni accostate, la query e la pagina che l'ha eseguita.

Questa pagina racconta tre cose: che cosa ci si trova dentro quella riga, quanto ci si può fidare di quello che si legge, e da dove si comincia. Quanto rallenta il sito tenere acceso il modulo è un'altra domanda, e la risposta è misurata nell'articolo dedicato al suo costo. Lo stesso problema, per le chiamate HTTP verso servizi esterni, è nell'articolo sul servizio esterno che rallenta una rotta.

Perché gli strumenti che hai già non rispondono

Rispondono a domande vicine, e nessuna è questa.

Il log lento di MySQL conosce le query e ignora le pagine. Non è un limite di configurazione, è la sua definizione: il manuale lo descrive come l'elenco delle istruzioni SQL che superano una certa durata. Istruzioni, non pagine. I campi che salva sono quelli del database, cioè durata, righe lette e righe restituite, e nessuno di questi dice da dove sia partita la richiesta: il database riceve comandi da una connessione e non sa che sopra di lui esista un sito. Alla fine hai la query colpevole e vai a cercarla a mano dentro il codice.

Gli strumenti di sviluppo guardano la pagina che hai aperto adesso, non quella lenta di ieri che non riesci a riprodurre.

Due precisazioni, perché girano capovolte. La prima: Devel dichiara di essere sicuro in produzione, alla lettera, sulla sua pagina di progetto, a patto di dare il permesso giusto solo a chi sviluppa. Il confine quindi non è fra sviluppo e produzione: è fra la richiesta che stai facendo tu e la storia delle richieste degli altri. La seconda: XHProf scende in un dettaglio che qui non troverai, perché ricostruisce l'albero delle chiamate, mentre Native Observability cronometra i servizi e si ferma lì.

DB Performance è quello che arriva più vicino, e la differenza è netta: raggruppa le query lente per forma e suggerisce indici, ma sulla sua pagina di progetto non compare mai la parola rotta né la parola URL. Nessuno di questi strumenti scrive da quale pagina la query sia arrivata.

Che cosa si vede, quando il collegamento c'è

Una riga per ogni query lenta, e niente per le altre.

In un ambiente di misura con Drupal 11, con le impostazioni predefinite del modulo, una pagina costruita per essere lenta risponde in circa 0,6 secondi. In tabella resta questo:

route_name        testing_native_observability.probe_slow_db
duration_ms       603.968
query_text        SELECT SLEEP(:s)
query_hash        0f907bc4...

Quattro informazioni, e servono tutte:

• la rotta è il nome che Drupal dà a una pagina dal punto di vista del codice. Dice quale parte del sito ha generato la query, anche quando l'indirizzo cambia a ogni visita;
• la durata è in millisecondi, quindi circa 0,6 secondi;
• il testo della query è, accanto, la classe e il metodo che l'hanno eseguita;
• l'impronta è un codice calcolato sul testo SQL ripulito dai valori. Serve a ritrovare la stessa query su altre pagine e in altri giorni, anche quando i valori cambiano.

Nella stessa richiesta girava anche una seconda query pesante, e non compare. È durata meno della soglia predefinita di cento millisecondi, quindi non è stata salvata. La soglia si comporta da cancello, non da registratore.

Le stesse righe si leggono a video su /admin/reports/native-observability/database-observer, con il permesso access native observability database observer.

Quanto ti puoi fidare di quella tabella

Dipende da due impostazioni, e la seconda merita attenzione.

La prima è la soglia, cento millisecondi di default: decide quanto deve durare una query per finire in tabella. Abbassarla non porta più verità, porta più righe, e sotto qualche millisecondo stai registrando il funzionamento normale del sito.

La seconda è il massimo di righe per richiesta, venti di default. Se una pagina produce più di venti query lente, le altre vengono scartate, e per ora nessuna schermata te lo dice. Venti righe in tabella sono indistinguibili da venti query lente davvero avvenute.

C'è però un modo di accorgersene, perché il modulo salva anche quante query lente ha visto, prima di scartarne qualcuna. Questa query mette in fila le richieste in cui è successo, confrontando le righe salvate (stored_rows) con quelle viste (slow_queries_seen):

SELECT request_id, route_name, COUNT(*) AS stored_rows,
       MAX(JSON_EXTRACT(payload, '$.request_summary.slow_query_count')) AS slow_queries_seen
FROM native_observability_database_query
GROUP BY request_id, route_name
HAVING slow_queries_seen > stored_rows;

Nell'ambiente di misura il taglio si vede a occhio nudo: una pagina che esegue venticinque query lente lascia in tabella esattamente venti righe, e le cinque in più non esistono da nessuna parte.

Un'ultima cosa, per non cercarle altrove: il Database Observer non scrive niente nel log di Drupal. Quello che ha visto sta nella sua tabella e nel suo report, e in nessun altro posto.

Se la pagina lenta la chiama un altro sistema

Il collegamento si mantiene con due intestazioni HTTP. Chi chiama mette il proprio identificativo in X-Native-Observability-Parent-Request-Id, Drupal risponde con X-Native-Observability-Request-Id, e il modulo conserva il legame fra le due richieste. Da lì si arriva alle query lente di quella pagina.

Una avvertenza per non restare delusi: verso un dominio diverso dal tuo, l'identificativo lo deve mettere chi chiama. Il modulo lo aggiunge da solo solo alle chiamate che restano sullo stesso sito.

Da dove si comincia

Quattro passi, e dopo il primo la tabella comincia a riempirsi.

1. Installa il sottomodulo: drush en native_observability_database_observer -y. Si porta dietro il modulo principale.
2. Dai il permesso access native observability database observer a chi deve leggere il report, e administer native observability database observer a chi deve cambiarne le impostazioni.
3. Lascia la soglia a cento millisecondi per qualche giorno, poi guarda il report. Se la tabella resta vuota, sulle pagine che stai guardando non ci sono query lente: è un risultato, non un guasto.
4. Prima di trarre conclusioni, fai girare la query di controllo qui sopra. Se restituisce righe, stai leggendo solo una parte di quello che è successo.

Che cosa questa prova non dimostra

La lentezza dell'ambiente di misura è finta, ed è giusto saperlo.

• Il ritardo è iniettato da una pagina di test. La prova mostra il meccanismo, non che il modulo sappia diagnosticare da solo una lentezza vera, che di solito nasce da un indice mancante o da una query ripetuta dentro un ciclo.
• Per mostrare il taglio delle righe la soglia è stata abbassata di proposito. Il caso in cui sia la lentezza vera a produrre più di venti query lente in una sola richiesta non è stato riprodotto.
• Nessuna concorrenza e nessuna correzione rimisurata: una richiesta alla volta, su una pagina lenta per costruzione. I tempi assoluti non vanno letti come misura di prestazioni.

Fonti e riferimenti

Tutte le fonti sono state consultate il 27 settembre 2026.

1. The Slow Query Log, MySQL 8.4 Reference Manual (si apre in una nuova scheda). Definizione del log lento e campi scritti. Letta dal DOM reso: a curl il sito risponde 403.
2. Devel, pagina di progetto (si apre in una nuova scheda). La frase sulla sicurezza in produzione e il permesso da concedere. Letta dal DOM reso.
3. WebProfiler, pagina di progetto (si apre in una nuova scheda). La toolbar in fondo a ogni pagina. Letta dal DOM reso.
4. XHProf, pagina di progetto (si apre in una nuova scheda). Profiler gerarchico, scomposizione per chiamanti e chiamati. Letta dal DOM reso.
5. DB Performance, pagina di progetto (si apre in una nuova scheda). Aggregazione per forma della query e suggerimento di indici, release 1.0.0-alpha2. Letta dal DOM reso.
6. Native Observability, pagina di progetto (si apre in una nuova scheda). Requisiti e sottomoduli.
7. Sorgente del modulo, ramo 2.0.x (si apre in una nuova scheda). Le classi citate in questa pagina si aprono da lì: DatabaseQueryObserverSubscriber per il conteggio delle query lente prima del limite per richiesta, DatabaseObserverSettingsForm per i vincoli delle due impostazioni, TraceSubscriber per le due intestazioni HTTP.
8. I numeri di questa pagina vengono da un ambiente di misura con Drupal 11 che ho costruito io, non da un sito pubblico: comandi e risultati sono riprodotti qui sopra per intero, e le condizioni in cui valgono stanno nella sezione «Che cosa questa prova non dimostra». Non è una fonte che puoi aprire, è una misura che puoi rifare.

Quanto rallenta Drupal il modulo Native Observability?

Native Observability (si apre in una nuova scheda) è il modulo Drupal che registra dall'interno cosa succede a ogni richiesta, e strumentare un sito con lui costa circa 4,7 e circa 7,0 millisecondi per richiesta sulle due macchine dove l'ho misurato. Stesso codice, stessa versione, stesso comando di misura, due numeri che differiscono del 48%.

Cosa faccia il modulo e come sia costruito sta nella scheda del progetto; qui si parla soltanto di quanto costa e di come si misura.

Il primo è pubblicato nella documentazione del modulo (si apre in una nuova scheda), che ne dichiara le condizioni e la provenienza. Il secondo l'ho preso io su un ambiente DDEV in container, il 25 settembre 2026.

La terza riga è quella che conta di più: spegnere due sottomoduli porta il costo da circa 4,7 a circa 1,8 millisecondi, cioè lo taglia del 62%. Le due cifre del taglio vengono dalla stessa sessione appaiata, non dal confronto fra la prima e la terza riga di questa tabella. Nessuno dei tre numeri è la risposta alla tua domanda, perché nessuna di quelle installazioni è la tua.

Perché due macchine danno due numeri diversi

Il costo di strumentare un'applicazione dipende dalla macchina che esegue l'istruzione in più, e le due macchine qui sopra differiscono su tutto ciò che conta: frequenza e generazione della CPU, stato dell'opcache, tipo di storage, carico concorrente al momento della misura, e lo strato di virtualizzazione che c'è o non c'è sotto.

Va detto anche quello che non ho tenuto costante: le due installazioni Drupal non avevano lo stesso contenuto. La documentazione dichiara che la misura piu' bassa è stata presa a tabelle vuote; la mia no. Il volume di dati sposta il lavoro di alcune strumentazioni, quindi lo scarto fra le due cifre va letto come differenza fra due ambienti nel loro insieme, non fra due processori. Dichiararlo costa una riga e rende il numero utilizzabile: una cifra senza le sue condizioni è lo stesso genere di dato che i fornitori di APM pubblicano senza dire dove l'hanno preso.

Perché il modulo ha smesso di dichiarare una percentuale

Prima della 2.0.0, e cioè fino alla 1.x compresa, native_observability pubblicava una stima che nessuno aveva mai misurato. Le note di rilascio della 2.0.0, che quel codice lo hanno rimosso, lo dicono senza giri di parole:

The report used to sum four hardcoded constants and print a made-up "Estimated overhead: 10%".

Quattro costanti scritte a mano nel sorgente, sommate, stampate come percentuale. Quel codice è stato rimosso nella 2.0.0. The Drop Times (si apre in una nuova scheda) ha dedicato un articolo a quella decisione e riporta la mia risposta scritta, in cui definivo quel 10% una sovrastima ricavata dalle mie prove, che non si poteva trasferire da un server all'altro. La frase è mia, non loro: è una citazione, non una conferma indipendente. La loro copertura si ferma al costo del modulo, che è una sola delle cose che il modulo fa: qui resto sullo stesso terreno, e cosa faccia per il resto sta nella scheda del progetto.

Al suo posto la 2.0.0 ha messo un comando. La scelta costa qualcosa a chi cerca una cifra sulla pagina del progetto e non la trova, e rende qualcosa a chi deve decidere se installare il modulo su un server preciso.

Sono io il maintainer del modulo, quindi questa sezione è il resoconto di una decisione mia. Le misure le puoi rifare con lo stesso comando. Il giudizio sulla decisione resta mio.

Le misure di questa pagina sono state prese sulla 2.0.1. La release stabile pubblicata sul progetto è 2.0.1, e se è più recente conviene rifare la misura prima di fidarsi dei numeri qui sotto.

Come si misura: il comando

Un comando, nessuna configurazione:

drush no:overhead:measure

Il comando confronta due stati della stessa installazione: cattura accesa e cattura spenta. Misurare entrambi gli stati sullo stesso sito isola il costo del modulo dalle differenze fra un server e un altro, che è esattamente ciò che rende inutile confrontare il tuo numero col mio.

Il modulo include due rotte di calibrazione, escluse da una misura ordinaria: una che non esegue nessuna query e nessun rendering, una che esegue un carico dichiarato e costante. Servono a far sì che la misura ponga la stessa domanda su qualunque installazione.

Come fa il comando a non mentire

Il protocollo è quello del benchmarking in ambiente rumoroso, applicato a una richiesta HTTP. Le note di rilascio della 2.0.0 lo descrivono per intero, e sono cinque accorgimenti:

1. Blocchi appaiati. Ogni coppia esegue un blocco con la cattura accesa e uno con la cattura

spenta, così un rallentamento del server colpisce entrambi i lati.

1. Alternanza. Il lato che parte per primo cambia da una coppia alla successiva, perché il primo

dei due paga l'ingresso a freddo.

1. Prima coppia scartata. Serve a riscaldare cache e opcache e non entra nel calcolo.
2. Mediana delle differenze appaiate. La mediana regge un valore anomalo, la media no.
3. Test dei segni esatto bilaterale, con soglia p ≤ 0,05, più una passata separata con la

cattura spenta su entrambi i lati per misurare il rumore di fondo della macchina.

L'ultimo punto è quello che distingue una misura da un numero. Senza il rumore di fondo non sai se il delta che hai ottenuto è l'effetto del modulo o il respiro del tuo server.

Come leggo il risultato

Quattro valori decidono se il numero vale, e stanno tutti nell'output. Questo è il mio, tagliato alle righe che contano:

Fixed cost per request (a): 6.953 ms/req

calibration-minimal:
  - budget: 0.87% of the declared TTFB budget (good)
  - N 15 | IQR [6.908, 7.020] | noise 0.040 | signs 7/7 | p=0.01562

Un delta che non superi il rumore viene dichiarato unclear invece di meas, e a quel punto la cosa utile da fare è rifare la misura su una macchina più tranquilla.

Circa 7 millisecondi sono tanti o pochi?

Dipende dal budget di risposta del tuo sito, e contro il mio sono circa lo 0,9%.

La soglia di riferimento arriva da Solving Big Data Challenges for Enterprise Application Performance Management (si apre in una nuova scheda) (Rabl, Gómez-Villamor, Sadoghi, Muntés-Mulero, Jacobsen, Mankovskii, VLDB 2012), che la formula così: «As a rule of thumb, a maximum tolerable overhead is five percent, but a smaller rate is preferable». Sopra quella soglia il monitoraggio degrada ciò che dovrebbe osservare.

Quanto la soglia venga rispettata è un'altra questione. groundcover osserva che il 3-5% ricorre nei benchmark che i fornitori di APM conducono su sé stessi, e cita una misura di Scout APM, che di New Relic è concorrente, in cui il suo agente aggiungeva oltre il 44% in uno scenario Ruby.

Gli 800 millisecondi non li ho scelti io: sono il valore di overhead.budget_ms nella configurazione del modulo, e il commento nel sorgente dice che vengono dalla soglia TTFB «good» documentata da web.dev. Serve a colorare il verdetto, e va sostituito col budget reale del tuo sito: una cifra in millisecondi senza il budget contro cui confrontarla non dice se il modulo sia sostenibile.

La scrittura sul database il visitatore non la paga

Le righe non vengono scritte durante la richiesta. DeferredPersistenceBuffer le accumula in memoria e le scarica con una sola INSERT multi-riga agganciata a KernelEvents::TERMINATE, l'evento che Drupal emette dopo che la risposta ha raggiunto il client. Il commento nel sorgente dice da dove si veniva: una richiesta carica spediva «circa 130 INSERT singole».

Tre dettagli del meccanismo, perché la differenza fra buffering e scrittura differita sta lì:

• il buffer si svuota da sé oltre le 1000 righe, così una richiesta anomala non tiene in memoria un

volume illimitato;

• flush() ingoia le eccezioni, perché un errore dell'osservabilità non deve far cadere la risposta

che stava osservando;

• l'impostazione deferred_persistence_enabled riporta il modulo alla scrittura immediata, quando

serve per capire cosa stia succedendo al buffer.

Quello che invece il visitatore paga è la strumentazione, e resta dentro la richiesta. Nel censimento a livello di richiesta pubblicato nella documentazione del modulo (si apre in una nuova scheda) e ripreso da The Drop Times (si apre in una nuova scheda), su circa 6,3 millisecondi di lavoro del modulo circa 0,4 stavano nel flush differito (il 6,1%) mentre il restante 93,9% girava prima che la risposta partisse: tracciamento dell'esecuzione, collegamento degli span, osservazione della cache.

Quel censimento risponde a una domanda diversa dal costo fisso per richiesta, e i due numeri non vanno messi nella stessa colonna. Il censimento conta il lavoro che il modulo attribuisce a sé stesso. La misura appaiata conta la differenza fra un sito strumentato e lo stesso sito senza strumentazione, ed è quella che il visitatore paga.

Quanto raccoglie il modulo lo decidi tu, e i limiti sono già impostati

Ogni fonte di dati ha un tetto scritto nella configurazione predefinita, e nessuno di questi valori è cablato nel codice. Come impostarli sta nella pagina di configurazione della documentazione (si apre in una nuova scheda); questi sono i default, da config/install:

In native_observability.settings:

I due observer sono sottomoduli e hanno un oggetto di configurazione proprio. In native_observability_database_observer.settings:

In native_observability_cache_observer.settings:

Le due soglie per richiesta sono quelle che tengono il costo costante quando una pagina si comporta male: una rotta che esegue trecento query ne fa registrare venti, non trecento.

Sul lato dei dati personali i default partono chiusi, e questo abbassa anche il lavoro: il corpo della richiesta, la query string e gli header non vengono raccolti (body_mode, query_mode, headers_mode sono a off), l'indirizzo IP è anonimizzato e dello user agent resta solo la famiglia. Il modulo esclude inoltre le proprie rotte dalla cattura (exclude_own_routes), così aprire la dashboard non gonfia i contatori che stai leggendo.

Cosa dichiarano gli altri strumenti

Nessuno dei fornitori di APM per PHP pubblica una cifra ottenuta sulla macchina del cliente, e due dei quattro che ho consultato non pubblicano alcuna cifra. La colonna che conta non è quanto dichiarano, è a quali condizioni.

Le percentuali di Tideways non si confrontano con la mia. Misurano WordPress su PHP 5.6 e PHP 7, sotto un carico costruito per saturare la macchina, mentre il mio numero viene da Drupal 11.4.5 su PHP 8.3. Altro CMS, due versioni maggiori di PHP di distanza, condizioni opposte.

Quello che si confronta è il comportamento. Tideways e Blackfire pubblicano numeri misurati e ne dichiarano i limiti, e quella è la cosa giusta da fare anche quando il numero che esce non è lusinghiero. New Relic e Datadog, sulle pagine che ho letto, non pubblicano niente. Il confronto che regge è questo, e non ha percentuali dentro.

Che cosa chiedere a chi pubblica un numero di prestazioni

Quattro domande, e valgono per qualunque strumento, non solo per questo. Non sono teoriche: le ho scritte dopo aver trovato tre difetti che falsavano la misura del mio stesso modulo, elencati con i loro numeri nelle note di rilascio della 2.0.0 (si apre in una nuova scheda).

1. Lo strumento si esclude dalla propria misura? Chi traccia anche le rotte con cui si misura

conta sé stesso, e il segno dell'errore non è prevedibile: nel mio caso il costo risultava più basso del 55%, non più alto.

1. La ripetizione è protetta dalla cache? Se la seconda esecuzione può essere servita dalla

cache della prima, il numero pubblicato è il tempo della cache: circa due ordini di grandezza più basso, cioè un costo che non esiste.

1. La configurazione viene riletta? Un servizio che legge le impostazioni una volta sola, per

la vita della propria istanza, funziona sotto PHP-FPM e mente in un runtime persistente. È la classe di problema del meta issue del core sui server applicativi persistenti (si apre in una nuova scheda), che elenca ReactPHP, PHP-PM, PHPFastCGI, FrankenPHP e Swoole.

1. Il rumore di fondo è dichiarato? Senza, non si distingue l'effetto misurato dal respiro della

macchina, ed è il motivo per cui noise sta dentro il risultato del comando insieme al valore.

Se chi pubblica un numero non risponde a queste quattro, quel numero vale quanto valeva il «10%» stampato dalla 1.x.

Cosa faccio con questo numero

Misuro prima di installare in produzione, e rimisuro dopo ogni cambio di macchina o di versione di PHP. La procedura sta in quattro passi:

1. Installare il modulo su un ambiente identico a quello di produzione per versione di PHP, di

Drupal e di database, con Xdebug spento: Xdebug strumenta ogni chiamata di funzione e qualunque misura fatta con lui acceso va buttata.

1. Eseguire drush no:overhead:measure senza altro carico sulla macchina.
2. Leggere N, IQR, noise e p prima del valore. Se il verdetto è unclear, il valore non si

usa.

1. Dividere il costo per il budget di risposta del sito e confrontare con la soglia che ti sei dato.

I passaggi di installazione stanno nella documentazione del modulo (si apre in una nuova scheda), e cosa il modulo faccia davvero nella scheda del progetto su questo sito. Il numero che ottieni vale per la tua macchina e per quella installazione. Il mio l'ho pubblicato perché serva da termine di paragone sull'ordine di grandezza, e perché si veda che due misure dello stesso codice possono stare a mezzo millisecondo o a due millisecondi di distanza.

Fonti e riferimenti

Tutte le fonti sono state consultate il 27 settembre 2026.

1. Native Observability, pagina del progetto (si apre in una nuova scheda). Requisiti, comando di misura, release stabile 2.0.1.
2. Native Observability, documentazione: il costo del modulo (si apre in una nuova scheda). Le cifre 4,684, 1,795, 6,253 e 0,379 con le loro condizioni e la tabella di provenienza.
3. Native Observability, documentazione: configurazione (si apre in una nuova scheda) e installazione (si apre in una nuova scheda).
4. Native Observability 2.0.0, note di rilascio (si apre in una nuova scheda). Rimozione della stima a costanti, protocollo di misura appaiata, test dei segni.
5. Native Observability 2.0.0 Measures Its Own Performance Cost, The Drop Times (si apre in una nuova scheda). Censimento a livello di richiesta, 6,253 ms e scomposizione del flush differito.
6. APM Overheads: Is Your APM Slowing You Down?, groundcover (si apre in una nuova scheda). Il 3-5% nei benchmark dei fornitori, e la misura indipendente oltre il 44% su uno scenario Ruby.
7. Profiling Overhead and PHP 7, Tideways (si apre in una nuova scheda). Overhead misurato dal fornitore su PHP 5.6 e PHP 7, da 4,93% a 23,86%.
8. Configuring Blackfire Monitoring (si apre in una nuova scheda). «close-to-no overhead» sulle trace standard, fino al 15% misurato sulle Extended Traces.
9. PHP agent overhead reduction tips, New Relic (si apre in una nuova scheda). Assenza di una cifra dichiarata.
10. Agent Rate Limits, Datadog (si apre in una nuova scheda). Assenza di una cifra dichiarata; la pagina copre i limiti di frequenza dell'agente.
11. Robust benchmarking in noisy environments (si apre in una nuova scheda). Rumore del sistema operativo, riscaldamento, filtro degli anomali.
12. Make Drupal compatible with persistent app servers like ReactPHP, PHP-PM, PHPFastCGI, FrankenPHP, Swoole, core #2218651 (si apre in una nuova scheda). La classe di difetto della configurazione letta una volta per istanza.
13. Solving Big Data Challenges for Enterprise Application Performance Management, Rabl et al., VLDB 2012 (si apre in una nuova scheda). La soglia del 5% come regola pratica.