La query cache di WordPress: perché di solito fa più male che bene

Il sito Query Cache di WordPress promette tempi di caricamento più brevi, ma in pratica causa spesso invalidazioni, Latenza e contenuti incoerenti. Vi mostrerò perché questa cache spesso consuma le prestazioni nelle configurazioni di WordPress e come posso invece ottenere una velocità stabile.

Punti centrali

• InvalidazioneLe operazioni di scrittura frequenti svuotano la cache e generano overhead.
• LatenzaLe cache esterne aggiungono tempo di connessione, che spesso si consuma in qualsiasi risparmio.
• IncoerenzaInserimenti non aggiornati portano a prezzi vecchi, liste errate o cestini vuoti.
• RAMLa cache compete con PHP, MySQL e Nginx/Apache per la memoria.
• AlternativeLa cache della pagina, OPcache e le query pulite garantiscono un profitto affidabile.

Come funziona davvero la cache delle query di WordPress

MySQL memorizza i risultati delle query SELECT utilizzando l'esatto testo SQL nel file Cache e lo ripropone con una query identica, risparmiando così l'esecuzione. In WordPress, invece, le INSERT, le UPDATE e le DELETE vengono ricevute continuamente, il che carica immediatamente la cache delle query per le tabelle interessate. disabilitato. Vedo regolarmente un ciclo infinito nei log: riempire, svuotare, riempire di nuovo - il server brucia tempo di CPU senza alcun beneficio apprezzabile. Inoltre, la query cache di MySQL si scontra con i meccanismi propri di WordPress, come i transienti e la cache degli oggetti, aumentando la latenza invece di ridurla. Chi attiva la query cache di WordPress, quindi, spesso crea un doppio strato di cache che si rompe più velocemente di quanto possa supportare.

Definizione: cosa viene realmente memorizzato nella cache

Io distinguo tre livelli, che spesso vengono confusi:

• Cache delle query MySQLCache dei risultati per istruzioni SELECT identiche. Ogni operazione di scrittura sulle tabelle interessate invalida le voci. Questo è controproducente nei moderni carichi di lavoro OLTP come WordPress. Nelle versioni più recenti di MySQL, questa cache è anche obsoleta; esiste ancora in MariaDB, ma la disattivo anche lì.
• Pool di buffer InnoDBNon è una cache di risultati, ma una cache di pagine per dati e indici. È il percorso più robusto e collaudato per gli accessi di lettura ricorrenti. Una buona dimensione del pool di buffer spesso rende più di qualsiasi cache dei risultati.
• Cache degli oggetti/transienti di WordPressCache lato applicazione (spesso Redis/Memcached), in cui vengono memorizzate strutture preparate come i risultati di WP_Query, le opzioni o i frammenti HTML. Questo livello è utile solo se gli accessi in lettura sono la regola e l'invalidazione funziona in modo affidabile.

Nella vita di tutti i giorni, ho osservato che il pool di buffer e una cache di pagina ben scelta sono le leve più importanti. Una cache aggiuntiva per le query raramente fornisce un guadagno netto, ma aumenta la complessità, la latenza e il rischio di incongruenze.

Perché rallenta invece di aiutare

Su host condivisi o con WooCommerce, la cache genera un'evidente Ritardo, perché ogni connessione di rete a Redis o Memcached costa tempo e non produce quasi nessun risultato. Anche su macchine veloci, spesso perdo millisecondi per richiesta, che si sommano al traffico e gonfiano il time-to-first dei byte. Inoltre, c'è il rischio di risultati non aggiornati se mancano i ganci di invalidazione o se i plugin funzionano male: improvvisamente un cliente vede un risultato errato. Prezzo o titoli mancati. Se volete dare un'occhiata più da vicino, vi consiglio il mio rapporto di esperienza Freni della cache degli oggetti perché modelli simili si applicano ai livelli di cache delle query. In media, un accesso diretto e pulito al database con un buon schema e OPcache consente di ottenere tempi di risposta migliori e più stabili.

Cache stampede, TTL e coordinamento

Un modello ricorrente negli stack di WordPress è il Cache stampedeUna voce scade, molte richieste eseguono la stessa costosa query nello stesso momento e generano picchi. Le cache di query e oggetti non coordinate aggravano questo problema. Per evitare questo problema, utilizzo tre strategie:

• Bloccaggio/CoalcificazioneUna richiesta costruisce la voce, le altre attendono brevemente o restituiscono il vecchio valore (stale-while-revalidate) e si aggiornano in background.
• TTL utiliNessun standard arbitrario di 24 ore. Gli elenchi di prodotti o i frammenti di prezzo ricevono TTL brevi (secondi/minuti), i metadati del catalogo più lunghi.
• Invalidazione basata sugli eventiAl posto delle sequenze temporali, utilizzo dei ganci (ad esempio per i post-aggiornamenti) per eliminare solo le chiavi interessate o, meglio, per rinnovare in modo specifico la cache della pagina.

Importante: in WordPress I transitori Efficace con una cache di oggetti persistente attiva permanente salvato. Se non si effettua un'invalidazione pulita, si creeranno incoerenze e schemi di errore difficili da riprodurre.

Sintomi tipici dei siti produttivi

Quando la cache di WordPress è danneggiata, lo riconosco dapprima da una fluttuazione della Tempo di risposta, che improvvisamente sale e scende senza alcuna modifica del codice. La sera, quando arrivano altri ordini, le invalidazioni si accumulano e il sito cade in una spirale di mancanze della cache e nuovi inserimenti. Il monitoraggio mostra quindi picchi di CPU volatili in MySQL, mentre PHP-FPM attende nuovi risultati. Allo stesso tempo, i clienti segnalano disguidi come commenti duplicati, cestini della spesa vuoti o aggiornamenti ritardati dei widget dei prodotti. Nei log compaiono sempre più spesso anche avvisi di blocco, perché i processi concorrenti scrivono continuamente sulle stesse tabelle, invalidando così la cache.

Livelli di cache: sequenza invece di impilare

Do la priorità alle cache in base alla catena d'impatto:

1. Browser/CDN/edge cache per le pagine completamente pubbliche, differenziate per cookie/intestazioni.
2. Cache di pagina nello stack (server web/plugin), idealmente con precaricamento e spurgo mirato sugli eventi.
3. OPcache per un bytecode PHP compilato in modo coerente.
4. Cache degli oggetti solo in modo selettivo per oggetti costosi e che cambiano raramente.
5. Banca dati con uno schema forte, indici e un ampio pool di buffer.

Chi si attiene a questa sequenza non solo riduce il TTFB, ma soprattutto la varianza - ciò che gli utenti percepiscono come „scatti“.

Migliori opzioni per la velocità reale

Guadagno in modo affidabile le prestazioni quando Caching della pagina Attivare la cache delle pagine, configurare OPcache in modo appropriato e ottimizzare le query al database. La cache delle pagine fornisce l'HTML, riduce il carico del database a zero e attenua i picchi di carico. OPcache compila PHP una sola volta, il che significa che PHP-FPM deve fare meno lavoro e il TTFB è ridotto. Una cache a oggetti con Redis è utile solo se le risorse del server sono generosamente disponibili e la logica dell'applicazione genera pochi accessi in scrittura per pagina. Con questa sequenza, elimino i colli di bottiglia all'origine e mantengo il numero di parti mobili gestibile, invece di usare un fragile memoria temporanea mantenere.

Misura	Vantaggi principali	Rischio/specialità
Caching della pagina (HTML statico)	Molto basso TTFB, quasi nessun carico di DB	I contenuti devono essere aggiornati in modo specifico quando vengono apportate delle modifiche
OPcache (bytecode PHP)	Meno tempo di CPU per Richiesta	Richiede una strategia di distribuzione e riscaldamento coerente
Cache degli oggetti Redis	Accesso rapido alle applicazioni più frequenti oggetti	Aiuta solo con i colpi; consuma RAM, ha bisogno di un design pulito dei tasti
Cache delle query MySQL	Esecuzione teoricamente inferiore delle query	Elevato sforzo di invalidazione, rischio di incoerenza, spese generali aggiuntive

Guida pratica: Disattivare e testare le alternative

Inizio con MySQL e disattivo la cache delle query a livello di sistema cambiando la configurazione in tipo_cache_query all'indirizzo 0 e dimensione_cache_della_query all'indirizzo 0 set. Poi riordino WordPress: Se un drop-in o una costante forzano la cache degli oggetti, li disattivo come test con define('WP_CACHE', false);. Utilizzo poi strumenti come Query Monitor, Blackfire o semplici metriche (TTFB, query/richieste, CPU) per misurare l'impatto effettivo per pagina. Solo quando la cache della pagina è impostata e PHP/OPcache funzionano correttamente, valuto specificamente se un piccolo livello di Redis alleggerisce il carico sui singoli hotspot. Questa sequenza mi consente di ottenere risultati riproducibili e di garantire che Stabilità, invece di sperare in colpi di fortuna.

Configurazioni in calcestruzzo che hanno dimostrato la loro validità

Alcune impostazioni predefinite con cui ottengo regolarmente guadagni stabili (convalidare sempre sul proprio sistema):

• MySQL/MariaDB:

  [mysqld]
  query_cache_type=0
  query_cache_size=0
  innodb_buffer_pool_size=60-70%_vom_RAM
  innodb_flush_log_at_trx_commit=1
  slow_query_log=1
  long_query_time=0.2
  log_queries_not_using_indexes=1
      

  Il pool di buffer sopporta il carico principale. Mostro il log lento agli sviluppatori e rimuovo sistematicamente i modelli N+1 e SELECT *.
• OPcache:

  opcache.enable=1
  opcache.memory_consumption=256
  opcache.interned_strings_buffer=16
  opcache.max_accelerated_files=100000
  opcache.validate_timestamps=1
  opcache.revalidate_freq=60
  ; JIT per gli stack classici di WordPress piuttosto spento:
  opcache.jit=0
      

  Sono importanti una distribuzione coerente (ad esempio, collegamenti simbolici atomici) e una fase di riscaldamento dopo i rilasci.
• PHP-FPM:

  pm=dinamico
  pm.max_children=
  pm.max_requests=500-1000
  process_idle_timeout=10s
      

  In questo modo si attutiscono le perdite e le frammentazioni senza provocare avviamenti a freddo.
• Redis (se utilizzato):

  maxmemory 
  politica di maxmemoria volatile-lru
  tcp-backlog 511
  ; preferito localmente tramite socket UNIX per una latenza minima
      

  Accetto Redis solo localmente o nello stesso AZ/host: sulle reti lente diventa rapidamente un amplificatore di latenza.

Mantenere pulito il database: Indici, query, plugin

Prima di impilare le cache, ottimizzo le query e Indici, perché il maggior risparmio di tempo deriva da un buon lavoro sui dati. Le JOIN troppo lunghe, le SELECT *, le condizioni WHERE mancanti e l'ordinamento senza indice costano più tempo di quanto qualsiasi cache possa risparmiare. Controllo regolarmente i plugin che memorizzano molte opzioni in wp_options senza una strategia di autocaricamento e rimuovo le estensioni superflue. Un aiuto mirato può essere quello di visualizzare e semplificare i propri schemi SQL: un'introduzione è fornita da Ottimizzare le query del database. Con una disciplina delle query pulita, la pressione sul server diminuisce in modo misurabile e il presunto vantaggio della cache delle query di WordPress si risolve da solo, perché non c'è più nulla da nascondere.

Fattori di hosting che battono la cache

Buono CPU-Le prestazioni, le veloci unità SSD NVMe, la RAM sufficiente e le ultime versioni di MySQL fanno la differenza più di una fragile cache di query. Anche la configurazione del server web gioca un ruolo importante: keep-alive, HTTP/2 o HTTP/3, timeout ragionevoli e un pool di processi PHP snello. Mi assicuro che OPcache sia generosamente dimensionata in modo che il bytecode degli script più frequenti vi entri completamente. Allo stesso tempo, limito i cron job e le attività in background che scatenano query storm durante i momenti di picco. In questo modo creo una solida base di prestazioni su cui posso usare la cache delle pagine e la cache degli oggetti mirata con precisione millimetrica, senza impantanarmi in un sistema di cache fragile. Soluzioni alternative perdere.

Metodi di misurazione: come valuto l'effetto

Misuro prima il Linea di base senza query cache: avvio a freddo, avvio a caldo, poi 50-200 richieste con JMeter o k6. Poi attivo specificamente solo un set di viti, mai diversi contemporaneamente, e ripeto i test di carico. Registro metriche come TTFB, latenza P95/P99, query per richiesta, percentuali di hit della cache e valori CPU/IO. Una vera vittoria per me è quando la mediana e il P95 scendono, i tassi di errore diminuiscono e la varianza si riduce. In quasi tutti i progetti WordPress, questo metodo mostra che la cache delle query di WordPress aumenta la varianza e riduce il tasso di errore mediano. Valore di risposta deteriorata.

Manuale di messa a punto: Soglie e controlli

• Tasso di successoAl di sotto di ~60% gli hit della cache degli oggetti sul traffico produttivo raramente valgono la pena. Quindi disattivo costantemente e misuro di nuovo.
• Latenza di Redis>1 ms mediano locale è troppo. È possibile ottenere un tempo inferiore ai millisecondi tramite un socket UNIX e una pipeline breve.
• Tempi di attesa del DBSorge Threads_running aumenta in modo significativo sotto carico, controllo prima gli indici/le query, senza attivare la cache.
• varianzaUn P95 che cade è più importante per me di una statistica mediana esteticamente migliore.
• InvalidazioniAd ogni aggiornamento dei contenuti o dei prezzi, osservo quante chiavi vengono eliminate. Le cancellazioni ampie sono un anti-pattern.
• RiscaldamentoDopo le distribuzioni e l'eliminazione delle pagine, riscaldo automaticamente i percorsi critici (pagina iniziale, categoria, cassa).

Compatibilità e rischi con i plugin

Alcune estensioni sovrascrivono le chiavi della cache, cancellano i transitori troppo presto o ignorano le chiavi della cache necessarie. Ganci, che porta a voci orfane. I problemi diventano più visibili negli ambienti multisito, perché si verificano più eventi di scrittura in parallelo e l'invalidazione avviene più frequentemente. I flussi di lavoro del commercio elettronico con prezzi dinamici, buoni e frammenti di carrello sono particolarmente sensibili: anche un ritardo di pochi millisecondi può far crollare le metriche di checkout. Per questo motivo, isolo i problemi di cache disattivando gradualmente i plugin e verificandoli in punti di misurazione chiari. Se un componente aggiuntivo richiede la cache della query, ne faccio a meno e scelgo una soluzione che funzioni senza vulnerabilità. Strato intermedio funziona in modo pulito.

Sicurezza operativa: rollback e manutenzione

Mantengo le modifiche alla cache ripristinabili. Questo significa: flag per la cache degli oggetti e delle pagine, file di configurazione separati e una lista di controllo per le emergenze. Se qualcosa va storto sotto carico, per prima cosa estraggo la query/object cache e lascio che la page cache + OPcache funzionino. Dopodiché:

1. Obiettivo a filo anziché globalmente: eliminare solo le chiavi interessate, non svuotare l'intero Redis.
2. Utilizzare WP-CLI:

   lavaggio della cache di wp
   wp transient delete --all
       

   Salvate le metriche in anticipo, poi misurate di nuovo.
3. Rotazione dei tronchi e il log delle query lento, invece di attivare il controllo della cache.

Breve sintesi: cosa assumo e perché

Ho disattivato la cache delle query di WordPress a causa dell'invalidazione, Latenza e l'incoerenza si mangiano il profitto teorico. Invece, mi affido alla cache delle pagine, a OPcache e a un lavoro pulito sui database, che fornisce prestazioni costanti e senza sorprese. Uso Redis in modo selettivo se c'è un chiaro hotspot e se è disponibile una quantità sufficiente di RAM. Se si misura in modo oggettivo, ci si rende subito conto che query ben strutturate, risorse host solide e cache HTML forniscono le risposte tranquille e veloci di cui ogni sito ha bisogno. Questo mi permette di mantenere prestazioni prevedibili, di risparmiare sui costi del server in euro e di evitare schemi di errore che non possono essere intercettati in modo affidabile con qualsiasi cache di query.