...
logotyp för webbhotell

WordPress query cache: Varför det oftast gör mer skada än nytta

Der WordPress Query Cache lovar kortare laddningstider, men orsakar i praktiken ofta ogiltigförklaringar, Fördröjning och inkonsekvent innehåll. Jag kommer att visa dig varför denna cache ofta äter upp prestanda i WordPress-installationer och hur jag kan uppnå stabil hastighet istället.

Centrala punkter

  • OgiltigförklaringFrekventa skrivoperationer tömmer cacheminnet och genererar overhead.
  • FördröjningExterna cacheminnen ökar anslutningstiden, vilket ofta äter upp eventuella besparingar.
  • InkonsekvensFöråldrade poster leder till gamla priser, felaktiga listor eller tomma kundkorgar.
  • RAM: Cachen konkurrerar med PHP, MySQL och Nginx/Apache om minnet.
  • Alternativa lösningarSidcache, OPcache och rena frågor ger tillförlitlig vinst.

Så här fungerar WordPress query cache egentligen

MySQL lagrar resultaten av SELECT-frågor med hjälp av den exakta SQL-texten i Cache och levererar den igen med en identisk fråga, vilket sparar körningen. I WordPress tas dock INSERT, UPDATE och DELETE emot kontinuerligt, vilket omedelbart laddar frågecachen för berörda tabeller. funktionshindrad. Jag ser regelbundet en oändlig slinga i loggarna: fyll, töm, fyll igen - servern bränner CPU-tid utan någon märkbar fördel. Dessutom kolliderar MySQL Query Cache med WordPress egna mekanismer som transienter och objektcache, vilket ökar latensen istället för att minska den. De som WordPress query cache är därför ofta uppbyggd av ett dubbelt cachelager som bryts snabbare än det kan stödja.

Definition: Vad är det egentligen som cachas här?

Jag skiljer mellan tre nivåer, som ofta blandas ihop:

  • Cache för MySQL-frågorResultatcache för identiska SELECT-satser. Varje skrivoperation på berörda tabeller ogiltigförklarar poster. Detta är kontraproduktivt i moderna OLTP-arbetsbelastningar som WordPress. I nyare MySQL-versioner är denna cache också föråldrad; den finns fortfarande i MariaDB, men jag stänger av den där också.
  • InnoDB buffertpool: Inte en resultatcache, utan en sidcache för data- och indexsidor. Det är den robusta, beprövade vägen för återkommande läsaccesser. En solid buffertpoolstorlek ger ofta mer än någon resultatcache.
  • WordPress objektcache/transienterCache på applikationssidan (ofta Redis/Memcached), där förberedda strukturer som WP_Query-resultat, alternativ eller HTML-fragment lagras. Detta lager hjälper bara om läsåtkomst är regeln och ogiltigförklaring fungerar på ett tillförlitligt sätt.

I det dagliga livet har jag observerat att buffertpoolen och en väl vald sidcache är de största hävstängerna. Ytterligare cachelagring av frågor ger sällan någon nettovinst, utan ökar komplexiteten, latensen och risken för inkonsekvenser.

Varför det saktar ner istället för att hjälpa

På delade värdar eller med WooCommerce genererar cacheminnet märkbart Fördröjning, eftersom varje nätverksanslutning till Redis eller Memcached kostar tid och knappast ger några träffar. Även på snabba maskiner förlorar jag ofta millisekunder per begäran, vilket ökar med trafiken och blåser upp tid-till-första byte. Dessutom finns det risk för föråldrade resultat om ogiltighetskrokar saknas eller plugins fungerar felaktigt - plötsligt ser en kund ett felaktigt resultat. Pris eller missade aktier. Om du vill titta närmare på det rekommenderar jag min erfarenhetsrapport Bromsar för objektcache eftersom liknande mönster gäller för cachelagringsnivåer för frågor. I genomsnitt ger ren direktåtkomst till databasen med ett bra schema och OPcache bättre och mer stabila svarstider.

Cache-stampede, TTL och samordning

Ett återkommande mönster i WordPress-stackar är Cache-stampedeEn post går ut, många förfrågningar gör samma dyra förfrågan samtidigt och genererar spikar. Query- och objektcacher utan samordning förvärrar detta. Jag använder tre strategier för att undvika detta:

  • Låsning/Koalescens: En begäran bygger posten, de andra väntar en kort stund eller returnerar det gamla värdet (stale-under-validering) och uppdateras i bakgrunden.
  • Användbara TTL:erInga godtyckliga 24-timmarsstandarder. Produktlistor eller prisfragment får korta TTL:er (sekunder/minuter), katalogmetadata längre TTL:er.
  • Händelsebaserad ogiltigförklaringI stället för trubbiga tidssekvenser använder jag krokar (t.ex. för postuppdateringar) för att radera endast berörda nycklar - eller ännu bättre: för att specifikt förnya sidcachen.

Viktigt: I WordPress Övergångar Effektivt med aktiv persistent objektcache permanent sparas. Om du inte har en ren ogiltigförklaring här kommer du att skapa inkonsekvenser och felmönster som är svåra att reproducera.

Typiska symptom på produktiva anläggningar

När WordPress query cache är skadad märker jag det först genom en fluktuerande Svarstid, som plötsligt går upp och ner utan några kodändringar. På kvällen, när fler beställningar kommer in, ackumuleras ogiltigheter och webbplatsen faller in i en spiral av cachemissar och nya poster. Övervakningen visar sedan flyktiga CPU-toppar i MySQL, medan PHP-FPM väntar på nya resultat. Samtidigt rapporterar kunder missmatchningar som duplicerade kommentarer, tomma kundkorgar eller försenade uppdateringar av produktwidgets. Låsvarningar dyker också allt oftare upp i loggar eftersom konkurrerande processer ständigt skriver till samma tabeller och därmed inaktiverar cacheminnet.

Cachningsnivåer: sekvens istället för stapling

Jag prioriterar cacher enligt påverkanskedjan:

  1. Webbläsare/CDN/edge-cache för helt offentliga sidor, differentierade genom cookies/headers.
  2. Cache för sidor i stacken (webbserver/plugin), helst med förladdning och riktad rensning vid händelser.
  3. OPcache för konsekvent kompilerad PHP-bytekod.
  4. Cache för objekt endast selektivt för dyra, sällan föränderliga objekt.
  5. Databas med starkt schema, index och stor buffertpool.

De som följer denna sekvens minskar inte bara TTFB, utan framför allt varians - vad användarna uppfattar som „ryckigt“.

Bättre alternativ för verklig hastighet

Jag får tillförlitlig prestanda när jag först Cachelagring av sidor aktivera sidcaching, konfigurera OPcache på rätt sätt och sedan effektivisera databasfrågorna. Sidcaching levererar HTML, minskar databasbelastningen till noll och jämnar ut belastningstoppar. OPcache kompilerar PHP en gång, vilket innebär att PHP-FPM behöver göra mindre arbete och TTFB reduceras. En objektbaserad cache med Redis är bara värd om serverresurserna är generöst tillgängliga och applikationslogiken genererar få skrivåtkomster per sida. Med den här sekvensen eliminerar jag flaskhalsar vid källan och håller antalet rörliga delar hanterbart, istället för att använda en bräcklig mellanlagring att upprätthålla.

Mått Viktigaste fördelarna Risk/specialitet
Cachelagring av sidor (statisk HTML) Mycket låg TTFB, knappast någon DB-belastning Innehållet måste uppdateras specifikt när ändringar görs
OPcache (PHP-bytekod) Mindre CPU-tid per Begäran Kräver konsekvent utplacering och uppvärmningsstrategi
Cache för Redis-objekt Snabb tillgång till många objekt Hjälper bara vid träffar; slukar RAM-minne, behöver en ren tangentdesign
Cache för MySQL-frågor Teoretiskt sett mindre exekvering av frågor Hög invalidiseringsinsats, risk för inkonsekvens, extra omkostnader

Praktisk guide: Avaktivera och testa alternativ

Jag börjar med MySQL och stänger av frågecachen på systemnivå genom att ändra konfigurationen till query_cache_type på 0 och query_cache_storlek på 0 set. Sedan städar jag upp WordPress: Om ett drop-in eller en konstant tvingar fram objektcachelagring avaktiverar jag det som ett test med define('WP_CACHE', false);. Jag använder sedan verktyg som Query Monitor, Blackfire eller enkla mätvärden (TTFB, queries/requests, CPU) för att mäta den faktiska påverkan per sida. Först när sidcaching är inställd och PHP/OPcache körs korrekt gör jag en specifik bedömning av om ett litet Redis-lager avlastar belastningen på enskilda hotspots. Den här sekvensen ger mig reproducerbara resultat och säkerställer Stabilitet, istället för att hoppas på en slumpmässig träff.

Betongkonfigurationer som har visat sig vara värdefulla

Några standardvärden som jag regelbundet uppnår stabila vinster med (validera alltid på ditt eget system):

  • 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
lång_förfrågan_tid = 0,2
log_queries_not_using_indexes=1
    Buffertpoolen bär huvudbelastningen. Jag visar den långsamma loggen för utvecklare och tar systematiskt bort N+1- och SELECT *-mönster.
  • OPcache: 
    opcache.enable=1
opcache.minnesförbrukning=256
opcache.interned_strings_buffer=16
opcache.max_accelererade_filer=100000
opcache.validera_tidsstämplar=1
opcache.revalidate_freq=60
; JIT för klassiska WordPress-stackar snarare av:
opcache.jit=0
    Det är viktigt med en konsekvent distribution (t.ex. atomiska symlinks) och en uppvärmning efter releaser.
  • PHP-FPM: 
    pm=dynamisk
pm.max_children=.
pm.max_requests=500-1000
process_idle_timeout=10s
    Detta dämpar läckage och fragmentering utan att provocera fram kallstarter.
  • Redis (om den används): 
    maxminne 
maxminne-policy flyktig-lru
tcp-backlog 511
; lokalt föredraget via UNIX-socket för minimal latens
    Jag accepterar bara Redis lokalt eller i samma AZ/host - över långsamma nätverk blir det snabbt en latensförstärkare.

Håll databasen ren: Index, frågor, plugins

Innan jag staplar cacher optimerar jag frågor och Index, eftersom den största tidsbesparingen kommer från bra dataarbete. Överlånga JOIN, SELECT *, saknade WHERE-villkor och sortering utan index kostar mer tid än någon cache kan spara. Jag kontrollerar regelbundet plugins som lagrar många alternativ i wp_options utan en autoload-strategi och tar bort överflödiga tillägg. Ett riktat hjälpmedel kan vara att se och effektivisera dina egna SQL-mönster - en introduktion ges av Optimera databasfrågor. Med en ren frågedisciplin minskar trycket på servern mätbart, och den förmodade fördelen med WordPress frågecache tar hand om sig själv eftersom det inte finns något kvar att dölja.

Hostingfaktorer som slår cachelagring

Bra CPUPrestanda, snabba NVMe SSD-enheter, tillräckligt med RAM-minne och de senaste MySQL-versionerna gör större skillnad än en bräcklig query cache. Webbserverns konfiguration spelar också en stor roll: keep-alive, HTTP/2 eller HTTP/3, vettiga timeouts och en slimmad PHP-processpool. Jag ser till att OPcache är generöst dimensionerad så att bytekoden för de frekventa skripten får plats helt och hållet. Samtidigt begränsar jag cron-jobb och bakgrundsuppgifter som utlöser frågestormar under topptider. Detta skapar en solid grundprestanda där jag kan använda sidcaching och riktad objektcaching med exakt precision, utan att fastna i spröda Workarounds ...att förlora.

Mätmetoder: Hur jag bedömer effekten

Jag mäter först Baslinje utan query cache: kallstart, varmstart, sedan 50 till 200 förfrågningar med JMeter eller k6. Jag aktiverar sedan specifikt bara en justeringsskruv, aldrig flera samtidigt, och upprepar belastningstesterna. Jag registrerar mätvärden som TTFB, P95/P99-latens, frågor per begäran, cache-träfffrekvenser och CPU/IO-värden. En riktig vinst för mig är när medianen och P95 sjunker, felfrekvenserna sjunker och variansen blir mindre. I nästan alla WordPress -projekt visar denna metod att WordPress -cachen för frågor ökar variansen och minskar medianfelprocenten. Svarsvärde försämrats.

Spelbok för tuning: Tröskelvärden och kontroller

  • TräfffrekvensUnder ~60% objektcacheträffar på produktiv trafik är det sällan värt det. Jag avaktiverar sedan konsekvent och mäter igen.
  • Redis latenstid>1 ms median lokalt är för mycket. Sub-millisekunder kan uppnås via UNIX-socket och kort pipeline.
  • DB väntetiderstiger upp Trådar_löpande ökar betydligt under belastning, kontrollerar jag först index/förfrågningar - skruvar inte upp cacheminnet.
  • varians: En fallande P95 är viktigare för mig än en kosmetiskt bättre medianstatistik.
  • Ogiltigförklaringar: Med varje innehålls- eller prisuppdatering observerar jag hur många nycklar som tappas bort. Breda raderingar är ett anti-mönster.
  • Uppvärmning: Efter utplaceringar/sidrensningar förvärmer jag kritiska rutter (startsida, kategori, kassa) automatiskt.

Kompatibilitet och risker med plugins

Vissa tillägg skriver över cache-nycklar, rensar transienter för tidigt eller ignorerar nödvändiga cache-nycklar. Krokar, vilket leder till föräldralösa poster. Problemen blir mer synliga i miljöer med flera webbplatser eftersom fler skrivhändelser inträffar parallellt och invalideringen sker oftare. Arbetsflöden för e-handel med dynamiska priser, kuponger och varukorgsfragment är särskilt känsliga: även en fördröjning på några millisekunder kan få kassamätvärdena att rasa. Jag isolerar därför problem med cachelagring genom att gradvis inaktivera plugins och verifiera dem vid tydliga mätpunkter. Om ett tillägg kräver query cache avstår jag från det och väljer en lösning som fungerar utan sårbarhet Mellanliggande lager fungerar rent.

Operativ säkerhet: återställning och underhåll

Jag håller cachelagringsändringar rullbara. Detta innebär: funktionsflaggor för objekt- / sidcache, separata konfigurationsfiler och en checklista för nödsituationer. Om något går fel under belastning tar jag först bort query-/objektcachen och låter sidcachen + OPcache fungera. Efter detta:

  1. Spolning riktad istället för globalt: Ta bara bort berörda nycklar, töm inte hela Redis.
  2. Använd WP-CLI: 
    wp cache flush
wp transient delete --all
    Spara mätvärden i förväg och mät sedan igen.
  3. Rotera stockar och långsam frågelogg istället för att slå på cachekontrollen.

Kort sammanfattning: Vad jag anställer och varför

Jag stänger av WordPress query cache på grund av ogiltighet, Fördröjning och inkonsekvens äter upp den teoretiska vinsten. Istället förlitar jag mig på sidcachning, OPcache och rent databasarbete som levererar konsekvent och utan överraskningar. Jag använder Redis selektivt om det finns en tydlig hotspot och tillräckligt med RAM-minne är tillgängligt. Om du mäter objektivt inser du snabbt: välstrukturerade frågor, starka värdresurser och HTML-cachelagring ger de lugna, snabba svar som varje webbplats behöver. Detta gör att jag kan hålla prestandan förutsägbar, spara serverkostnader i euro och undvika felmönster som inte kan fångas upp på ett tillförlitligt sätt med någon frågecache.

Aktuella artiklar