Indice dei contenuti dell'articolo:
Query Monitor è probabilmente uno degli strumenti più utili a disposizione di chi sviluppa, gestisce o ottimizza un sito WordPress. Permette di osservare cosa accade durante l’esecuzione di una pagina, individuare query SQL lente o duplicate, analizzare errori PHP, controllare hook, chiamate HTTP, script, fogli di stile e numerosi altri aspetti che normalmente rimarrebbero nascosti.
Il problema, quindi, non è Query Monitor. Il problema è come viene utilizzato.
Negli anni abbiamo visto consolidarsi una cattiva abitudine piuttosto diffusa: installare Query Monitor per effettuare una verifica, attivarlo e poi dimenticarsene. Il plugin rimane così presente e operativo per settimane, mesi o addirittura permanentemente, anche quando nessuno sta realmente analizzando i dati che raccoglie.
È un approccio concettualmente sbagliato.
Query Monitor dovrebbe essere considerato alla stregua di uno strumento diagnostico: si attiva quando è necessario osservare il funzionamento di WordPress, si raccolgono le informazioni necessarie, si individua il problema e, terminata la diagnosi, lo si disattiva.
Perché, prendendo in prestito una regola che nel Poker assume un significato molto concreto, vedere ha un prezzo.
Nel Poker vedere ha un prezzo. Anche nel debugging
Al tavolo da Poker non è possibile continuare a vedere gratuitamente cosa hanno in mano gli altri giocatori. Per ottenere informazioni bisogna pagare, chiamare una puntata, mettere qualcosa nel piatto.
Nel debugging software il principio non è molto diverso.
Raccogliere informazioni ha un costo computazionale.
Se vogliamo conoscere il numero delle query eseguite, dobbiamo intercettarle e registrarle. Se vogliamo sapere quale componente ha generato una determinata query, dobbiamo raccogliere ulteriori informazioni. Se vogliamo analizzare errori PHP, hook, chiamate HTTP, template, script e altri eventi che si verificano durante la richiesta, dobbiamo necessariamente introdurre uno strato di osservazione.
Query Monitor svolge questo lavoro in maniera estremamente efficace e con un overhead generalmente contenuto, ma questo non significa che il costo sia matematicamente pari a zero.
Osservare un sistema significa inevitabilmente utilizzare una parte delle risorse di quel sistema.
Ed è qui che bisogna distinguere tra uso e abuso.
Come funziona Query Monitor
Quando Query Monitor è attivo, WordPress mette a disposizione dell’amministratore una serie di informazioni relative alla richiesta corrente. Nella barra di amministrazione vengono mostrati immediatamente alcuni indicatori utili, tra cui il tempo necessario alla generazione della pagina, il picco di memoria utilizzata, il tempo complessivamente impiegato dalle query SQL e il loro numero.
Aprendo i relativi pannelli è possibile entrare molto più in profondità nell’analisi.
Query Monitor può infatti mostrare, tra le altre cose:
- le query SQL eseguite durante la richiesta e il relativo tempo di esecuzione;
- query lente, duplicate o contenenti errori;
- il plugin, il tema o la funzione responsabile di determinate query;
- errori PHP, warning, notice e utilizzo di funzioni deprecate;
- hook, action e filter coinvolti nell’esecuzione;
- richieste effettuate attraverso le HTTP API di WordPress;
- script e fogli di stile caricati con le relative dipendenze;
- template e parti di template utilizzate;
- informazioni sull’ambiente PHP, WordPress, database e web server;
- conditional tag e altre informazioni relative alla richiesta corrente.
È quindi molto più di un semplice contatore di query.
Query Monitor costruisce una vera e propria radiografia della richiesta WordPress, cercando di mettere in relazione gli eventi osservati con i componenti che li hanno generati.
Ed è precisamente questa capacità di osservazione a renderlo prezioso durante una diagnosi.
Per raccogliere informazioni bisogna fare del lavoro
Uno degli errori più comuni consiste nel pensare che, siccome il pannello di Query Monitor è visibile soltanto all’amministratore autorizzato, allora il suo funzionamento sia completamente gratuito dal punto di vista delle risorse.
Non è questo il modo corretto di ragionare.
Per presentare informazioni diagnostiche Query Monitor deve collegarsi a diversi punti dell’esecuzione di WordPress, raccogliere dati, organizzarli e conservarli abbastanza a lungo da poterli successivamente mostrare e analizzare.
Su un sito sano e relativamente semplice questo overhead può essere piccolo e difficilmente percepibile. Ma un overhead piccolo non equivale a nessun overhead.
La differenza diventa particolarmente interessante proprio nei siti sui quali Query Monitor viene utilizzato più spesso: quelli che hanno già un problema.
Immaginiamo una pagina WordPress che esegua centinaia di query SQL, generi numerosi warning, effettui molte chiamate verso API esterne oppure carichi una quantità anomala di componenti. Query Monitor dovrà raccogliere una mole di informazioni decisamente maggiore rispetto a quella necessaria per analizzare una semplice pagina che esegue poche decine di query.
Di conseguenza, più il sistema da diagnosticare è complesso o patologico, maggiore può diventare il costo della sua osservazione.
Il paradosso: Query Monitor può pesare di più proprio quando il sito ha problemi
Questo aspetto merita particolare attenzione.
Un sito WordPress già vicino al proprio limite di memoria PHP, con un numero eccessivo di query o con numerosi eventi da monitorare, parte da una situazione di scarsità di risorse.
Attivando uno strumento diagnostico gli chiediamo contemporaneamente di continuare a eseguire il normale carico applicativo e di registrare informazioni su ciò che sta accadendo.
È il motivo per cui, in determinate situazioni, Query Monitor può contribuire ad aumentare l’utilizzo della memoria o il tempo necessario alla generazione della pagina.
Questo non rappresenta un difetto concettuale di Query Monitor. È una conseguenza naturale dell’instrumentation e del profiling.
Succede anche in altri ambiti sistemistici: abilitare logging estremamente verboso, tracing, profiler o modalità di debug comporta un costo. Sono funzionalità preziose quando dobbiamo cercare un problema, ma non necessariamente configurazioni da mantenere permanentemente senza uno scopo.
Il debug è uno stato operativo, non dovrebbe diventare lo stato normale del sistema.
Il rischio di misurare un sito alterando ciò che stiamo misurando
C’è inoltre un altro problema importante, soprattutto quando Query Monitor viene utilizzato per effettuare confronti prestazionali.
Se vogliamo conoscere le prestazioni reali di una determinata configurazione WordPress, dobbiamo cercare per quanto possibile di misurarla nelle condizioni nelle quali verrà effettivamente utilizzata.
Tenere attivo uno strumento diagnostico durante ogni test può introdurre un overhead che finisce per alterare parzialmente il dato che vogliamo misurare.
Non significa che i numeri mostrati da Query Monitor siano inutili. Al contrario: sono estremamente utili per capire dove WordPress spende tempo e quali componenti intervengono durante una richiesta.
Bisogna però distinguere due domande differenti.
La prima è: “Cosa sta facendo WordPress durante questa richiesta?”
Per rispondere, Query Monitor è uno strumento eccellente.
La seconda è: “Qual è la performance reale del sito in produzione senza instrumentation?”
Per rispondere seriamente a questa domanda bisogna anche effettuare misurazioni con Query Monitor disattivato e utilizzare strumenti di benchmark adeguati.
Installato non significa necessariamente da lasciare attivo
Esiste poi un equivoco tipico dell’ecosistema WordPress: se un plugin ci è utile, allora deve necessariamente rimanere sempre attivo.
Non è così.
Ci sono plugin che rappresentano parte integrante del funzionamento applicativo del sito e che devono evidentemente restare attivi. Un plugin di caching, un’estensione WooCommerce necessaria al checkout o una funzione applicativa personalizzata appartengono normalmente a questa categoria.
Query Monitor ha invece uno scopo differente.
È uno strumento tecnico di osservazione e troubleshooting.
Non è necessario cancellarlo ogni volta. Può tranquillamente rimanere installato e disattivato, pronto a essere riattivato quando serve effettuare una diagnosi.
Quello che ha poco senso è lasciarlo attivo per mesi semplicemente perché “potrebbe tornare utile”.
Quando tornerà utile, bastano pochi secondi per attivarlo.
Il modo corretto di utilizzare Query Monitor
Una procedura sensata è molto semplice.
Quando viene segnalato un problema di lentezza, un comportamento anomalo o un errore, si attiva Query Monitor e si riproduce il problema nelle condizioni necessarie.
A quel punto si osservano i dati realmente pertinenti alla diagnosi: query SQL, tempi, chiamate HTTP, errori, componenti responsabili, hook o qualsiasi altra informazione utile.
Si individua quindi la causa del problema, si applica eventualmente una modifica e si ripete il test per capire cosa è cambiato.
Infine si effettua una verifica prestazionale anche senza Query Monitor.
Terminato il lavoro, il plugin può essere nuovamente disattivato.
In sintesi:
- attivare Query Monitor quando esiste qualcosa da osservare;
- raccogliere le informazioni necessarie alla diagnosi;
- correggere il problema individuato;
- verificare nuovamente il comportamento del sito;
- disattivare Query Monitor quando la fase diagnostica è conclusa.
È un modello operativo semplice, pulito e perfettamente coerente con il ruolo dello strumento.
Query Monitor in produzione: sì, ma quando serve
Questo non significa sostenere che Query Monitor non debba mai essere attivato su un sito di produzione.
Ci sono problemi che compaiono esclusivamente in produzione e che non possono essere riprodotti facilmente in staging. In questi casi poter osservare direttamente la richiesta reale può essere estremamente utile.
L’importante è comprendere la differenza tra attivazione consapevole e attivazione permanente per inerzia.
Attivarlo su un sito in produzione per indagare un problema specifico, raccogliere i dati necessari e successivamente disattivarlo è un utilizzo perfettamente sensato.
Lasciarlo attivo indefinitamente soltanto perché “tanto non dà fastidio” è invece una scelta molto più discutibile.
In particolare su installazioni WordPress molto complesse, WooCommerce con molte estensioni, backend pesanti o sistemi che stanno già eseguendo centinaia di query per richiesta, ogni strato diagnostico aggiuntivo dovrebbe essere utilizzato con una precisa finalità.
Il problema non è lo strumento, ma l’assenza di disciplina operativa
Nella sistemistica esiste una differenza enorme tra avere molti strumenti e sapere quando utilizzarli.
Log dettagliati, profiler, debugger, tracing e strumenti di diagnostica sono indispensabili quando qualcosa non funziona. Ma mantenere indiscriminatamente ogni livello di debug permanentemente abilitato non rende necessariamente un sistema più controllato.
Spesso lo rende semplicemente più complesso.
Lo stesso principio dovrebbe essere applicato a WordPress.
Un ambiente di produzione dovrebbe contenere e mantenere attivi i componenti necessari al suo normale funzionamento. Gli strumenti utilizzati esclusivamente per attività di sviluppo e troubleshooting dovrebbero essere impiegati quando esiste una ragione concreta per farlo.
Questo approccio permette anche di evitare situazioni paradossali nelle quali si sta cercando di ottimizzare WordPress mentre contemporaneamente si mantengono attivi plugin e modalità diagnostiche di cui nessuno sta leggendo i risultati.
“Ma Query Monitor incide pochissimo”: non è questo il punto
Una possibile obiezione è che Query Monitor sia progettato con attenzione e che nella maggior parte delle installazioni il suo overhead sia ridotto.
È vero, ed è importante dirlo.
Query Monitor non deve essere demonizzato e non avrebbe senso presentarlo come un plugin che, da solo, trasforma necessariamente un sito veloce in un sito lento.
Il punto è un altro.
Se una funzionalità diagnostica non ci serve in quel momento, perché pagarne anche un piccolo costo?
Su una singola richiesta la differenza può essere trascurabile. Su una pagina patologica con centinaia di query, numerosi errori, chiamate HTTP o una quantità importante di informazioni da raccogliere, l’effetto può diventare più evidente, soprattutto in termini di memoria.
E soprattutto non c’è alcun vantaggio concreto nel sostenere quel costo quando nessuno sta analizzando i dati prodotti.
È esattamente il significato dell’espressione “vedere ha un prezzo”. Non significa che il prezzo sia sempre alto. Significa che il prezzo esiste e deve esserci una ragione per pagarlo.
Conclusioni: attivatelo, usatelo, poi spegnetelo
Il messaggio finale è quindi estremamente semplice.
Usate Query Monitor. È uno strumento eccellente per diagnosticare problemi WordPress, comprendere query SQL, individuare errori, analizzare chiamate HTTP e capire quali componenti partecipano alla generazione di una pagina.
Ma utilizzatelo consapevolmente.
Non lasciatelo permanentemente attivo su un sito semplicemente perché è stato installato durante un’attività di troubleshooting sei mesi prima e nessuno si è più ricordato di disattivarlo.
Non confondete inoltre una richiesta eseguita sotto instrumentation con un benchmark neutrale delle performance reali del sito. Usate i dati di Query Monitor per capire dove e perché WordPress sta lavorando, quindi confermate il risultato finale anche nelle normali condizioni operative.
La buona sistemistica non consiste nell’accendere ogni strumento disponibile e lasciarlo acceso per sempre. Consiste nel sapere quale strumento utilizzare, quando utilizzarlo e quando non serve più.
Query Monitor non fa eccezione.
Perché anche nel debugging, esattamente come al tavolo da Poker, vedere ha un prezzo.
