Redis in WordPress: ali spletno stran res pohitri in kdaj se ga splača uporabljati?

Redis se pri ponudnikih spletnega gostovanja vse pogosteje pojavlja ob izrazih, kot so WordPress gostovanje, hitrejši WooCommerce in optimizacija podatkovne baze. Pogosto je predstavljen kot tehnologija, ki lahko občutno pohitri spletno stran.

Toda ali Redis spletno stran dejansko pohitri?

Kratek odgovor je: lahko zelo, lahko pa tudi skoraj nič.

Razlika je predvsem v tem, kakšno spletno stran imamo, koliko vsebine je dinamične in kakšno predpomnjenje že uporabljamo. Pri običajni predstavitveni WordPress strani, ki jo učinkovito predpomni LiteSpeed Cache ali druga rešitev za Page Cache, obiskovalec po vključitvi Redisa morda sploh ne bo opazil razlike. Pri spletni trgovini WooCommerce, strani s prijavljenimi uporabniki ali drugi dinamični aplikaciji pa je zgodba lahko povsem drugačna.

Kaj je Redis?

Redis je zelo hitra podatkovna shramba, ki podatke hrani predvsem v delovnem pomnilniku oziroma RAM-u.

WordPress pri svojem delovanju neprestano potrebuje podatke iz podatkovne baze MySQL oziroma MariaDB. Podatki o objavah, uporabnikih, nastavitvah, izdelkih, kategorijah in številnih drugih elementih se med izdelavo strani pridobivajo in obdelujejo.

WordPress sicer že vsebuje svoj Object Cache, vendar je ta privzeto neobstojen. Podatki v njem obstajajo samo med izvajanjem posamezne zahteve in se med različnimi prikazi strani ne ohranijo. Persistent Object Cache to spremeni.

Če za njegovo zaledje uporabimo Redis, lahko pogosto uporabljeni podatki ostanejo v hitrem pomnilniku tudi za naslednje zahteve. WordPress jih zato ob naslednjem prikazu ni nujno prisiljen ponovno pridobiti ali izračunati. Rezultat je lahko manj dela za podatkovno bazo in hitrejše izvajanje WordPressa.

Redis Object Cache in Page Cache nista ista stvar

To je verjetno najpomembnejša razlika pri razumevanju Redisa.

Če uporabljamo LiteSpeed Cache, Nginx FastCGI Cache ali drugo rešitev za Page Cache, lahko strežnik shrani že izdelano končno HTML stran. Ko naslednji obiskovalec zahteva isto stran, se mu lahko postreže že pripravljena različica, ne da bi WordPress ponovno izvajal celoten PHP in poizvedbe v podatkovno bazo.

Redis Object Cache deluje drugače. WordPress se pri dinamični zahtevi še vedno izvaja, vendar lahko del podatkov pridobi iz zelo hitrega pomnilnika namesto iz podatkovne baze.

Redis in Page Cache zato nista konkurenčni tehnologiji. Vsaka rešuje drug problem in zelo dobro lahko delujeta skupaj.

Kdaj Redis skoraj nič ne pohitri?

Predstavljajmo si preprosto WordPress stran manjšega podjetja. Na njej je deset ali dvajset podstrani, vsebina se spreminja nekajkrat mesečno, obiskovalci niso prijavljeni in stran uporablja pravilno nastavljen LiteSpeed Cache.

Prvi obiskovalec odpre podstran in WordPress jo izdela. LiteSpeed rezultat shrani. Naslednjih sto obiskovalcev dobi že pripravljeno različico strani.

Če se WordPress pri teh obiskih sploh ne izvaja, Redis nima česa bistvenega pospeševati. Zato ni smiselno trditi, da bo vključitev Redisa vsako WordPress stran pohitrila za 50, 100 ali 300 odstotkov.

Če Page Cache že opravi skoraj vse delo, je dodatna korist Redis Object Cachea za anonimnega obiskovalca lahko zelo majhna.

Pri WooCommerce postane stvar precej bolj zanimiva

Spletna trgovina je drugačen primer. WooCommerce vsebuje veliko dinamičnih elementov: košarico, uporabniške račune, zalogo, cene, naročila, filtre izdelkov, različice izdelkov, personalizirano vsebino in številne druge podatke.

Košarice enega obiskovalca seveda ne moremo shraniti v Page Cache in jo nato pokazati drugemu obiskovalcu. Enako velja za checkout in številne strani prijavljenih uporabnikov.

Pri takšnih zahtevah se mora WordPress dejansko izvajati in dostopati do podatkov. Tu začne Redis kazati svojo pravo vrednost.

Če WordPress ali posamezni vtičnik večkrat potrebuje podatke, ki so že shranjeni v Redis Object Cacheu, jih lahko pridobi iz pomnilnika namesto s ponovnim delom nad podatkovno bazo.

Pomembna ni samo hitrost posameznega obiskovalca

Pri Redisu je zelo lahko narediti napako in gledati samo en rezultat testa hitrosti. Recimo, da se stran brez Redisa izdela v 300 milisekundah, z Redisom pa v 220 milisekundah. Razlika 80 milisekund na prvi pogled ne deluje dramatično.

Toda zdaj na spletno trgovino istočasno pride 100 obiskovalcev. Če Redis bistveno zmanjša število operacij, ki jih mora izvajati podatkovna baza, je lahko skupna razlika precej večja. Strežnik mora opraviti manj dela za posamezno zahtevo in lahko istočasno obdela več obiskovalcev.

Zato je ena največjih prednosti Redisa pogosto večja zmogljivost spletne strani pod obremenitvijo, ne samo nekaj milisekund boljši rezultat posameznega testa.

Redis lahko pomaga tudi tam, kjer Page Cache ne more

Še ena zanimiva razlika je WordPress administracija. Strani /wp-admin/ seveda ne moremo običajno servirati vsem uporabnikom iz istega Page Cachea. Redis Object Cache pa deluje na ravni podatkov, ki jih WordPress uporablja.

Zato lahko persistent object cache pomaga tudi pri administraciji WordPressa, prijavljenih uporabnikih, WooCommerce administraciji, zahtevnejših filtrih, REST API zahtevah in drugih dinamičnih operacijah.

Tudi WordPress sam podpira Persistent Object Cache

Persistent Object Cache ni neuraden trik za optimizacijo WordPressa. WordPress ima lasten Object Cache API in v uradni dokumentaciji pojasnjuje uporabo persistent cache rešitev. Pri običajnem WordPress Object Cacheu se podatki ob koncu zahteve izgubijo, s persistent backendom, kot je Redis, pa lahko ostanejo na voljo naslednjim zahtevam.

Redis lahko zmanjša tudi delo s Transients

WordPress in njegovi vtičniki veliko uporabljajo tako imenovane transients – začasno shranjene podatke z določenim časom veljavnosti. Brez persistent object cachea se ti praviloma shranjujejo v podatkovno bazo WordPressa. Če je aktiven persistent object cache, kot je Redis, lahko WordPress te podatke učinkoviteje obravnava prek Object Cachea.

Redis ne more popraviti slabo narejene spletne strani

Redis ima svoje omejitve. Če WordPress potrebuje tri sekunde za prikaz strani zaradi slabo napisanega vtičnika, to še ne pomeni, da bo Redis težavo odpravil.

Prav tako Redis ne bo čudežno popravil slabe SQL poizvedbe, manjkajočih indeksov v podatkovni bazi, ogromnih in slabo vzdrževanih tabel, počasnega zunanjega API-ja, prevelikih slik, ogromne količine JavaScripta, počasnega PHP izvajanja ali strežnika s premalo procesorske moči in pomnilnika.

Če je spletna stran počasna, je zato najprej smiselno ugotoviti, kaj je počasno.

Kako preveriti, ali Redis dejansko pomaga?

Najboljši način ni ugibanje, ampak meritev. Na WordPress strani lahko primerjamo stanje pred in po vključitvi Redis Object Cachea.

Smiselno je spremljati predvsem TTFB (Time To First Byte), število poizvedb v podatkovno bazo, čas izvajanja PHP, cache hits in misses ter obnašanje strani pod obremenitvijo. Za podrobnejšo analizo WordPressa je uporabno tudi orodje Query Monitor.

Je Redis smiseln za vsako WordPress stran?

Za manjšo predstavitveno stran z odličnim Page Cacheom Redis verjetno ne bo tehnologija, zaradi katere bo stran nenadoma dvakrat hitrejša. Pri dinamični strani pa se razmerje spremeni.

Redis je posebej zanimiv za WooCommerce trgovine, večje WordPress portale, strani z veliko prijavljenimi uporabniki, članske strani, forume, strani z veliko podatkovnimi poizvedbami, WordPress Multisite in druge dinamične WordPress projekte.

Redis ni samo za WordPress

Redis seveda ni WordPress tehnologija. Uporabljajo ga najrazličnejše spletne aplikacije in programski jeziki. Poleg predpomnjenja se lahko uporablja za uporabniške seje, čakalne vrste, začasne podatke, API-je, komunikacijo med procesi, omejevanje zahtev in številne druge naloge.

Kateri slovenski ponudniki gostovanja omogočajo Redis?

Pri ponudnikih gostovanja ni dovolj pogledati samo, ali se beseda Redis pojavlja na seznamu funkcij. Pomembno je tudi, kako je Redis implementiran, pri katerih paketih je na voljo in ali ponudnik pomaga pri njegovi nastavitvi.

Webicom

Webicom omogoča uporabo Redis Object Cachea na podprtih cPanel paketih. Zanimiva je predvsem izvedba, saj lahko posamezni cPanel uporabnik uporablja svojo Redis storitev, povezava iz WordPressa pa poteka prek lokalnega Unix socketa. Redis je mogoče povezati tudi z vtičnikom LiteSpeed Cache in tako uporabljati Page Cache in Redis Object Cache hkrati.

Webicom ima objavljena tudi podrobna navodila: Redis Object Cache v WordPressu – nastavitev na Webicom gostovanju.

Hostko

Hostko pri svoji ponudbi WordPress gostovanja navaja Redis Object Cache. Njihovo WordPress okolje temelji tudi na LiteSpeed spletnem strežniku in NVMe diskih, zato lahko uporabnik kombinira strežniško predpomnjenje strani in object caching.

NEOSERV

Redis najdemo tudi v ponudbi NEOSERV, predvsem pri zmogljivejših rešitvah. Redis je smiseln zlasti za zahtevnejše spletne trgovine, portale in druge projekte, kjer je veliko dinamičnih zahtev in dostopov do podatkovne baze.

To seveda niso nujno edini slovenski ponudniki, ki omogočajo Redis. Ponudbe in tehnologije se spreminjajo, zato je pred naročilom vedno smiselno preveriti aktualne specifikacije izbranega paketa.

Redis ali hitrejši procesor?

Če imamo omejen proračun, je zanimivo še eno vprašanje: kaj je pomembnejše, Redis ali zmogljivejši strežnik?

Redis ne more nadomestiti počasnega procesorja, premajhne količine RAM-a ali preobremenjenega gostovanja. Po drugi strani pa tudi zelo hiter procesor po nepotrebnem opravlja delo, če aplikacija vedno znova pridobiva in izračunava podatke, ki bi jih lahko učinkovito predpomnili.

Pri zahtevnem WordPressu je zato najboljša rešitev običajno kombinacija: dovolj zmogljiv strežnik + hiter PHP + učinkovita podatkovna baza + Page Cache + Redis Object Cache + pravilno optimizirana spletna stran.

Torej: ali Redis dejansko pohitri WordPress?

Da, vendar ne vedno toliko, kot bi lahko sklepali iz oglasov.

Pri običajni predstavitveni strani, kjer večino obiskov prestreže učinkovit Page Cache, je lahko razlika za obiskovalca minimalna.

Pri WooCommerce trgovini, prijavljenih uporabnikih, administraciji WordPressa in drugih dinamičnih zahtevah pa Redis lahko zmanjša število dostopov do podatkovne baze, skrajša čas obdelave zahtev in predvsem pomaga strežniku obdelati več sočasnih obiskovalcev.

Zato pravo vprašanje ni: »Ali Redis pohitri WordPress?«

Boljše vprašanje je: »Koliko dela mora moj WordPress pri posamezni zahtevi dejansko opraviti in koliko tega dela lahko Redis prepreči?«

Če skoraj vse obiskovalce že postreže Page Cache, bo odgovor verjetno: ne prav veliko. Če pa mora WordPress za vsakega obiskovalca znova sestavljati dinamično vsebino, izvajati PHP in iskati podatke v podatkovni bazi, lahko postane Redis eden koristnejših delov optimizacije.