WordPressin suorituskyvystä puhuttaessa query cache nousee esiin yllättävän usein. Moni olettaa, että tietokantakyselyiden välimuisti on automaattinen ja tehokas ratkaisu kaikkiin hitaisiin sivuihin. Todellisuus on huomattavasti monimutkaisempi. Osittain siksi query cache on enemmän historiallinen käsite kuin moderni optimointikeino.
Kysymys ei ole vain siitä, toimiiko query cache, vaan mihin kerrokseen optimointi kannattaa oikeasti tehdä.
Mitä query cache tarkoittaa
Query cache viittaa tietokantatasolla toimivaan välimuistiin, joka:
-
tallentaa kyselyn tuloksen muistissa
-
palauttaa tuloksen ilman uutta suoritusta
-
perustuu identtiseen SQL-kyselyyn
Ajatus on houkutteleva: sama kysely, sama vastaus, ei kuormaa. WordPressin dynaamisessa ympäristössä tämä ajatus kuitenkin säröilee.
MySQL Query Cache ja sen historia
Miksi se ei ole enää oletus
Perinteinen MySQL Query Cache:
-
toimi globaalina välimuistina
-
lukitsi koko cachen kirjoitusoperaatioissa
-
skaalautui huonosti
Siksi se:
-
poistettiin käytöstä oletuksena
-
deprekoitiin MySQL 5.7:ssa
-
poistettiin kokonaan MySQL 8:ssa
Moderni WordPress-hosting ei enää tarjoa tätä vaihtoehtoa, eikä se ole sattumaa.
WordPressin kyselymalli ja ongelman ydin
Dynaamisuus rikkoo query cachen
WordPressissä:
-
käyttäjän rooli vaikuttaa kyselyihin
-
kieli vaikuttaa sisältöön
-
lisäosat muokkaavat SQL:ää
-
LIMIT ja ORDER BY vaihtelevat
Pieni muutos SQL:ssä tarkoittaa:
-
eri cache key
-
ei osumaa query cacheen
Sama sivu voi tuottaa kymmeniä eri SQL-variaatioita, jolloin query cache ei pääse oikeuksiinsa.
Kirjoitukset invalidoivat cachen
Yksi muutos, monta seurannaisvaikutusta
Query cache invalidioituu, kun:
-
post julkaistaan
-
meta päivitetään
-
kommentti lisätään
-
option arvo muuttuu
WordPressissä kirjoituksia tapahtuu jatkuvasti:
-
cron-ajot
-
sessiot
-
laskurit
-
analytiikka
Tämä tarkoittaa, että query cache tyhjenee usein ennen kuin siitä saadaan hyötyä.
Objektivälimuisti vs. query cache
Miksi WordPress suosii object cachea
WordPressin Object Cache:
-
toimii PHP-tasolla
-
ymmärtää WordPressin rakenteen
-
cachettaa loogisia objekteja, ei SQL:ää
Objektivälimuisti:
-
ei riipu SQL:n muodosta
-
on helpompi invalidoida oikein
-
toimii Redisillä tai Memcachedilla
Tämä on syy siihen, miksi WordPress core panostaa object cacheen, ei query cacheen.
Transientit ja sovelluslogiikka
Kohdennettu välimuisti voittaa aina
Transient API:
-
cachettaa laskettuja tuloksia
-
antaa kontrollin elinkaareen
-
vähentää tietokantakyselyitä tehokkaasti
Yksi hyvin sijoitettu transient:
-
korvaa kymmeniä SQL-kyselyitä
-
on ennustettava
-
ei riipu tietokannan sisäisestä toiminnasta
Query cache ei tiedä, mikä tieto on kallista laskea. Sovellus tietää.
Nykyaikainen tietokantaoptimointi
Missä optimointi oikeasti tapahtuu
Modernissa WordPress-ympäristössä:
-
käytetään Redis-object cachea
-
optimoidaan indeksit
-
vähennetään turhia kyselyitä
-
cachetaan kokonaisia sivuja
Query cache ei ole osa tätä kokonaisuutta.
Milloin query cache voi vielä auttaa
Harvinaiset poikkeukset
Query cache voi tuoda hyötyä, jos:
-
sisältö on lähes täysin staattista
-
kirjoituksia on äärimmäisen vähän
-
MySQL-versio tukee sitä
-
ympäristö on yksinkertainen
Useimmissa WordPress-projekteissa nämä ehdot eivät täyty.
Yleisimmät harhaluulot
Tyypillisiä uskomuksia:
-
“query cache nopeuttaa kaikkea”
-
“tietokanta hoitaa optimoinnin”
-
“PHP on pullonkaula”
Todellisuudessa:
-
sovelluslogiikka ratkaisee
-
väärä cache-kerros lisää ongelmia
-
näkyvyys on tärkeämpää kuin automaatio
Miten query cachea kannattaa ajatella
Query cache on:
-
historiallinen optimointikeino
-
huonosti skaalautuva
-
väärässä kerroksessa WordPressille
WordPress ei ole tietokantasovellus. Se on sisältöjärjestelmä, jonka suorituskyky rakentuu useista kerroksista.
Lopuksi: Myytti useimmille, hyöty harvoille
WordPressin kontekstissa query cache on useammin myytti kuin ratkaisu. Se voi auttaa tietyissä, rajatuissa ympäristöissä, mutta modernissa tuotantoympäristössä sen paikka on syrjässä.
Todellinen suorituskyky syntyy:
-
oikeasta cache-kerroksesta
-
selkeästä invalidointistrategiasta
-
sovelluslogiikan ymmärtämisestä
Kun nämä ovat kunnossa, query cachea ei kaipaa kukaan.
