Cache oggetti ovunque
WordPress tenta di ridurre il numero di query del database il più possibile.
Ad esempio, ogni volta che si ottiene un metacampo o un campo di tassonomia, prima di interrogare il database, WordPress verifica se quello è già stato interrogato e memorizzato nella cache e lo restituisce da lì invece di interrogare il database.
Il "processo cache" viene eseguito tramite la WP_Object_Cache
classe e le wp_cache_*
funzioni (che sono wrapper per i metodi di quella classe.)
Dove vive la cache
Per impostazione predefinita, la "cache" non è altro che una variabile globale PHP. Significa che è in memoria, ma significa anche che svanisce ad ogni richiesta.
Tuttavia, tramite dropins ( advanced-cache.php
e / o object-cache.php
), è possibile impostare un modo personalizzato per gestire questa cache.
Di solito, questi dropins vengono utilizzati per impostare una sorta di meccanismo di memorizzazione nella cache che "sopravvive" alle singole richieste.
Per questo motivo, tra le persone WP, questi sono conosciuti come plug-in "cache persistente" (anche se al di fuori della bolla le parole "cache" e "persistente" non hanno molto senso insieme).
Le scelte più popolari al giorno d'oggi sono Memcached o Redis .
Pertanto, utilizzando i plug-in "cache persistente" è possibile ridurre drasticamente il numero di query del database, poiché la cache non viene aggiornata su ogni richiesta.
Qualche esempio
$foo = get_post_meta('foo', $post_id, true);
// a lot of code in the middle
$bar = get_post_meta('bar', $post_id, true);
Le 2 righe di codice sopra attiveranno, al massimo, 1 query sul database.
Infatti, quando si esegue una query su un campo personalizzato, tutti i campi per quel post vengono recuperati dal database, memorizzati nella cache tramite la cache degli oggetti e le richieste successive estraggono i dati dalla cache e non da db.
Lo stesso accade per i termini di tassonomia, WordPress estrae tutti i termini per una tassonomia una volta, quindi li restituisce dalla cache.
La cache degli oggetti è ampiamente utilizzata in WordPress. Non solo per post, meta valori e tassonomie, ma anche per utenti, commenti, dati sui temi ...
Cosa WP_Query
c'entra tutto questo?
Quando esegui query su alcuni post tramite WP_Query
, per impostazione predefinita, WordPress non li estrae solo dal database (o dalla cache se sono memorizzati nella cache), ma aggiorna anche la cache per tutti i campi personalizzati e tutte le tassonomie correlate ai post estratti.
Quindi, quando chiami, ad esempio, get_the_terms()
o get_post_meta()
mentre i messaggi di looping sono passati WP_Query
, in realtà non attivi alcuna query sul database, ma estrai informazioni dalla cache.
Bello no?
Bene, sì, ma ha un costo.
L'aggiornamento della cache "magico" che WordPress fa quando si inseriscono messaggi WP_Query
avviene update_meta_cache
per meta e in update_object_term_cache
per tassonomie.
Se guardi il codice sorgente di quelle funzioni, vedrai che lì WordPress esegue solo una query db in ciascuna funzione, ma esegue anche molta elaborazione. Ad esempio, update_object_term_cache
ci sono 7 nidificatiforeach
... se hai molte tassonomie e il numero di post per pagina è elevato, questo non è molto efficace.
A proposito di questi WP_Query
argomenti, finalmente
Cosa fare 'update_post_meta_cache'
e 'update_post_term_cache'
quando impostato su false
è impedire a WordPress di aggiornare la cache per i campi personalizzati e le tassonomie, rispettivamente.
In tal caso, alla prima query di un campo personalizzato o di una tassonomia viene attivata una query del database e i dati vengono memorizzati nella cache.
Ne vale la pena?
Come al solito, la risposta è che dipende . Il più delle volte su cui impostare questi valori false
è una buona scelta, perché impedisce l'elaborazione non necessaria e le query del database se non necessarie, e la cache viene aggiornata comunque i primi campi personalizzati / termini di tassonomia richiesti.
Tuttavia, se hai intenzione di chiamare, anche una volta, get_post_meta()
durante il ciclo e hai intenzione di chiamare get_the_terms()
per tutte (o la maggior parte) delle tassonomie supportate dai post, l'aggiornamento della cache viene comunque attivato e potrebbe non esserci alcun vantaggio effettivo su impostando tali argomenti di query su false
.
wp_reset_postdata()
è reimpostareglobal $post
e reimpostare la cache degli oggetti? Sembra che se avessi creato un WP_Query personalizzato, avrei creato un nuovo oggetto memorizzato nella cache, ma per ripristinarlo avrebbe dovuto richiedere nuovamente la cache originale. O forse sto andando troppo lontano nel contesto di questa domanda.