Non tutto il codice WP è codice pubblico
Se hai intenzione di rilasciare qualcosa di pubblico, allora tutte le cose che Kovshenin ha detto sono perfettamente valide.
Le cose sono diverse se hai intenzione di scrivere codice privato per te o la tua azienda.
La cache di oggetti esterni è un grande vantaggio, in ogni caso
Se possibile, è consigliabile impostare una cache di oggetti persistenti esterni .
Tutte le cose dette nella risposta di kovshenin sui transitori e MySQL sono molto vere, e considerando che WP stesso e un gruppo di plugin fanno uso della cache degli oggetti ... quindi il miglioramento delle prestazioni ottenuto, vale assolutamente il (piccolo) sforzo di installazione un moderno sistema di cache come Redis o Memcached.
I valori memorizzati nella cache potrebbero non essere presenti: va bene
Inoltre, sì, una cache di oggetti esterna non è affidabile. Non dovresti mai fare affidamento sul fatto che c'è un transitorio. È necessario assicurarsi che funzioni, se nella cache non sono dove dovrebbero essere.
La cache non è un archivio, la cache è cache.
Usa la cache in modo selettivo
Vedi questo esempio:
function my_get_some_value($key) {
// by default no cache when debug and if no external object_cache
$defUse = ! (defined('WP_DEBUG') && WP_DEBUG) && wp_using_ext_object_cache();
// make the usage of cache filterable
$useCache = apply_filters('my_use_cache', $defUse);
// return cached value if any
if ($useCache && ($cached = get_transient($key))) {
return $cached;
}
// no cached value, make sure your code works with no cache
$value = my_get_some_value_in_some_expensive_way();
// set cache, if allowed
$useCache and set_transient($key, $value, HOUR_IN_SECONDS);
return $value;
}
Utilizzando un codice come questo, nel tuo sito privato, le prestazioni del sito possono migliorare molto , specialmente se hai molti utenti.
Nota che:
- Per impostazione predefinita, la cache non viene utilizzata quando il debug è attivo, quindi si spera nel proprio ambiente di sviluppo. Credetemi, la cache può rendere il debug un inferno
- Per impostazione predefinita, la cache non viene utilizzata anche quando WP non è impostato per utilizzare una cache di oggetti esterna. Significa che non esiste tutto il problema connesso a MySQL, perché non si usa alcun transitorio quando usano MySQL. Un'alternativa probabilmente più semplice sarebbe quella di utilizzare le
wp_cache_*
funzioni , quindi se non è installata alcuna cache esterna, la cache si verifica in memoria e il database non è mai coinvolto.
- L'uso della cache è filtrabile, per gestire alcuni casi limite che potresti incontrare
No Webscale If No Cache
Non dovresti provare a risolvere i problemi di velocità con la cache. Se hai problemi di velocità, dovresti ripensare al codice.
Ma per ridimensionare un sito Web su Webscale, la cache è piuttosto richiesta .
E molte volte (ma non sempre) il frammento, la cache sensibile al contesto è molto più flessibile e adatto della cache aggressiva a pagina intera.
Le tue domande:
Dovrei usare l'API transitoria qui?
Dipende .
Il tuo codice sta consumando molte risorse? Altrimenti, forse non c'è bisogno di cache. Come detto, non è solo una questione di velocità. Se il tuo codice scorre veloce ma richiede un sacco di CPU e memoria per un paio di utenti ... cosa succede quando hai 100 o 1000 utenti simultanei?
Se ti rendi conto che la cache sarebbe una buona idea ..
... ed è codice pubblico: probabilmente no . Puoi considerare di memorizzare nella cache in modo selettivo, come nel mio esempio sopra nel codice pubblico, ma di solito è meglio se lasci tali decisioni agli implementatori.
... ed è un codice privato: molto probabilmente sì . Ma anche per il codice privato, memorizzare in cache in modo selettivo è comunque una buona cosa, ad esempio per il debug.
Ricorda, comunque, che le wp_cache_*
funzioni possono darti accesso alla cache senza il rischio di inquinare il database.
Devo usare l'API transitoria per memorizzare nella cache l'array $ related_posts o la stringa $ html_output?
Dipende da molte cose. Quanto sono grandi le corde? Quale cache esterna stai usando? Se hai intenzione di memorizzare nella cache i post, archiviare l'ID come array può essere una buona idea, interrogare un numero decente di post con il loro ID è abbastanza veloce.
Note finali
L'API transitoria è probabilmente una delle cose migliori di WordPress. Grazie ai plugin che puoi trovare per qualsiasi tipo di sistema cache, diventa una stupida semplice API per un gran numero di software che può funzionare sotto il cofano.
Al di fuori di WordPress, tale astrazione che funziona immediatamente con un sacco di diversi sistemi di memorizzazione nella cache e ti consente di passare da un sistema all'altro senza alcuno sforzo è molto difficile da trovare.
Raramente mi senti dire che WordPress è meglio di altre cose moderne, ma l'API transitoria è una delle poche cose che mi manca quando non lavoro con WordPress.
Sicuramente la cache è difficile, non risolve i problemi del codice e non è un proiettile d'argento, ma è qualcosa di cui hai bisogno per costruire un sito ad alto traffico che funzioni .
L'idea di WordPress di utilizzare una tabella MySQL non ottimizzata per fare cache è abbastanza folle, ma non è meglio tenersi alla larga dalla cache solo perché WordPress, per impostazione predefinita, lo fa.
Devi solo capire come funzionano le cose, quindi fare la tua scelta.