Tasso di successo della cache degli oggetti di WordPress: significato e valori target significativi

Cosa memorizza la cache degli oggetti di WordPress

Il sito Cache degli oggetti di WordPress memorizza i dati associati a una chiave e all'interno di un gruppo. Se WordPress richiede nuovamente lo stesso valore, può recuperarlo dalla cache invece di eseguire nuovamente l'operazione sottostante. Tra questi vi sono, ad esempio, i dati che altrimenti dovrebbero essere letti dal database o ricalcolati.

L'implementazione Core integrata è, per impostazione predefinita, legato alla richiesta: Mantiene i dati memorizzati per la durata di una singola richiesta. Una successiva visualizzazione della pagina non ha quindi automaticamente accesso ai valori memorizzati in precedenza. Ciononostante, la cache è in grado di evitare accessi ripetuti già all’interno di una singola richiesta.

Un drop-in può sostituire l'implementazione di base con un Cache degli oggetti persistenti sostituire. In questo modo, le voci appropriate possono essere conservate anche al di là delle singole richieste. Redis è una possibile opzione di backend, ma non è un requisito indispensabile per WordPress; sono possibili anche altri approcci di backend. Anche con un drop-in persistente, determinati gruppi possono continuare ad applicarsi solo alla richiesta corrente.

I transienti rappresentano un’ulteriore possibilità per memorizzare dati necessari solo per un periodo limitato. Grazie a una cache di oggetti persistente, possono essere salvati lì, senza dover ricorrere normalmente al database. La loro durata non indica una disponibilità minima garantita: un valore può scomparire prima del previsto. Il codice dell’applicazione deve quindi tenere conto della possibile assenza di un transiente ed essere in grado di rigenerare il valore se necessario.

Questa distinzione è fondamentale per la successiva valutazione di un tasso di successo: l'accesso alla cache locale durante una richiesta e l'accesso a un backend esterno non sono necessariamente lo stesso parametro di misurazione. Verifica quindi innanzitutto quale implementazione viene effettivamente utilizzata e quali dati vengono trattati in modo persistente.

Distinguere tra cache degli oggetti e cache delle pagine

Quando si visualizza una pagina, può verificarsi un Cache di pagina fornire una risposta alla pagina già generata. Se la richiesta riceve risposta in quella sede, non è necessario che segua lo stesso percorso dell’applicazione WordPress di una richiesta non memorizzata nella cache. La cache degli oggetti, invece, opera all’interno dell’applicazione con singoli dati memorizzati nella cache, non con la risposta completa alla pagina.

Immagina una pagina di articolo accessibile pubblicamente: se la risposta si trova nella cache della pagina, può essere fornita direttamente. Se invece WordPress deve generare la pagina, la cache degli oggetti può essere d’aiuto in caso di accessi ripetuti ai dati. Il carico di lavoro effettivamente risparmiato dipende dalla richiesta, dai dati memorizzati e dalla specifica implementazione.

Ciò ha delle conseguenze sull’interpretazione: un buon tasso di cache degli oggetti descrive solo gli accessi alla cache registrati. Non indica direttamente quanti visitatori ricevano già una risposta pronta dalla cache delle pagine né quanto velocemente reagisca l’intero sito web. In caso di caching delle pagine molto intenso, i vantaggi della cache degli oggetti possono diventare evidenti soprattutto nelle richieste WordPress rimanenti.

Anche la cache del browser e quella dell'opcode svolgono altre funzioni. La cache del browser mantiene le risorse a disposizione dell'utente; una cache dell'opcode PHP memorizza il codice PHP compilato. Nessuna delle due sostituisce né la memorizzazione dei singoli dati dell'applicazione nella cache degli oggetti né la fornitura di una risposta completa dalla cache della pagina.

La costante WP_CACHE Da sola, questa opzione non attiva la cache degli oggetti Redis. Per ottenere una cache degli oggetti persistente, è necessaria un’implementazione adeguata e la relativa configurazione supportata. Un ulteriore esempio dell’interazione tra diversi livelli è disponibile nell’articolo dedicato a Motore di cache AccelerateWP.

Cosa ci dicono i successi e i fallimenti

A Colpire si verifica quando una voce ricercata viene trovata nel livello di cache considerato. Un Signorina significa che lì non viene rilevato. Il tasso di successo mette in rapporto i risultati positivi con il totale dei risultati positivi e negativi registrati: risultati positivi / (risultati positivi + risultati negativi) × 100. Se non vi sono né risultati positivi né negativi, il tasso per quel periodo non è definito.

Un errore non è automaticamente un errore tecnico. Al primo accesso, una voce potrebbe ancora mancare; anche dopo la sua scadenza, potrebbe essere necessario recuperarla o generarla nuovamente. Ciò che conta è quali conseguenze abbiano tali tentativi falliti nel flusso concreto delle operazioni e se abbia senso ripetere gli accessi.

Il metodo Core di WordPress, nella propria implementazione, conta i risultati positivi della cache e i tentativi falliti. Tuttavia, un plug-in drop-in può sostituire questa implementazione. Pertanto, non è possibile dedurre con certezza dal sistema di conteggio del core quali visualizzazioni vengano registrate da un plug-in: verifica, per la versione in uso, quali accessi e quale periodo di tempo siano inclusi nelle statistiche.

Redis segnala con keyspace_hits e keyspace_misses ricerche di chiavi andate a buon fine o fallite nello spazio delle chiavi di Redis. Anche una ricerca fallita EXISTS-Il fallo può essere considerato un errore. Questo Tasso di successo di Redis non è quindi automaticamente equiparabile a una quota relativa a WordPress o a un plugin.

Se un'istanza di Redis è utilizzata da più siti web o applicazioni, i suoi contatori possono riflettere complessivamente le visite di tutti questi siti. In tal caso, senza un'adeguata telemetria separata, non è possibile attribuire in modo attendibile una quota globale a un singolo sito WordPress. Per ogni confronto, dovresti quindi specificare a quale livello e a quale istanza si riferiscono i dati.

Verificare con attenzione il campo di misura e l'accesso

Prima di effettuare la misurazione, verifica quale implementazione della cache degli oggetti utilizza WordPress. Se WP-CLI è disponibile e hai accesso alla directory di WordPress, puoi avviare un’analisi di inventario in sola lettura con il seguente comando:

wp cache type

Il risultato aiuta a classificare l'implementazione, ma non dimostra che ogni accesso rilevante venga memorizzato in modo persistente. WordPress consente a un drop-in di sostituire la cache del core; allo stesso tempo, i singoli gruppi potrebbero non essere persistenti. Per questo motivo, è importante annotare anche il drop-in o il plugin utilizzato e la relativa versione.

Verifica nella documentazione della versione specifica quali accessi comprendono gli “hit” e i “miss” visualizzati e in quale arco di tempo vengono conteggiati. È possibile confrontare in modo significativo la quota di un plugin con un altro indicatore solo se si conoscono l’ambito di misurazione e il metodo di conteggio. È particolarmente importante stabilire se la visualizzazione descrive solo una richiesta o un intervallo di tempo più lungo.

Per Redis, purché siano disponibili la connessione e le autorizzazioni, è possibile interrogare in modalità di sola lettura le statistiche e le informazioni sulla memoria in una sessione della CLI di Redis. I comandi seguenti non contengono volutamente alcuna credenziale di accesso:

INFO stats
INFO memory

Documenta il Campo di misura: Quali istanze o nodi sono stati interrogati e quali altri siti web o applicazioni li utilizzano? I contatori globali di Redis, se condivisi, non possono essere facilmente attribuiti a un singolo sito web. Verifica che i risultati non contengano informazioni operative sensibili prima di divulgarli; per questa analisi non è necessario né un flush né un test di carico.

Se non hai accesso alla CLI di Redis, chiedi al tuo provider di hosting quali sono le metriche disponibili e il loro ambito di applicazione. Anche una dashboard è una base utile solo se è chiaro se mostra la stessa istanza, singoli nodi o valori già aggregati.

Calcolare la percentuale di successo di Redis in un intervallo

Le statistiche di Redis sono semplici conteggi, non rappresentano un'analisi completa relativa a un determinato periodo di misurazione. Per un'analisi a intervalli, consulta i valori relativi a keyspace_hits e keyspace_misses all'inizio e alla fine dello stesso intervallo di tempo definito dalla stessa istanza. Annota entrambi i momenti e l'istanza corrispondente, in modo che le letture corrispondano.

Successivamente, per ogni contatore, sottrai il valore iniziale dal valore finale. Il Tasso di successo per intervallo è dato da: ΔHits / (ΔHits + ΔMisses) × 100. Il simbolo Δ indica la rispettiva differenza. Se entrambe le differenze sono pari a zero, in quella finestra non sono state registrate ricerche; in tal caso, il rapporto non è definito, anziché essere pari allo zero per cento.

Un esempio di calcolo illustrativo, non una misurazione: se gli “hit” aumentano di 900 e i “miss” di 100, si ottiene il 90% su un totale di 1.000 ricerche conteggiate. Ciò non significa né che le pagine siano più veloci del 90 per cento, né che siano state risparmiate esattamente 900 interrogazioni del database. Redis conta le ricerche per chiave; la loro importanza per l’applicazione dipende dal tipo di accesso specifico.

Se uno dei contatori diminuisce tra una lettura e l'altra, la semplice differenza calcolata tramite questa frazione non è valida. Ciò può essere causato da un riavvio o dal ripristino delle statistiche. Ricomincia la finestra di misurazione oppure suddividila in base a dati operativi affidabili in corrispondenza della frattura, invece di inserire un valore negativo nella formula.

In presenza di più nodi, calcola innanzitutto le differenze per ciascuno dei nodi corrispondenti nello stesso periodo. Somma quindi separatamente gli “hit” e i “miss” e calcola da questi il tasso complessivo. Una media non ponderata delle singole percentuali tratta un nodo con poche ricerche esattamente come uno con molte; ciò può distorcere notevolmente il quadro complessivo.

Tieni presente quali nodi sono effettivamente coinvolti e quale ruolo svolgono nell’ambiente. Un tasso complessivo calcolato in questo modo descrive solo i contatori selezionati e i relativi utenti; non si traduce automaticamente in una quota specifica della cache degli oggetti di WordPress.

Protocollo di misurazione e indicatori Redis

Oltre ai successi e agli insuccessi, altri indicatori Redis aiutano a inquadrare la situazione. Anche in questo caso, le differenze nel periodo di riferimento scelto sono più significative rispetto ai dati complessivi considerati isolatamente. La tabella seguente distingue il significato dei valori dalle conclusioni che essi, da soli, non possono sostenere.

Un aumento di expired_keys può essere un motivo per esaminare più da vicino la durata di vita e i modelli di accesso. Tuttavia, non indica se una voce sia stata nuovamente richiesta poco dopo la sua scadenza. Allo stesso modo, evicted_keys da considerare nel contesto del limite di memoria configurato e della strategia di sostituzione, anziché dedurne immediatamente un aumento della memoria.

Un utile Protocollo di misurazione Indica l'inizio e la fine dell'intervallo di tempo, l'istanza o il nodo, le due differenze tra i contatori, la loro somma e il rapporto calcolato. Specifica se l'istanza è condivisa e se durante l'intervallo si è verificato un riavvio o un ripristino. In questo modo le misurazioni rimarranno tracciabili in seguito.

Registra contemporaneamente il tipo di richiesta in esame e un indicatore di latenza adeguato, nonché il carico del database e il tasso di errore. Ad esempio, distingue le visualizzazioni delle pagine pubbliche dalle richieste degli utenti registrati, se sono disponibili dati pertinenti. La quota Redis da sola non rivela quale di questi tipi di richiesta abbia beneficiato di un risultato positivo.

Ai fini di un confronto successivo, il periodo di tempo, i nodi e la composizione delle richieste dovrebbero essere il più possibile simili. Annota inoltre le modifiche rilevanti e le fasi di riscaldamento individuabili. Laddove manchino dati o un’istanza condivisa non consenta alcuna attribuzione, tale limitazione va riportata nel verbale anziché in una conclusione apparentemente precisa.

Avvio a freddo, negozio online e sito web statico

Dopo un riavvio o un’implementazione, le voci necessarie potrebbero inizialmente mancare. Tali mancati riscontri sono prevedibili durante il popolamento della cache; in caso di accessi ripetuti, la percentuale di riscontri positivi può successivamente aumentare. I valori provenienti dalla Fase a freddo e fase a caldo dovresti considerarlo separatamente, in modo che una media a lungo termine non nasconda né i costi iniziali né l'andamento successivo.

Nel caso di un negozio online o di un’area riservata agli utenti registrati, le richieste dinamiche rivestono particolare importanza: una cache di pagina non risponde necessariamente a ogni richiesta relativa al carrello o all’account. Confronta quindi tipi di richieste il più possibile simili e, oltre alla percentuale, presta attenzione ai loro tempi di risposta e al carico sul database. Un elevato tasso di successo di Redis, di per sé, non indica se il carrello venga visualizzato rapidamente e con contenuti corretti.

Nel caso di un sito web prevalentemente statico, invece, gran parte delle visualizzazioni delle pagine può già provenire dalla cache delle pagine. Una cache degli oggetti persistente agisce in questo caso soprattutto sulle richieste che WordPress elabora effettivamente. Valuta quindi separatamente se queste richieste rimanenti ne traggono vantaggio e se l'effetto si ripercuote sull'intero sito web.

Se utilizzi Redis insieme ad altri siti web o applicazioni, il contatore delle istanze include anche i loro accessi. Senza un'adeguata telemetria separata, non è possibile attribuire in modo affidabile la quota globale a un singolo sito web. Documenta anche quali nodi vengono monitorati: in caso contrario, una variazione della quota potrebbe essere dovuta anche a un diverso utilizzo o a un cambiamento nell'ambito di misurazione.

Analizzare i valori anomali e gli errori

Un tasso basso è innanzitutto un’osservazione, non una diagnosi. Tra le possibili spiegazioni figurano un numero elevato di accessi iniziali, durate brevi o una distribuzione degli accessi con chiavi raramente riutilizzate. Verifica se la composizione delle richieste o la finestra di misurazione è cambiata prima di modificare le impostazioni di memoria o della cache.

I contatori expired_keys e evicted_keys forniscono ulteriori indicazioni: il primo conta le chiavi scadute, il secondo quelle sovrascritte a causa del limite di memoria. Le loro differenze dipendono dall’istanza Redis e devono essere adeguate alla configurazione e all’utilizzo. La presenza di molte chiavi scadute non dimostra né che il TTL sia stato scelto in modo errato, né che una durata maggiore sia opportuna; essa può infatti compromettere l’attualità dei dati memorizzati.

Per le proprie estensioni, in wp_cache_get il parametro $found Importante: distingue tra un valore trovato e uno salvato false da una voce non trovata. Prima di eseguire operazioni relative ai gruppi, dovresti utilizzare wp_cache_supports verificare se il backend specifico supporti la funzione desiderata. Un drop-in sostitutivo può differire dall'implementazione di base.

Avviso: Uno svuotamento incauto della cache può interessare più voci o applicazioni di quanto previsto e distorcere la misurazione successiva a causa di un avvio a freddo. Verifica l’ambito di applicazione e ottieni l’autorizzazione prima di eseguire operazioni di cancellazione. Ulteriori spunti per la Risoluzione dei problemi in caso di cache degli oggetti di WordPress lenta contribuire a includere nell'analisi anche un eventuale overhead della cache.

Stabilire autonomamente valori obiettivo adeguati

Una quota minima universale del 90% non costituisce un requisito tecnico valido. È più sensato un intervallo di valori specifico per il sito, che sia in linea con la distribuzione prevista degli accessi e con i benefici per l'applicazione. Redis raccomanda di valutare il valore osservato nel contesto del rispettivo modello di accesso; un valore percentuale da solo non basta a spiegare le prestazioni di WordPress.

Effettua innanzitutto una misurazione iniziale rappresentativa, indicando il periodo, l'intervallo di misurazione, il numero di accessi e la quota. A tal fine, registra i tempi di risposta dei principali tipi di richiesta, il carico del database e il tasso di errore. Identifica separatamente gli avvii a freddo e tieni conto delle differenze tipiche tra i periodi di scarso e intenso traffico, invece di considerare come stato normale una finestra casualmente favorevole.

Successivamente, pianifica una modifica concreta e, una volta approvata, verificala per prima cosa, se possibile, in un ambiente di test adeguato. Confronta quindi periodi di tempo e composizioni di richieste simili: cambiano la quota e il numero di lookups, ma anche la latenza o il carico sul database? In questo modo è più facile distinguere l’effetto da un semplice spostamento degli accessi.

Anche un tasso elevato può nascondere pochi errori, ma particolarmente costosi. Al contrario, un tasso moderato non deve necessariamente rappresentare un problema, purché alle richieste rilevanti venga data una risposta rapida e corretta. I costi operativi aggiuntivi per Redis o un altro backend persistente non sono automaticamente giustificati solo da una quota migliore; tieni conto del supporto di hosting, dei costi e dei possibili scenari di guasto.