Spiegazione di update_post_ (meta / termine) _cache


23

Stavo leggendo alcune buone pratiche da 10up e menzionano l'impostazione di questi due flag su false in un WP_Query (a seconda di ciò che stai interrogando):

  • 'update_post_meta_cache' => false: utile quando post meta non verrà utilizzato.
  • 'update_post_term_cache' => false: utile quando i termini della tassonomia non verranno utilizzati.

Io parto dal presupposto che utilizzando qualcosa di simile update_post_caches(), ma io non sono nemmeno sicuro al 100% che cosa ciò significhi. Qualcuno potrebbe spiegare cosa significano queste due bandiere in WP_Queryae quanto sono utili? Più informazioni meglio è, dato che non so molto su come WordPress memorizza nella cache le cose, ma è accettabile anche una risposta ben ponderata su queste due bandiere.

Risposte:


30

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_Cacheclasse 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.phpe / 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_Queryc'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_Queryavviene update_meta_cacheper meta e in update_object_term_cacheper 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_cacheci sono 7 nidificatiforeach ... se hai molte tassonomie e il numero di post per pagina è elevato, questo non è molto efficace.

A proposito di questi WP_Queryargomenti, 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.


! Neat Come sempre la tua intuizione è sempre apprezzata GM. I transitori sarebbero considerati "cache persistente"? Quindi, per andare oltre, durante un WP_Query il motivo wp_reset_postdata()è reimpostare global $poste 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.
Howdy_McGee

1
@Howdy_McGee La cache degli oggetti e l'oggetto post non sono correlati. Quindi wp_reset_postdata()non fare nulla per quanto riguarda la cache degli oggetti. wp_reset_postdata()reimposta solo l'oggetto post globale, che è un'altra variabile globale, che non viene mai memorizzato nella cache ... I transitori sono una cosa ibrida: quando hai installato un plug-in cache persistente, usa quello transitorio, ma se non hai plug-in cache persistente, quindi i transitori usa il database.
gmazzap

Ah, mi sono appena aggrappato alla global variablenozione e ho pensato che fosse l' oggetto global $postglobale o $wp_query, grazie per il chiarimento!
Howdy_McGee

Su un sidenote , fields => 'ids'imposta entrambe le cache su false. Suppongo abbia senso che una cache degli oggetti funzioni solo sugli oggetti, ma ho pensato di fare solo una menzione: D
Howdy_McGee

3

Il principale punto di interesse qui è la update_post_cachesfunzione. Viene chiamato dopo che WP_Query ha ottenuto tutti i post dal DB. Di solito, il motivo per cui si desidera che i post siano in primo luogo visualizzati, il che significa solitamente visualizzare i termini e qualcosa in base ai metadati, pertanto WP_Query eseguirà anche una query predefinita sul DB per i dati relativi a meta e termini relativi ai post restituiti e lo memorizza nella cache *. Queste informazioni non sono esplicitamente disponibili nei dati restituiti da WP_Query, ma quando chiamerai le API pertinenti per ottenere il termine e le meta info di un post specifico, saranno già disponibili in memoria e non sarà necessario inviare un nuovo interrogare nel DB.

Ciò consente a wordpress di ridurre l'overhead relativo all'invio di richieste al DB inviando una sola richiesta per ottenere le informazioni per tutti i post anziché inviare una richiesta per ogni post.

In questo momento non riesco a trovare alcun esempio non banale di quando non vorrai aggiornare la cache, ma potrebbe essere banale se vuoi solo un elenco dei titoli di tutti i post. Per questo non hai bisogno di termini o metadati.

* cache - La cosa più importante qui è la cache basata sulla memoria in cui WP archivia quasi tutto ciò che ottiene dal DB anche senza avere alcun plug-in di cache degli oggetti attivo. Ovviamente, quando si dispone di cache degli oggetti, le informazioni verranno memorizzate anche lì.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.