Jokainen haluaa nopeamman sivuston. Se tehdään serveripuolella yleensä välimuisteilla. Ensimmäiseksi kannattaa asentaa Hitch hoitamaan SSL-liikenteen ja tarjoamaan http/2-yhteydet sekä Varnish hoitamaan välimuistit ja muut proxy-puuhat. Sitten onkin aika ratkaista PHP-kysymykset ja keskustelu MySQL:n kanssa. Silloin asennetaan Redis. Jos se toimii kunnolla, niin Redis on huomaamaton. Mutta jos se kiukuttelee, niin säätö saattaa olla työlämpää kuin sen antama hyöty. WordPress Multisite saattaa vaatia hieman ekstrahuomiota, mutta se on hoidettavissa kohtuullisen kivuttomasti.

Nopea WordPress on mahdollinen, mutta muutama asia on tehtävä:

• kuvat on oltava järkevän kokoisia pikselikooltaan ja kokoja ei säädetä HTML:llä
• vähennetään kuvien määrää sivuilla
• optimoidaan kuvat ja käytetään CND:ää ainakin mediatiedostoille
• poistetaan turhan lisäosat, ei käytetä Jetpackiä
• asennetaan sivuja tekevä välimuisti, kuten WP Rocket
• otetaan käyttöön serverillä välimuisti, kuten Varnish
• otetaan käyttöön HTTP/2 ja asennetaan Hitch
• viimeisenä: asennetaan PHP:lle Redis

Redis

Redis on niin sanottu object cache. Käytännössä se välimuistittaa PHP-komentoja ja niiden tuloksia. Eniten Redis vaikuttaa tietokantakutsuihin, jonka jälkeen ihan jokaista PHP:n kaipaamaa asiaa ei tarvitse hakea tietokannasta. Kun googlettaa Redisiä, niin ylilauseet ovat aivan tolkuttomia: se nopeuttaa mitä tahansa WordPress-asennusta ainakin tuhatkertaisesti.

Tuo varmasti pitää paikkaansa, jos testataan demosivua wordpress-asennuksella, jossa ei ole mitään toiminnallisuuksia. Kun miettii satakertaisia parannuksia, niin puhutaan mittaluokasta, jossa Pingdomin testin latausaika on tipahtanut vaikka 750 millisekunnista 50 millisekuntiin. Tuossa muutos on 1500 % ja otsikointi on silloin 1500-kertainen. Pienennykset eivät ole kertaisia, vaan pitäisi sanoa, että ilman Redisiä sivu latautui 15 kertaa hitaammin – mutta se ei ole yhtä dramaattinen kuin 1500.

Se, että pelkästään nettiyhteyden lagaavat enemmän, on sitten toinen juttu. Tuo nopeusetu ei tuollaisenaan näy käyttäjälle.

Aidolla verkkosivulla sisällön ja toiminnallisuuden kanssa Redis ei koskaan anna silminnähtävää etua, jos kaikki muut asiat on tehty oikein. Suurin välimuisteihin liittyvä parannus saadaan dynaamisen sisällön staattisiksi sivuiksi muuttavien pluginien kanssa ja niistä toimivin sekä tehokkain on eittämättä WP Rocket.

Redis tulee mukaan kuvioihin siinä vaiheessa, kun serverin kuorma alkaa kasvamaan ja kävijämäärät lisääntyvät. Katiskassa Redisin tuoma etu alkaa näkyä, kun yhtä aikaisia kävijöitä on yli 50. Ja nyt tulee se koukku: kävijöiden täytyy olla kirjautuneena ja tehdä jotain dynaamista.

Olen julkaissut Katiskassa uuden jutun ja aiheuttanut kävijäpiikin. Juttu tulee suurimmalta osaltaan WP Rocketin tekemästä staattisesta cachestä ja lopputulos on varastoitu Varnishin välimuistiin. Ei sitä lueta Apachelta, ja se tarkoittaa, että Redis istuu ja pyörittää peukaloitaan laiskana.

Tai ainakin melkein laiskana, sillä mukana on aina jotain dynaamistakin, kuten vaikka Googlen mainokset. Ja tässä tulee vastaan Redisin kysymysmerkit ns. tavallisilla sivustoilla. Kun sisältö haetaan ulkoa, niin se haetaan ulkoa. Välimuistit ohitetaan. Se on aina hidasta. Paras nopeusetu saadaan estämällä Googlen mainokset ja hiukan lisää tarjoamalla Analytics omalta serveriltä (WP Rocket mahdollistaa sen, mutta erillinen plugari CAOS tuntuisi olevan tehokkaampi). Sitten kun dynaaminen lopputulos, vaikka uusimpien postausten lista, tulee omasta tietokannasta, niin se varastoituu Redisille. Ja seuraavalle pyytäjälle esitetään sama pyyntö välimuistista, ei se muutu. Tilanteesta riippuen se tarkoittaa, että joko on ongelma tai ei ole. Jos on ongelma, ja se korjataan estämällä sen objektin/resurssin välimuistittaminen Redisin avulla, niin Redis muuttui hyödyttömäksi tuolta osin.

Minulla vaihtelee Varnishissa ”parasta ennen päiväykset” välimuistissa olevalle sisällölle tunnista päivään, viikkoon ja vuoteen. Jos Redisin antaa muistaa vaikka 3600 sekuntia eli tunnin, niin jossain vaiheessa törmää ongelmiin WordPressin hallinnassa – on vaikka päivittänyt lisäosat, jotka eivät olekaan päivittyneet. Tai on asentanut lisäosan, joka ei ole poistunutkaan. Tuo kaikki tulee Redisistä, Joku osaava osaa varmaan konfiguroida sen niin, että moiset eivät kiusaa. Minä olen löytänyt ainoiksi ratkaisuiksi lyhyemmän TTL-ajan ja tyhjentää manuaalisesti Redisin cachen.

300 sekuntia eli 5 minuuttia toimii hieman paremmin, jos ei pidä kiirettä. Mutta silti saa olla erikseen tyhjentämässä Redisin cachea, kun tekee taustalla jotain järjestelmään liittyvää – mutta ei liioitella asiaa, kyse on ehkä parista kerrasta viikossa.

Kun toimiva ”säilytysaika” on jotain 5 minuutin ja tunnin välillä, niin törmätään taas kävijämäärään. Jos kävijöitä tulee hieman yli tunnin välein, niin yksikään ei saa yhtään mitään Redisin cachesta. Ja Redis on silloin hyödytön. Jos päivässä vaikka tusina ihmistä käyttää samaa sisältöä niin, että kaikki välimuistit tekevät parhaansa, niin kannattaako kaikki vaiva vain siksi, että he saavat sisältönsä sekunnin nopeammin? Nyt täytyy muistaa, että valtaosa Suomen sivustoista ei todellakaan kerää satoja yhtä aikaisia kävijöitä ja suurin osa webmastereista korkkaa pullon kuohuvaa, jos päivän kokonaissaldo ylittää sadan. Tosin, jos kysyt määristä, niin aivan jokaisella on ainakin 10 000 kävijää. Aika monet myös valehtelevat.

Se, että cache ei lämpene, on aina ongelma. Tai ainakin seuraus. Tätä kirjoitettaessa on heinäkuun loppu sekä helle, ja minä olen tehnyt serverihommia. Tarkoittaa sitä, että Katiskassa on kävijäkato. Päivässä piipahtaa 500 – 700 välillä, kun normaali ”tyhjäkäynti” on 1000 – 1500 ja jos julkaisen jotain, niin kävijämäärät ovat 2000 – 5000 päivässä. Seurasin Varnishia ja hieman ihmettelin miksi cachestä tuli niin vähän sisältöä. Se johtui täysin siitä, että kävijät olivat päämäärättömiä surffailijoita, jotka lukivat harvoin samoja kuin joku muu aikaisemmin. Eli he eivät koskaan saaneet mitään cachestä. Ja tässä olisi Redis ollut suunnilleen samassa tilanteessa – missään vaiheessa ei tule tilannetta, että pääsisi tarjoamaan välimuistitettua asiaa.

Pitkähkö aloitus sille, että jos sinulla ei ole aitoa kuormaa, vaan olet asentamassa Redisiä vain siksi, että WordPress tai sen hallinta on hidas, niin Redis tuskiin korjaa tai parantaa yhtään mitään. Sen sijaan on olemassa riski, että se rikkoo. Tai menee itse rikki.

Asentaminen Ubuntuun

Redisin asentaminen on yhtä helppoa kuin oikeastaan kaiken muunkin. Taas: käytän esimerkeissä root-tunnusta. Joten muista sudo tai su, jos sinä et halua.

apt update

apt install redis-server

Laitetaan perusasetukset kuntoon.

nano /etc/redis/redis.conf

Kelaa tiedosto sen matkaa alaspäin, tai käytä hakua (ctrl+w nanossa), että löydät tämän:

supervised no

Muuta se muotoon:

supervised systemd

Nyt Redis tottelee systemctl-komentoja.

Mene tiedoston loppuun ja lisää nämä:

maxmemory 215mb

maxmemory-policy allkeys-lru

Ne löytyvät kommentoitunakin tiedostosta, jos haluat ne laittaa ns. omille paikoilleen. Loppuun laitto on vaan helpompaa.

maxmemory on se muistimäärä, joka Redisillä on käytössä. Sehän pitää cachensä muistissa. Dokumenteissa sanotaan, että 50 megaa riittää helposti yhdelle WordPressille ja 256 megaa on reilusti isoillekin paketeilla. Minä laitoin 512 megaa. Osaksi koska muistia oli vapaana, osaksi koska minusta nuo suositukset on aina alakanttiin. Ja saahan sitä vaihdettua myöhemmin, jos siltä tuntuu. Mutta cache, joka joutuu tyhjentämään tilanpuutteen takia vanhempaa dataa, on aika turha cache.

Tallenna. Jos haluat tehdä Redisistä turvallisemman ja asettaa salasanaa, muuttaa komentoja jne, niin googleta. Itse en näe niille suurempaa tarvetta, koska en ajatellut päästää ketään vierasta shelliin.

WordPress

Asenna lisäosa Redis Object Cache. Se tekee pääosan työstä WordPressin päässä.

https://fi.wordpress.org/plugins/redis-cache/

Multisite-asennuksissa se kannattaa sallia Verkkotasolla kaikille. Käynnistä lisäosa.

Avaa wp-config.php ja lisää sinne seuraavat. Ne täytyy lisätä kaikkiin WordPresseihin, jos sinulla on useampi virtual host. Ja jos sinulla on jonkun domainin takana jotain muuta kuin WordPress, niin onnea matkaan – en tiedä niistä yhtään mitään.

Kerrotaan WordPressille, että cache on käytössä.

define('WP_CACHE', true);

Tämä määrää kuinka kauan asiat pysyvät välimuistissa.

define('WP_REDIS_MAXTTL', 900);

Aika on sekunteina, joten 900 on 15 minuuttia.

Lisää nämä kaksi riviä, jos sinulla on useampi wordpress-asennus eri domaineilla.

define('WP_REDIS_DATABASE', 1);

$redis_server = array( 'host' => '127.0.0.1', 'port' => 6379, );

Laita jokaiselle wordpress-asennukselle oma tietokanta. En tiedä, onko tämä aidosti pakollinen, mutta eipähän sitten sekoa. Oletuksena käytössä on 16 tietokantaa. Älä muuta porttiriviä.

Itse aloitan numeroinnin ykkösestä. Pelkästään siksi, että nolla on oletus. Jos unohdan jonkun, tai en saa sitä laitettua, koska ei ole WordPress, niin se menee sitten automaattisesti nollaan. Silloin ainakaan WordPressit eivät ole mukana sekoittamassa pakkaa.

Lisää tämä sinne missä on muutkin saltit. Tai alkuun, miten vain haluat.

define('WP_CACHE_KEY_SALT', 'example.com');

Voit laittaa siihen randomin merkkijonon, domainin, saitin nimen… Domainia varmaan suurin osa käyttää. Kunhan se on jokaisella virtual hostilla erilainen. Redis ei muutoin tiedä kuka on pyytänyt mitäkin. Silloin esimerkiksi kahden wordpress-sivuston esittämät asiat voivat vuotaa toinen toisilleen. WP_CACHE_KEY_SALT pitää oikean paikan asiat niille kuuluvassa paikassa.

Kootaan kaikki yhteen, jos haluat kopypeistata ne kerralla.

define('WP_CACHE', true);
define('WP_REDIS_MAXTTL', 900);
define('WP_REDIS_DATABASE', 1);
$redis_server = array( 'host' => '127.0.0.1', 'port' => 6379, );
define('WP_CACHE_KEY_SALT', 'example.com');

Jos sivusto kaatuu, niin käytännössä syynä on aina joku puuttuva puolipiste tai ylimääräinen merkki.

Nyt on aika käynnistää Redis.

systemctl start redis

Siirry WordPress-sivuston hallintaan ja Asetukset > Redis (Multisitessä se löytyy Verkon puolelta). Klikkaa nappulaa Enable object cache. Nappula Flush cache kannattaa painaa mieleen. Sitä kannattaa näpäyttää aina ennen päivityksiä tai jos tulee sellainen olo, että kaikki ei ole ihan niin kuin pitäisi.

Toimiiko cache?

Koska missään ei näy mitään viisareita eikä laskureita, niin meillä ei ole varmaa tietoa, että meneekö mikään Redisin kautta välimuistiin, Joten tarkistetaan.

redis-cli monitor

Odota hetki ja rivejä pitäisi näkyä. Jos on hiljaista, niin varmista se käymällä saitilla ja piipahtamalla jollekin sivulle. Käyntisi pitäisi näkyä. Jos ei näy, niin vilkaise, että Redis on ylipäätään hengissä.

systemctl status redis

Jos se on punaisella, niin jokin on mennyt pieleen. Tarkista ensimmäiseksi conf tiedosto. Muuten en pysty auttamaan, koska minulla on Redis toiminut sinällään aina täysin moitteetta.

Jos/kun sinulla tulee tarve tyhjentää välimuisti, niin shellin kautta se onnistuu helposti – mutta siinä menee sitten kaikkien sivustojen välimuistit.

redis-cli flushall

Ongelmakohtia

Minulla Redis on aiheuttanut ongelmia eniten WordPressin hallinnan puolella ja nimenomaan aina lisäosiin liittyen, Yleensä asetukset eivät ole muuttunut tai poisto/lisäys ei ole näkynyt. Redis on tarjonnut välimuistista vanhaa tietoa. Tuosta on selvinnyt joko tyhjentämällä välimuistin tai pysäyttämällä Redisin lisäosasta. Hieman liian työlästä rutiinihommissa – varsinkin kun nopeushyötyä ei oikein näkynyt.

Varnishin ja Redisin pitäisi toimia täysin ongelmitta yhdessä ja ne hoitavat cachet aivan eri tavalla, mutta ongelmaa oli silti. Serverin tilastoissa näkyi pieni pysähdys niin levyn kuin muistin käytössä, mutta prosessori on silti tehnyt töitä. En alkanut selvittämään, että olisiko syy Varnisihin asetuksissa, kuten että olen sallinut vain yhden ytimen käytön ja niitä on kuitenkin kuusi, tai onko jommallakummalla liikaa muistia varattuna – muistista ei kuitenkaan ollut käytössä kuin hikisesti neljännes. Jossain vaiheessa pysähtely poistui, joten ehkä syypää olikin joku muu, vaikka backup.

WordPress Multisite

Redis sinällään on yhteensopiva kaikkien kanssa. Ei sille ole merkitystä mistä liikenne tulee ja on cachen hyödyntäjän asia hoitaa data tarvitsemallaan tavalla. Tämä tarkoittaa sitä, että kun kysytään onko Redis yhteensopiva WordPress Multisiten kanssa, niin tarkoitetaan onko lisäosa Redis Object Cache multisivustoyhteensopiva. Helppo vastaus on, että kyllä se on.

Vaikea vastaus on, että sitä saattaa joutua säätämään. Mutta se pätee ihan yksittäisenkin Worpdress-asennuksen kanssa. Käy vilkaisemassa lisäosan sivua ja keskity kohtiin

• WP_REDIS_GLOBAL_GROUPS
• WP_REDIS_IGNORED_GROUPS

En valitettavasti osaa sanoa mitä kannattaa säätää. Mutta varmaan kannattaa lähteä liikkeelle siitä mikä hannaa vastaan.

Huuhtelunappi

Jos on laiska kaivamaan esille Redisin asetuksista Flush cache nappulan, niin sen saa adminin työkalupalkkiin.

Laita tämä koodi teeman/lapsiteeman functions.php – tiedostoon tai mieluiten käytä Snippets lisäosaa.