Objektum-gyorsítótár (Redis) WordPressben: mikor éri meg, mikor okoz hibát

Scheo · 2026-09-16 · olvasási idő ~10 perc · Szerző: Schmidt Péter

Egy lassú WordPress oldalnál a leggyakoribb reflex, hogy bekapcsolunk valamilyen gyorsítótárat, aztán remélünk. A gond az, hogy a gyorsítótár szó legalább négy különböző dolgot jelent (böngésző-oldali tárolás, CDN, oldal-gyorsítótár, objektum-gyorsítótár), és ezek egymástól teljesen eltérő helyen segítenek. Az objektum-gyorsítótár, vagyis a Redis vagy a Memcached bevonása az egyik leghatásosabb eszköz, ha az oldalad tényleg sokat beszél az adatbázissal. Ha viszont nem, akkor egy újabb réteg, ami elromolhat, és amit senki nem fog gyanúba venni, amikor a kosár rosszul viselkedik.

Mi a különbség az oldal-gyorsítótár és az objektum-gyorsítótár között?

Az oldal-gyorsítótár kész HTML-t tárol egy URL-hez, az objektum-gyorsítótár pedig az oldal felépítése közben keletkező adatokat, tipikusan adatbázis-lekérdezések eredményét. Az egyik a végeredményt spórolja meg, a másik a munkát közben.

Hivatalosan igazolt: a WordPress magja tartalmaz egy objektum-gyorsítótár réteget (WP_Object_Cache, a wp_cache_get() és wp_cache_set() függvényekkel), de ez alapállapotban csak egyetlen kérés idejére él. Amint a PHP-folyamat lefut, minden eltűnik. Perzisszé, vagyis kérések között is megmaradóvá egy úgynevezett drop-in fájl teszi: a wp-content/object-cache.php, amit a Redis- vagy Memcached-bővítmény telepít. Ettől kezdve az wp_options autoload sorai, a taxonómia-adatok, a tranziensek és a lekérdezés-eredmények a memóriából jönnek.

A gyakorlati különbség ott válik élessé, ahol az oldal-gyorsítótár nem tud dolgozni. Bejelentkezett felhasználónál, nem üres kosárnál, fizetési folyamatban, tagsági területen és az adminban a jól beállított oldal-gyorsítótár szándékosan kimarad, mert személyre szóló tartalmat nem tárolhat közösen. Ilyenkor minden kérés teljes PHP-futást és teljes adatbázis-kört jelent. Pont ezt a kört tudja lerövidíteni az objektum-gyorsítótár.

Fordítva is igaz: egy bemutatkozó oldalon, ahol napi néhány száz kijelentkezett látogató jön, és az oldal-gyorsítótár szinte mindent lefed, a Redis lényegében semmit nem gyorsít. A látogató úgyis egy statikus HTML-t kap, oda se PHP, se SQL nem fut.

Milyen oldalnál hoz valódi eredményt a Redis vagy a Memcached?

Röviden: ott, ahol kérésenként sok adatbázis-lekérdezés fut, és ahol a látogatók nagy része nem kaphat közös HTML-t. Négy tipikus eset:

• Sok lekérdezés kérésenként. Ha a Query Monitor 300, 600 vagy ezer feletti lekérdezést mutat egy aloldalon (sok bővítmény, összetett szűrők, nagy menü, egyedi mezők tömege), akkor van mit megspórolni. Tapasztalati durva küszöb: 150 lekérdezés alatt ritkán érdemes hozzányúlni, 400 felett szinte mindig érdemes megvizsgálni.
• Bejelentkezett felhasználók. Ügyfélportál, szerkesztői csapat, sok szerzős magazin. Ha a napi munkaidő nagy részét emberek az adminban töltik, az objektum-gyorsítótár közvetlenül az ő idejüket adja vissza.
• WooCommerce. A kosár, a fiók, a pénztár és a szűrhető terméklisták sok autoload-opciót, terméktulajdonságot és tranzienst olvasnak. Nagy termékszámnál, változatokkal és attribútum-szűrőkkel ez a legjellemzőbb haszon-eset.
• Tagsági és tanfolyam-oldalak. Itt szinte minden látogató be van jelentkezve, tehát az oldal-gyorsítótár szinte használhatatlan, viszont jogosultság-ellenőrzés, előrehaladás-követés és felhasználói metaadat rengeteg van.

Szakmai feltételezés: a Redis és a Memcached közti választás egy átlagos magyar WordPress oldalon másodrangú kérdés. A Redis mellett szól, hogy a WordPress-ökoszisztéma bővítményei jobban támogatják, tud lemezre írni, és többféle adatszerkezettel dolgozik. A Memcached egyszerűbb és több szálon fut. A mért különbséget a legtöbb esetben inkább a kapcsolat módja (Unix socket vagy TCP), a PHP-kiterjesztés (phpredis a natív, a tisztán PHP-ben írt kliens lassabb) és a bővítmény minősége adja, nem maga a szerver.

Hogyan vezesd be az objektum-gyorsítótárat lépésről lépésre?

Az alábbi sorrend szándékosan a méréssel kezdődik és a méréssel végződik. Ha a nulladik lépést kihagyod, később nem fogod tudni megmondani, hogy a Redis segített-e vagy csak elhitted.

1. Nulladik lépés: alapmérés. Query Monitorral jegyezd fel három reprezentatív oldalon (főoldal, kategória vagy terméklista, kosár vagy fiók), bejelentkezve és kijelentkezve: a lekérdezések számát, az SQL-időt, a PHP-időt és a memóriahasználatot. Mellé a bejelentkezett TTFB-t. Írd le, ne csak nézd meg.
2. Tárhely-oldali elérhetőség ellenőrzése. Kell egy futó Redis vagy Memcached szolgáltatás, és kell hozzá PHP-kiterjesztés. Ellenőrzés parancssorból:

php -m | grep -i -E 'redis|memcach'

redis-cli -h 127.0.0.1 -p 6379 ping

Ha az első semmit nem ír ki, a bővítmény hiába lesz feltelepítve. Megosztott tárhelynél gyakran a szolgáltató panelján (cPanel, Plesk, ispmanager) kell külön bekapcsolni, és sokszor nem TCP-porton, hanem Unix socketen érhető el. Kérdezd meg írásban a szolgáltatót: van-e dedikált példány vagy adatbázis-szám, mennyi a memórialimit, és mi a kiürítési szabály.

3. Bővítmény és beállítás. Egy darab objektum-gyorsítótár bővítmény legyen aktív, ne kettő. A wp-config.php-ban a lényeges sorok:

define( 'WP_REDIS_HOST', '127.0.0.1' );

define( 'WP_REDIS_PORT', 6379 );

define( 'WP_REDIS_DATABASE', 3 );

define( 'WP_CACHE_KEY_SALT', 'oldalneve_hu_' );

A WP_REDIS_DATABASE és a WP_CACHE_KEY_SALT nem díszítés. Ha ugyanazon a gépen több oldal használja ugyanazt a Redis példányt, ez a kettő választja el őket egymástól.

4. A kapcsolat tesztje. A bővítmény felületén kapcsold be, majd ellenőrizd, hogy létrejött-e a wp-content/object-cache.php, és hogy a státusz csatlakozottat ír. Parancssorból is nézd meg, mert a webkiszolgáló és a WP-CLI nem mindig ugyanazzal a felhasználóval és útvonallal fut:

wp redis status

wp cache flush

5. Utómérés ugyanazon az oldalakon. Ugyanaz a három URL, ugyanaz a négy szám. Ha a lekérdezésszám nem esett érdemben, vagy a bejelentkezett TTFB nem lett jobb, akkor nálad ez most nem hozott hasznot, és jogos döntés kikapcsolni.

Mit jelent a találati arány, és mi a gond a 90% alatti értékkel?

A találati arány (hit rate) azt mutatja, hogy a gyorsítótárból kért adatoknak mekkora része volt tényleg ott. A bővítmények kiírják, de érdemes a szerver oldaláról is ellenőrizni:

redis-cli info stats | grep -E 'keyspace_hits|keyspace_misses|evicted_keys|expired_keys'

redis-cli info memory | grep -E 'used_memory_human|maxmemory_human'

A számítás egyszerű: találatok osztva a találatok és tévedések összegével. Saját tapasztalat: egy bejáratott, néhány órája futó oldalon a 95% feletti arány a normális. A 90% alatti érték nem magában baj, hanem tünet, és általában az alábbi öt ok valamelyikére vezet vissza:

• Kevés memória, ezért kiszorítás. Ha az evicted_keys nullánál nagyobb és folyamatosan nő, a Redis kidobálja azt, amit épp beírtál. Ez a leggyakoribb ok megosztott tárhelyen.
• Túl rövid élettartam. Ha a WP_REDIS_MAXTTL néhány perc, a gyakran olvasott adatok is állandóan lejárnak.
• Írás-nehéz működés. Egy bővítmény minden kérésnél tranzienst ír, vagy minden oldalbetöltés frissít egy számlálót. Ilyenkor a gyorsítótár nem olvasási, hanem írási terhelés alá kerül.
• Túl gyakori teljes ürítés. Ha egy mentő vagy szinkronizáló feladat félóránként kiüríti az egészet, soha nem melegszik be.
• Mérési tévedés. Frissen ürített gyorsítótárnál vagy éppen induló forgalomnál az arány természetesen alacsony. Legalább egy-két óra forgalom után olvasd le.

A találati arány tehát diagnosztikai eszköz, nem cél. Hajszolni értelmetlen: attól, hogy 97%-ra vitted, még nem lett jobb a felhasználói élmény, ha a lassúságot eredetileg egy külső API-hívás vagy egy indexelés nélküli egyedi tábla okozta.

Milyen hibák szoktak előjönni objektum-gyorsítótár bekapcsolása után?

A bajok többsége nem lassulás, hanem elavult vagy összekeveredett adat, és ez sokkal nehezebben észrevehető. A leggyakoribbak:

• Elavult adat a kosárban. A látogató beteszi a terméket, de a kosár-összeg a régi marad, vagy a szállítási díj nem számol újra. Ennek jellemzően nem a Redis az oka önmagában, hanem az, hogy a kosár-részletek, a mini-kosár töredékei vagy a munkamenet-adatok olyan csoportba kerültek, amit nem szabad kérések között megőrizni. Saját tapasztalat: ha WooCommerce alatt furcsa kosár-viselkedést látsz, először azt ellenőrizd, hogy az oldal-gyorsítótár tényleg kihagyja-e a kosár, pénztár és fiók oldalakat, és hogy a nem perzisztens csoportok listája ép-e.
• Munkamenet-keveredés. A legkellemetlenebb hiba: az egyik felhasználó a másik adatát látja. Tipikus kiváltó ok, hogy több oldal ugyanazt a Redis adatbázist használja azonos kulcs-előtag nélkül, vagy hogy egy fejlesztői és egy éles példány osztozik egy példányon. A WP_CACHE_KEY_SALT és a külön WP_REDIS_DATABASE pont ezért kötelező, nem opcionális.
• A gyorsítótár ürítésének hiánya frissítés után. Bővítmény- vagy témafrissítés, migrálás, adatbázis-visszaállítás után a memóriában maradt régi opciók ütköznek a friss kóddal. Az eredmény üres oldal, hiányzó beállítás vagy visszatérő, javítás után is makacsul megmaradó hibaüzenet. A szabály egyszerű: minden frissítés és minden költöztetés után wp cache flush, és ha van PHP OPcache, azt is külön kell üríteni. Ez a kettő nem ugyanaz.
• Memórialimit megosztott tárhelyen. Ha a maxmemory szűk, és a kiürítési szabály noeviction, a Redis egy ponton hibát ad írás helyett. Ilyenkor nem lassulás lesz, hanem hiba. Nagy forgalmú, sok opciót olvasó oldalnál az allkeys-lru szabály általában jobban viselkedik, de ezt a szolgáltató dönti el, nem te.
• Elavult drop-in fájl. A bővítmény frissül, de a object-cache.php nem cserélődik le automatikusan. A státuszfelület jelzi, ha verzióeltérés van, és ezt nem szabad figyelmen kívül hagyni.
• Kétféle gyorsítótár-bővítmény egyszerre. Két drop-in nem tud egymás mellett élni, az utóbbi felülírja az előbbit, a viselkedés pedig kiszámíthatatlan lesz.

Mikor NE kapcsold be, és miért ez a szigorúbb álláspont?

Saját nézőpont: objektum-gyorsítótárat csak akkor kapcsolj be, ha van méréssel alátámasztott előtte és utána állapot. Aki mérés nélkül kapcsolja be, az nem gyorsított, hanem szerzett egy újabb réteget, amit hat hónap múlva senki nem fog gyanúba venni, amikor a pénztár hibázik.

Konkrétan hagyd ki, ha:

• bemutatkozó vagy szolgáltatás-oldalról van szó, kevés aloldallal és szinte csak kijelentkezett látogatóval;
• a lekérdezésszám kérésenként alacsony, és az SQL-idő a teljes válaszidő kis részét adja (ilyenkor a szűk keresztmetszet máshol van: egy nehéz külső szkript, egy lassú külső API, képméret vagy egy hiányzó adatbázis-index);
• a tárhely csak megosztott, más oldalakkal közös Redis példányt tud adni, és nem tudsz külön adatbázis-számot és kulcs-előtagot kapni;
• nincs senki, aki frissítés után ki tudja üríteni, vagy egy hibát vissza tud vonni.

Szakmai feltételezés: a sebesség és a keresési láthatóság között van összefüggés, de az objektum-gyorsítótár önmagában nem javít helyezést, és nem garantál semmilyen eredményt. Ami mérhető, az a bejelentkezett felhasználók és az admin gyorsulása, illetve a szerver terhelésének csökkenése csúcsidőben. A kijelentkezett látogató által érzékelt betöltési idő nagy részét jó eséllyel a front-end (képek, szkriptek, betűtípusok) adja, azt pedig a Redis nem érinti.

Milyen ellenőrzőlistán menj végig bevezetés előtt és után?

Bevezetés előtt:

• Van friss, visszaállítható mentés, és tudod, hogyan állítod vissza.
• Le van írva a három referencia-oldal négy száma, bejelentkezve és kijelentkezve.
• Írásban megvan a szolgáltatótól: van-e Redis vagy Memcached, mekkora memóriával, dedikált-e, mi a kiürítési szabály.
• A PHP-kiterjesztés tényleg fut, nem csak a szolgáltató kínálatában szerepel.
• Csak egy gyorsítótár-bővítmény lesz aktív.

Bevezetés után, az első két hétben:

• A kapcsolat státusza csatlakozott, a drop-in verziója egyezik.
• Találati arány leolvasva legalább két óra forgalom után, a kiszorított kulcsok száma nem növekszik folyamatosan.
• Kézzel végigpróbált vásárlási és bejelentkezési folyamat, két különböző böngészőből, egyszerre.
• Frissítés utáni ürítés be van írva a saját folyamatba, nem a memóriádra van bízva.
• Az utómérés összevetve az alapméréssel, és megvan a döntés: marad vagy megy.

Források és további olvasnivalók

• WordPress Developer Resources: Object Cache API és WP_Object_Cache osztály-dokumentáció
• WordPress Core Contributor Handbook: Cache API és drop-in fájlok
• WP-CLI Command Reference: wp cache parancscsoport
• Redis dokumentáció: memóriakezelés, kiürítési szabályok, az INFO parancs
• Memcached projekt wiki: protokoll és üzemeltetési útmutató
• PHP kézikönyv: Redis és Memcached kiterjesztések
• WooCommerce Documentation: gyorsítótárazási megfontolások és kizárandó oldalak
• Google Search Central: oldalélmény és Core Web Vitals dokumentáció
• web.dev: TTFB és szerveroldali válaszidő mérése
• Query Monitor bővítmény dokumentációja