Quando un cliente segnala schermate admin lente, checkout falliti o timeout casuali, le agenzie non possono permettersi il lusso di scavare in decine di tabelle o di analizzare all’inverso il comportamento dei plugin. È necessario riconoscere rapidamente i probabili punti di errore e concentrare l’attenzione dove è più importante.
In pratica, la maggior parte dei problemi gravi di prestazioni e di stabilità sono riconducibili a un piccolo numero di tabelle del database che crescono senza controllo nel tempo. Queste tabelle non causano problemi nei siti nuovi o a basso traffico, ma con anni di contenuti, plugin e attività degli utenti, sono responsabili di un numero sproporzionato di crash, query lente e ticket di assistenza.
Questo articolo si concentra su cinque tabelle (e schemi di tabelle) del database di WordPress che le agenzie che si occupano di manutenzione dovrebbero monitorare attivamente perché sono le più probabili cause di problemi di prestazioni reali con la crescita dei siti.
Perché le agenzie devono monitorare solo il 20% del database
Il principio di Pareto aiuta a spiegare molti modelli operativi e si applica anche alla manutenzione del database di WordPress. Le agenzie non riscontrano problemi in modo uniforme su tutto il database. Al contrario, un piccolo sottoinsieme di tabelle è responsabile della maggior parte dei rallentamenti, dei crash e dei ticket di assistenza urgenti legati al database.
Le installazioni standard di WordPress creano 12 tabelle predefinite. Alcune, come le tabelle wp_users, wp_links e le tabelle delle tassonomie, possono funzionare per anni senza causare problemi. In genere, queste non generano le query più lente che mandano in crash i siti durante i picchi di traffico.
Tuttavia, le tabelle ad alto rischio hanno una caratteristica in comune: possono mandare in tilt i siti in scala. Un sito con 100 post potrebbe funzionare bene con revisioni illimitate. Lo stesso sito, con 10.000 post e 300.000 voci di revisione, probabilmente andrà in timeout in ogni schermata di modifica. Un negozio di e-commerce con 50 prodotti dovrebbe funzionare bene, ma se si arriva a 5.000 prodotti il caricamento delle pagine può richiedere alcuni secondi.
Cinque schemi di database che causano il malfunzionamento dei siti WordPress in scala
Esaminiamo cinque schemi che compaiono frequentemente nel lavoro di manutenzione delle agenzie.
Non sono immediatamente problematici su siti di piccole dimensioni, ma con l’aumento dei contenuti, del traffico e dell’attività dei plugin, diventano le fonti più comuni di query lente, timeout e problemi di stabilità.
wp_options: il gonfiore di autoload potrebbe mandare in crash i siti ad alto traffico
La tabella wp_options memorizza le impostazioni del sito e le configurazioni dei plugin e determina quali opzioni WordPress carica a ogni richiesta di pagina (comprese le pagine in cache). Tra le colonne, autoload è la più importante:
WordPress carica per prima cosa tutte le opzioni autoload in memoria ad ogni richiesta. I siti con un’impronta di autoload più piccola riescono a gestire il traffico normalmente, anche se con l’aumentare dell’autoload, ogni visitatore consuma più memoria di quella che il server alloca per ogni processo PHP.
Se le dimensioni dell’autoload diventano troppo elevate (ad esempio, se superano i 3MB o più), si verificano schermate di amministrazione lente, fallimenti del checkout durante le vendite ed errori 502.
La colpa è quasi sempre delle impostazioni orfane dei plugin o delle voci temporanee della cache, note come transient. Con l’autoload abilitato, alcune opzioni di un plugin che hai cancellato potrebbero rimanere nella tabella wp_options, il che significa che vengono caricate a ogni richiesta. In decine di plugin per mesi o anni, si accumulano dati abbandonati che vengono caricati a ogni visualizzazione della pagina.
La Console SQL di Database Studio mostrata sopra permette di eseguire una query per verificare la dimensione dei dati autocaricati in byte:
SELECT 'autoloaded data in KiB' as name, ROUND(SUM(LENGTH(option_value))/ 1024) as value FROM wp_options WHERE autoload='yes'
UNION
SELECT 'autoloaded data count', count(*) FROM wp_options WHERE autoload='yes'
UNION
(SELECT option_name, length(option_value) FROM wp_options WHERE autoload='yes' ORDER BY length(option_value) DESC LIMIT 10)
Puoi utilizzare la console anche per eseguire altre query, come ad esempio ordinare i risultati della query iniziale.
Il tuo piano dovrebbe essere quello di esaminare i risultati, identificare le voci di autocaricamento più grandi e ripulirle (cioè eliminare le righe).
wp_postmeta: i siti di e-commerce possono andare in crash a causa dell’ingombro dei metadati
La tabella wp_postmeta contiene campi personalizzati per post, pagine e prodotti. Ogni volta che il contenuto viene salvato, possono essere aggiunte nuove voci di metadati. I plugin, in particolare, spesso aggiungono decine di campi a un singolo post o prodotto.
Ad esempio, WooCommerce memorizza i dati dei prodotti nella postmeta: variazioni, inventario, dettagli di spedizione e attributi. Un singolo prodotto con variazioni può generare decine di voci di metadati. I grandi cataloghi di prodotti creano potenzialmente milioni di righe di postmeta.
Il risultato di una tabella wp_postmeta sempre più grande è che le schermate di modifica faticano a caricare i dati, i filtri dei prodotti rallentano e le ricerche si bloccano nel tentativo di interrogare tabelle enormi. In generale, gli errori che si verificano durante i periodi di traffico elevato sono dovuti alle dimensioni elevate di wp_postmeta.
Utilizzando la console SQL, puoi eseguire query per selezionare ed eliminare i dati superflui simili a wp_options. Cerca aspetti come tabelle postmeta da molti gigabyte, molti duplicati meta_keys e metadati orfani in generale. Anche le opzioni di filtraggio di Database Studio sono utili in questo caso:
Ad esempio, puoi ordinare per meta_key cliccando sulla freccia della colonna. Questo raggruppa le chiavi identiche in modo da poter individuare gli schemi, come ad esempio le chiavi dei plugin cancellati o i campi personalizzati non utilizzati.
wp_posts: revisioni illimitate e crash delle schermate di modifica
La tabella wp_posts memorizza il contenuto e la cronologia delle revisioni. Per impostazione predefinita, WordPress salva ogni modifica come voce separata del database, quindi la modifica regolare dei contenuti genera una quantità significativa di dati extra. I siti con un’ampia cronologia di contenuti e modifiche possono accumulare migliaia di voci di revisione.
Inizialmente i siti funzionano bene, ma la presenza di molte revisioni memorizzate può causare un lento caricamento delle schermate di amministrazione durante la modifica dei post. WordPress salva ogni 60 secondi durante la modifica; anche i salvataggi automatici possono avere un impatto negativo perché lunghe sessioni di modifica creano decine di voci di salvataggio automatico.
È possibile sfoltire rapidamente la tabella delle revisioni di wp_posts (ad esempio):
Puoi quindi passare alla console SQL per eseguire una query ed eliminare le revisioni:
DELETE FROM wp_posts WHERE post_type="revision";
È una buona idea confrontare il numero di revisioni con i post pubblicati: rapporti a una cifra sono ragionevoli. Inoltre, controlla se le revisioni rappresentano più della metà delle voci totali, perché questo indica un probabile gonfiore. Le revisioni che aumentano di mese in mese suggeriscono la necessità di implementare dei limiti, che puoi ottenere con una rapida modifica di wp-config.php.
Tabelle dei plugin: i moduli e i log crescono fino a mandare in crash il sito
Quasi tutti i plugin creano tabelle di database personalizzate, ma è più comune con i plugin di moduli, ricerca e sicurezza. Questi possono continuare a crescere senza richiedere una manutenzione integrata.
In particolare, i plugin per i moduli memorizzano di default ogni invio in modo permanente. Per questo motivo, se i tuoi siti ricevono un traffico di invii costante nel corso degli anni, accumulerai migliaia di invii di moduli. Inoltre, le tabelle relative ai log crescono ancora più velocemente. I plugin di sicurezza registrano le azioni dei visitatori, i plugin di analisi tengono traccia delle pagine viste e gli strumenti di debug registrano gli errori.
Come nel caso di molti problemi con le tabelle del database, le pagine si bloccano, ma si verificano anche backup lenti del database e prestazioni degradate che non sono correlate al traffico. Il collegamento con il gonfiore del database non è sempre evidente perché i sintomi appaiono in aree non correlate.
Dovrai cercare le tabelle dei plugin che corrispondono o superano le dimensioni delle tabelle principali di WordPress; più sono grandi, più è importante ridurle. Una query SQL può individuare queste tabelle:
SELECT
TABLE_NAME AS `Table`,
ROUND((DATA_LENGTH + INDEX_LENGTH) / 1024 / 1024) AS `Size (MB)`
FROM
information_schema.TABLES
WHERE
TABLE_SCHEMA = "{database_name}"
ORDER BY
(DATA_LENGTH + INDEX_LENGTH)
DESC;
Se qualcuna di queste tabelle è orfana, puoi tranquillamente eliminarla. Tuttavia, anche se esula dallo scopo di questo post, se alcune tabelle sono abbastanza grandi da meritare una riduzione, ma sono ancora necessarie per il tuo sito, dovrai fare delle ricerche in merito, contattando eventualmente lo sviluppatore per un consiglio.
Action Scheduler: le attività fallite si accumulano e mandano in crash il checkout
Action Scheduler esegue essenzialmente attività in background per WordPress. Mette in coda le attività, le elabora in modo asincrono e memorizza i record di completamento in modo permanente per impostazione predefinita.
L’utilizzo di WooCommerce è un ottimo modo per capire come Action Scheduler possa causare problemi. Ad esempio, i timeout del gateway di pagamento causano azioni fallite che persistono nel database e vengono interrogate ad ogni caricamento di pagina per verificare la presenza di attività in sospeso. Puoi estrapolare una sola azione fallita dalle migliaia che un tipico negozio WooCommerce genera al mese.
Le Views di Database Studio possono aiutarti a eliminare queste azioni non riuscite:
Dai un titolo alla vista, scegli la tabella wp_actionscheduler_actions e clicca sul link Aggiungi condizione. In questo modo potrai mostrare solo le azioni non riuscite, rendendo più semplice la loro rimozione dal database.
Come gestire le tabelle importanti del database di WordPress in 10 minuti al mese
Al costo di pochi minuti al mese, puoi effettuare una minore gestione del database nel corso di un anno. Naturalmente, non dovrai monitorare o gestire molte delle tabelle del tuo database:
- La tabella
wp_usersraramente crea problemi, a meno che tu non gestisca siti di iscrizione con milioni di account. I dati degli utenti crescono in genere in modo lineare senza accumulare gonfiore. - Le tabelle delle tassonomie (come
wp_terms,wp_term_taxonomy,wp_term_relationships) spesso rimangono stabili indipendentemente dalle dimensioni del sito.
Tra le cinque tabelle problematiche, le grandi tabelle di wp_posts sui siti di contenuti sono tipiche e previste. Ricorda: i contenuti reali non sono “gonfiore”.
Impostazione del flusso di lavoro di monitoraggio
Esportare le tabelle del database permette di lavorare con i dati in altre applicazioni. Puoi farlo attraverso il menu a tendina con l’ellissi More Items per qualsiasi tabella:
Tuttavia, puoi fare molto in MyKinsta senza dover esportare. Puoi sfruttare al meglio il tuo tempo automatizzando la pulizia e rivedendo manualmente le metriche del tuo database. Le viste di Database Studio possono aiutarti a impostare l’analisi.
Ad esempio, puoi creare una vista personalizzata per monitorare wp_postmeta e aggiungere dei filtri per gli schemi specifici di meta_key che desideri monitorare:
Database Studio permette di creare e salvare snippet nella Console SQL, in modo da poter impostare una query SQL per ordinare tutte le tabelle in base alle dimensioni e accedervi ogni volta che ne hai bisogno:
Alcune delle tabelle più grandi dovrebbero essere wp_posts, wp_postmeta e wp_options. Dovrai indagare su tutte le tabelle che si posizionano più in alto.
L’esatto monitoraggio da impostare dipende dai siti e dalle tue esigenze. Tuttavia, ecco alcune aree da esaminare:
- Filtra
wp_optionsper gli autoload attivi, quindi controlla la dimensione totale (tramite query SQL o esportazione in CSV). Qualsiasi dimensione superiore a 1MB dovrebbe essere esaminata. - Controlla le dimensioni della tabella
wp_postmetarispetto a quelle del mese precedente, in particolare per verificare che non ci siano aumenti di dimensioni enormi. - Puoi filtrare post_type all’interno di
wp_postsper confrontare le revisioni con i post. Se necessario, imposta un limite all’interno diwp-config.php. - Per l’Action Scheduler, le azioni completate dovrebbero essere più numerose di quelle in sospeso o fallite.
In sintesi, usa Database Studio per creare le viste, i filtri e le query che userai spesso. Poi cerca le metriche “pericolose” e utilizza altri strumenti per automatizzare la pulizia. Ad esempio, il comando wp transient delete WP-CLI può aiutarti a eliminare i transient indesiderati all’interno del database.
Dalla correzione reattiva alla manutenzione proattiva del database
I problemi del database con cui le agenzie hanno a che fare più spesso non sono rari o imprevedibili. Sono il risultato di schemi familiari. La differenza tra reagire a questi problemi e prevenirli sta tutta nel focalizzarsi.
Non è necessario ispezionare ogni tabella o verificare ogni query. Devi sapere quali parti del database meritano un’attenzione costante e come individuare i primi segnali di allarme prima che si trasformino in interruzioni o in richieste di assistenza di emergenza.
Per le agenzie di manutenzione, questo cambia il modo in cui il lavoro sul database si inserisce nel flusso di lavoro. Invece di considerare la pulizia del database come una soluzione una tantum dopo un guasto, questa diventa un controllo leggero e ripetibile.
Se ti imbatti in un problema del database che non riesci a risolvere, soprattutto se emerge solo sotto carico, è importante avere il giusto supporto. Per i siti ospitati su Kinsta, il nostro team di supporto è disponibile 24 ore su 24, 7 giorni su 7, per aiutarti.
