Varnishin toiminta omalla serverilläni

Olen käyttänyt Varnishia pitkään reverse proxynä ja cachena servereilläni. Käytön ja toiminnan olen opetellut puhtaasti kokeilemalla ja huomattavan useasti kantapäätaktiikalla. Olen tehnyt jotain, rikkonut kaiken ja sitten selvitellyt mitä, missä ja miksi.

Pitkä ja työläs polku

Yhdessä vaiheessa kuningasajatukseni oli laittaa Hitch eteen tyhmäksi proxyksi terminoimaan SSL:ää omalle pienelle serverilleen Nginxin ja Varnishin kanssa, ja sitten jokainen sivusto ripoteltuna sinne tänne omille erillisille VPS:lle. Siinäkin oppi jotain, kuten iptablesin sielunelämää, mutta ehkä vahviten sen kuinka paljon moinen hidastaa, kun ei ole varaa maksaa laadusta.

Olen riidellyt kunnioittavan määrän tunteja yrittäessäni saada Varnishin toimimaan yhdessä WooCommercen, Gitean, Moodlen ja Discoursen kanssa. En ymmärtänyt sitä mitä dynaaminen ja käyttäjäkohtainen sisältö aidosti tarkoittaa moisen cachen kohdalla.

Älä edes yritä. Noiden kanssa Varnishista saattaa olla jotain iloa load balancer -hommissa ja hieman filtteröimässä määrättyjä sisääntulevia asioita, mutta siinä kaikki. Sekä niissä on yleensä oma järjestelmä cacheamassa sen mitä pystytään. Varnishissa ei noiden kanssa useinkaan edes return(pass) riitä, vaan on pakko, tai järkevää, tehdä perustason asioiden jälkeen return(pipe) ja päästää pyyntö sellaisenaan Varnishin läpi.

WooCommerce on hankala. WordPress on jo lähtökohtaisesti perin raskas, siltä osin sen suunnittelu, PHP-toteutus ja tietokannan käyttö, on jotain muuta kuin tältä ajalta. Mutta silti verkkokaupan minkäänlainen cacheaminen on tehokas tapa hankkia itselleen ikävyyksiä. Toki se onnistuu, mutta silloin on syytä tietää tarkkaan mitä tekee, eikä harrastaa sekalaisista lähteistä kopiointia.

Eniten turhaa työtä tein kuitenkin Discourse-foorumin kanssa. Se on täysin epäyhteensopiva Varnishin kanssa. Kyllä, alun perusasiat pystyy tekemään, mutta ei yhtään mitään muuta ja se on pakko päästää pipellä suoraan läpi.

En oivaltanut Discoursen kohdalla sen oleellista eroa muihin sivustoihini verrattuna. Se ei ole sivusto. Se on web-appi, joka kävijän suhteen toimii hänen laitteessaan. Tarvittavat JavaScriptit siirretään asiakkaalle, ja siksi ensimmäinen käyntikerta on hieman hidas. JS suoritetaan aina kävijän laitteella (siksi mm. Adsensen JS:n voi cachettaa, eikä se vaikuta mainoksiin), mutta sen jälkeen kaikki foorumiviesteihin liittyvät liikkuvat JSON-muodossa. Ja niitä ei todellakaan voi änkeä välimuisteihin.

Olenko ammattilainen Varnishin kanssa? Kaukana siitä, enintään hieman valistuneempi harrastelija.

Nykyinen setup

Tällä hetkellä minulla on Varnishin takana

• kuusi puhdasta WordPressiä
• yksi WooCommerce
• Matomo

Olen luopunut Moodleista, koska tarve loppui. Gitean poistin, koska GitHub on minulle riittävä, enkä aidosti tarvinnut omaa alustaa repoille. Minulle kun se on vain eräänlainen backup. Kahta Discoursea en enää edes yritä pakottaa samaan, vaan ne toimivat omilla VPS:llään tyytyväisinä omillaan.

Muutoin rakenne on hyvin simppeli ja tyytyväinen:

• Nginx (reverse proxy, SSL)
• Varnish (cache)
• Apache2 (backend, missä sivustot ovat)

MariaDB, PHP-FPM jne.

Joten pääperiaate on selvä. Kävijä saapuu Nginxiin. Tarkistetaan SSL ja tehdään pari muuta temppua, kuten vilkaistaan onko user agent sallittu (kyllä, inhoan syvästi botteja), onko url sallittu jne. tuon kaltaisia asioita, joissa Nginx on tehokkain. Nginx lähettää kävijän/pyynnön Varnishille.

Varnish tekee geoip-blokkauksen (kyllä, läpipäässeitä botteja, koska muutoin venäläinen, intialainen, kiinalainen tai vietnamilainen ei tulisi suomenkieliselle sivustolle) sekä yksinkertaistaa pyynnön sellaiseksi, että se on cachetettava, jos sitä ei ole vielä siellä. Siinä tapauksessa pyyntö jatkuu backendin Apache2:lle sellaisessa muodossa, jossa se moisen tarvitsee. Eli siivotaan pois mm. turhat seurannat, evästeet jne.

Silloin sivusto tekee sivun ja lähettää sen takaisin Varnishille. Se laittaa saadun sivun välimuistiin sekä jakaa sen takaisin viereilijalle Nginxin kautta.

Mutta jos pyydetty sivu löytyy välimuistista, niin hauskuus alkaa. Silloin Apache2, tietokanta ja PHP eivät tee yhtään mitään, ja se kierto on varsinainen pullonkaula, joka hidastaa sivustoa. Varnishin välimuisti on RAM:ssa, nopeimmassa mahdollisessa muistissa, ja sieltä pyydetty sivu välitetään silmänräpäyksessä takasin Nginxille ja kävijälle.

Joten Varnishin etu ei ole pelkästään siinä, että kävijä saa sivunsa nopeammin näkyviin ja suurin hidaste, johon ei voida enää vaikuttaa, on ns. netin nopeus — kaikki yhdessä, serverien välimatkat ja asiakkaan omat yhteydet.

Suurin etu on siinä, että oma serveri ei tarvitse enää niin paljon tehoja. Saa laskettua kuluja. Samalla Varnish on ehkä tehokkain työkalu haittaliikenteen estämisessä, ja se vasta säästääkin. Enemmän kuin välimuistittaminen.

Suurimmalla sivustollani on kävijöiden määrä päivässä 10 000 – 15 000 tällä hetkellä. Joten tarvitsisin turhan kalliin serverin kyetäkseni palvelemaan jokaista ilman palvelimen ajoittaista kaatumista. Mutta tuosta määrästä vain 2000 on ihmisiä. Loppu on puhdasta haittaliikennettä.

Joten kun Varnish (ja hiukan myös Nginx) estää selvimmät tapaukset, niin tarvitsen konetehoa huimasti vähemmän. Minun tasollani se tarkoittaa, että VPS, joka pyöritti puolta tusinaa WordPressiä ja kahta Moodlea, maksoi 60 euroa kuukaudessa alvitta. Mutta se ei riittänyt, ja olin suunnassa, että joudun seuraavaksi vuokraamaan 180 euroa kuussa maksavan.

Nyt Varnishin kanssa pyöritän samaa kävijämäärää 15 euroa maksavalla serverillä.

Mitä hakemistoissa piilee

Käytetty Varnishin setup löytyy täältä:

https://github.com/eksiscloud/Varnish_7.x

Olen pyrkinyt kommentoimaan mitä on tehty ja aika ajoin jopa miksi.

Minulla ei ole ehkä tyypillisin amatööritason asennus. Olen kokeillut useampaakin tapaa hoitaa sivustoni, ja tämä viimeinen on ainoa, johon olen kohtuullisen tyytyväinen. Se on siedettävän helppo kun täytyy muuttaa, muokata tai lisätä jotain, mutta ei helpoin lukea. Ainakaan jos siihen ensimmäisen kerran törmää.

Oletan, että sinulla on edes jonkinlainen käsitys siitä miten Varnish toimii, joten en selitä syväluotaavasti eri toimintoja. Enemmänkin keskityn kuvaamaan mitä tapahtuu.

Juuressa on perustason ohjaukset

• default.vcl, joka ohjaa oikean hostin vcl:ään
• emergency.vcl kun Varnishin toimintaa täytyy muuttaa paniikkitilanteissa; laittaa kaikki return(pipe)
• start.cli jota muokkaamalla saa valittua miten käynnistys tapahtuu esim. systemctl restart varnish kanssa

Hakemistossa sites on eri hostien, sivustojen, ikiomat vcl:t. Eli ne, jotka olisivat perusasennuksessa jokainen ikioma default.vcl:nsä.

Koska sivustot oma samanlaisia WordPressejä jokainen, suurin ero on isännöikö joku podcasteja vai ei, niin yhteiset ovat on jaettu omiin ali-vcl tiedostoihin, joita kutsutaan sivuston vcl:ssä sopivassa paikassa. Tällä saan estettyä sen, että jos muutan tai lisään jotain yhteistä, niin minun ei tarvitse muokata jokaisen hostin vcl:ää erikseen.

Muutaman asian olen joutunut jättämään hostien tiedostoihin, koska aivan kaikkea ei voi tehdä ali-vcl:ssä. Geoip on sellainen asia.

Nuo omiinsa laitetut yhteiset ali-vcl:t löytyvät hakemistosta include. Ne ovat siis kaikki sellaisia, jotka normaalisti löytyisivät tavalla tai toisella default.vcl:stä.

Hakemistossa ext on myös ali-vcl:iä, mutta omaan käyttään rakennettuja. Kuten user-agent muutoksia, uudelleenohjauksia ja sellaisia. Ne ovat omassa hakemistossaan vain historiallisin perustein. Joskus aloin tekemään niin ja se vain jäi, vaikka varsinaista tarvetta ei enää ole.

GitHubissa on pari muutakin hakemistoa, mutta ne eivät liity suoraan siihen mitä Varnish vaatii toimiakseen. Varnishiin liittyviä kylläkin.

Ai miksikö nimeän englanniksi? Nätti selitys olisi, että koska jaan nämä mm. GitHubin kautta, niin ehkä niitä voisi hyödyntää joku sellainenkin, joka ei suomea osaa. Aito selitys on tapa. Alkujaan kaikki löytämäni lähteet olivat englanniksi, joten minäkin käytin englantia, jotta olisi helpompi löytää myöhemmin asiaa, jos/kun on tarve etsiä. Se sitten jäi käytännöksi.

Kun kävijä saapuu

En selitä Nginxin toimintaa. Se on aika tyypillinen ja Nginx vain lähettää liikenteen Varnishille porttiin 8080 sopivien headereiden kanssa.

En muista enää miksi aloin käyttämään porttia 8080, kun ohjeet tyypillisesti ehdottavat muistaakseni 6891, koska varnishin adm käyttää porttia 6892. Ehkä siksi, että minulle tuo numerosarja oli vieras, ja oli luontevampaa toistaa http-portti.

Mitään käytännön merkitystähän tuolla ei ole.

init ja muut

Alussa, ennen kuin varsinainen työ alkaa, kerrotaan mitkä nippelit ovat saatavilla ja missä ne ovat. Samaten kerrotaan Varnishille missä se backend sijaitsee.

vcl_recv

Osio vcl_recv käsittelee ja siivoaa pyynnöt. Poistetaan turhat, kuten seurantakoodit, koska Apache2, ja vielä vähemmän cache, tarvitsee niitä. Käytännössä se mitä tehdään ei vaikuta siihen mitä menee välimuistiin, mitä haetaan välimuistista ja mikä päästetään ohi välimuistiin. Asiat vain laitetaan sellaiseen muotoon, että jos jotain tehdään, niin mukana ei ole turhaa roipetta.

Kaikki on toki oleellista, mutta ensimmäinen varsinainen oleellinen asia varmistaa on, että tärkeintä paikkaa ei välimuistiteta. Se tarkoittaa WordPressin hallintaa ja kirjautumista.

Joten sen takia vähintään wp-admin-polku ja kirjautumisen wp-login.php on päästettävä ohi cachen backendille ennen kuin tehdään mitään muuta.

Kun admin ja kirjautuminen on turvattu, niin on aika siivota evästeet. Tämä on tehtävä siksi, että Varnish ei cacheta eikä hae mitään cachesta, jos mukana on mikä tahansa eväste. Oletus on, että cookie asettaa jotain henkilökohtaista, ja käyttäjään liittyvää sisältöä ei laiteta välimuistiin. Se on muuttuvaa ja liittyy vain yhteen nimenomaiseen käyttäjään.

Cookien kanssa pystyy välimuistittamaan, jos ehdottomasti haluaa ja kyseessä on tilanne, että sisältö on ehdottomasti yleistä. Mutta lähes aina tilanne on kierrettävissä, eikä cookieta tarvita. Kuten kieliasetusten kanssa.

Sellaiset evästeet jätetään rauhaan, jotka ovat sivuston toiminnan ja käyttäjän saaman sisällön suhteen ehdottoman välttämättömiä. Kuten cookie, joka kertoo onko kävijä kirjautunut WordPressiin.

Turhat murennetaan ja hävitetään. Sellaisia ovat seuranta- ja mainos-evästeet, kuin myös analysoinnit jne. Cache ei tee niillä mitään, eikä tee Apachekaan, joten sivustoille ja sisällöille ne ovat täysin turhia.

Nyt päästään asiaan.

Per url ja jopa tiedostotyyppi täytyy kertoa Varnishille milloin ohitetaan välimuisti ja haetaan Apachelta, ja milloin on lupa hakea cachesta ja mahdollistaa välimuistittaminen.

On oleellista ymmärtää, että vcl_recv ei laita mitään välimuistiin. Se hakee välimuistista ja mahdollistaa myöhemmin cachettamisen.

Varnish tekee asioita järjestyksessä, joten sillä mitä tehdään missäkin järjestyksessä on merkitystä. Jokainen return(...) haarauttaa jonnekin, ja jos osa kyselystä päästää hakemaan cachesta return(hash) avulla, niin on aivan se ja sama olisiko myöhemmin tullutkin käsky mennä cachen ohi hakemaan Apachelta — sitä käskyä ei koskaan nähdä.

Joten järjestystä täytyy hieman miettiä.

Yleensä järjestys on, että

• ensimmäiseksi laitetaan return(pipe)koska se ohittaa Varnishin kokonaan
• toiseksi laitetaan jokainen return(pass) koska se ohittaa välimuistin ja hakee Apachelta
• viimeisenä tulee return(hash) sillä silloin käytetään välimuistia; käydään katsomassa onko objekti sillä hashillä cachessa ja jos ei ole, niin jatketaan Apachelle, mutta tehdään ikäänkuin paikkavaraus, jos myöhemmin sanotaankin, että tämän voi tarjoilla myöhemmin välimuistista muille kävijöille

Sivucache vs. objekticache

Vaikka sanoinkin, että en mene siihen miten Varnish toimii, niin ehkä tässä sopii piipahtaa. Lähinnä siksi, että se on niin oleellinen asia ymmärtää — ja minulle vaikea ymmärtää. Ja toiseksi ehkä aihe on syytä käsitellä, koska vcl_recv on osio, jossa määrätään kuka saa tyhjentää välimuisteja ja miten.

WordPressin omat cachet ovat ns. sivucacheja. Ne tekevät eräällä tavalla kopion koko sivusta ja tallentavat sen levylle, kuvineen päivineen. Eli kovalevyllä on odottamassa valmis sivukopio kuvia myöten, aivan kuin joku olisi käsin tehnyt sen HTML:llä. Sanotaan, että sivusisällöstä on staattinen kopio.

Aikasäästö otetaan siitä, että PHP:n ja tietokannan ei tarvitse kerta toisensa jälkeen rakentaa uudestaan samaa sisältöä.

Varnish on objekti-cache. Tarkoittaa sitä, että jokainen osa on oma objektinsa. URL:n mukainen sivu teksteineen on oma objektinsa. Niin on myös sivulla olevat kuvat ja ikonit jokainen erikseen oma objektinsa. Myös ulkomuodon rakentavat CSS-tyylitiedostot ovat oma objektinsa.

Silloin voidaan Varnishin cachesta poistaa, tai vaihtaa uuteen sisältöön, koko sivuteksti. Tai pelkästään logo. Jos ulkomuoto on vaihtunut, niin päivitetään cacheen vain CSS.

Tuo mukanaan sen, että Varnishin cachen hallinta on suunnattoman tarkan kohdennettua, mutta samalla myös aika monimutkaista. On sanottu, että ” There are only two difficult things in computer science: cache invalidation and naming things” ja tämä pätee Varnishissa. Minulla meni kaksi täyttä työpäivää, että sain cachen tyhjennyksen toimimaan; asia, jossa en ole onnistunut viimeisen noin 7 vuoden aikana ja siksi aina jyräsinkin koko cachen.

Se sub-vcl, jossa määritellään PURGE eli välimuistin tyhjentäminen, oli täysin työvoitto. Omalla tavallaan se oli yksi kolmesta tärkeimmästä osasta — kaksi muuta ovat cookiet ja TTL-säännöt, eli mitä välimuistitetaan ja kuinka kauan — ja sen ongelman ratkeaminen helpotti ylläpitoa todella paljon.

Aidosti minulla ei tehdä PURGEa. Se on välimuistissa olevan objektin suora poisto, delete eräällä tavalla. Minulla asetukset on tehty siten, että se on aidosti BAN, eli objekteja korvataan tuoreella aina hissukseen tarpeen mukaan. Se säästää hiukan tehoja ja energiaa, mutta lopputulos on sama.

WordPressin sivucachessa tyhjentäminen on helpompaa, mutta se perustuukin koko tallennetun sivusisällön poistamiseen ja uuden rakentamiseen.

Kun julkaisen tämän, niin cachesta poistetaan ja rakennetaan uudelleen pelkästään etusivun tekstit, sivupalkin tekstit sekä kategorian arkisto. Kaikki muu jää välimuistiin, koska ne eivät ole muuttuneet.

Ai niin, se hash. Se on vain tiedostosta laskettu numerosarja, jota käytetään välimuistissa tunnistamaan objekti. Paikkanumero. Joten ehkä ”vain” oli pahaa vähättelyä

vcl_backend_response

Kun kävijän pyyntö on lähtenyt vcl_recv osiosta, niin sillä on neljä vaihtoehtoista reittiä riippuen siitä kuka on pyytänyt mitäkin.

Esimerkiksi

• erikoistapauksessa pyyntö saa return(pipe) jolloin se lähetetään suoraan backendille kiertelemättä missään ja ilman, että Varnish puuttuu mihinkään. Apache2 tekee mitä tekee, ja vastaus palaa aivan yhtä suoraan Nginxin kautta maailmalle
• minä sisäänkirjautuneena adminina pysyn Varnishin rutiineissa, mutta menen return(pass) kautta cachen ohi Apachelle backendiin ja sitten sieltä takaisin Varnishiin
• satunnainen kävijä tulee Googlen hakutuloksista juttuun, jota ei ole luettu aikoihin, niin hän menee return(hash) kautta, mutta ei löydä välimuistista hakemaansa ja jatkaa matkaa Apacheen. Sivu tehdään ja hän palaa takaisin Varnishiin
• toinen satunnainen kävijä klikkaa linkkiä Facebookissa ja haluaa saman artikkelin kuin 1000 ennen häntä, ja löytää cachesta sen. Se annetaan ja hänet siirretäänkin Varnishin sisällä uloskäynnin suuntaan

Ensimmäinen oli selvä tapaus. Varnish on vain suora putki. Viimeinen tapaus on helppo ja siirtyy cachesta tietonsa saaneena viimeiselle etapille ennen kotiin lähtöä. Tapaukset 2 ja 3 sen sijaan siirtyvät osioon, jossa käsitellään tapaukset mitä tehdään, kun backendistä eli Apachelta saadaan vastaus. Varnishin vcl:ssä tuon osion nimi on vcl_backend_response

Varnishissa voidaan muuttaa monia asioita. Cookieita voidaan poistaa tai muokata. Selaimen lähettämiä tietoja, kuten vaikka kielipyyntö, user-agent, pakkaustapa jne. headereissa olevaa voidaan poistaa tai muokata sen mukaan mitä backendille halutaan lähettää.

Sama toimii toisinpäin. WordPressin lisäosa, joka vahtii latauksia, haluaa kirjoittaa cache-control headeriin, että mitään ei saa laittaa välimuistiin ja tekee sen sitten koko sivuston laajuisesti. Siinähän laittaa mitä huvittaa, koska nuo kaikki muutetaan. Apache2 voi lähettää tiedon kuinka kauan mitäkin tietostoa tai tiedostotyyppiä pidetään välimuistissa, ja lisäksi missä. Ihan vapaasti, koska Varnishissa ne muutetaan kaikki. Pakko ei ole, mutta useimmiten näin tehdään.

Jokaikinen saatu response-header on poistettavissa tai muutettavissa. Jos halutaan jokin header asiakkaalle, jota backend ei ole lisännyt, niin sitten se lisätään Varnishin puolella.

Osiona vcl_backend_request on melkoisen tärkeä. Siellä päätetään mikä menee cacheen ja kuinka kauan se on siellä. Näin siksi, että sinne saavutaan backendistä, ja backendiin on päädytty siksi, että jotain ei ole ollut cachessa. Nyt se tieto on haettu ja välimuistin täytyy saada ohjeet laitetaanko se talteen seuraavalle kävijälle, joka pyytää samaa.

Saman pyytäminen on tässä se ongelma ja se syy miksi response- eli vastaus headereita on pakko muokata. Vary on yksi sellainen header, joka saa adminin pään helposti särkemään.

Oletetaan, että on haettu tätä artikkelia. Apache2 lisää mukaan Varyn. Vary-header kertoo välimuistille millä perusteella se voi tarjota eri versioita samasta sivusta eri käyttäjille. Esimerkiksi:

• Vary: Accept-Encoding → tarjoa gzipattua versiota, jos selain tukee sitä
• Vary: User-Agent → tarjoa eri sisältö käyttäjälle sen mukaan mikä hänen laitteensa ja selaimensa on

Jokainen uusi Vary-arvo luo uuden välimuistiversion. Accept-Encoding on perusteltu, koska gzip pakattu on erilainen br pakattu — tosin sitäkään ei tarvitse säästää, koska Varnish osaa hoitaa pakkaukset, mutta silti.

Mutta jos headerissa on vaikka Vary: User-Agent, niin cache leviää käsiin. Ihan siksi, että sisältö on koko ajan sama, mutta jo pelkästään Samsungin eli malleilla ja jokaisella selaimella on erilainen User-Agent. Siihen kaikki muut päälle. Erilaisia User-Agenteja on tuhansittain, ja silloin oltaisiin tilanteessa, että sama juttu tallennettaisiin tuhat kertaa. Joten User-Agentit poistetaan Varysta.

WordPress asettaa aika usein cookien, vaikka sisältö ei riipu mitenkään käyttäjästä. Silloin Vary: Cookie aiheuttaisi sen, että cacheen vietäisiin jokaiselle käyttäjälle jokainen kerta aina uusi cache-versio. Mitään ei koskaan saataisi jaettua välimuistista. Siksi Cookie poistetaan niin Varystä kuin myös kokonaan silloin kun halutaan vaikka kuva välimuistiin.

Siksi Vary siivotaan ja muutetaan sellaiseksi, että siinä on vain ja ainoastaan sellaiset muuttujat, jotka aidosti vaikuttavat sisältöön

Joten jos vilkaiset selaimesi konsolista (F12 avaa sen) Network välilehdestä mitkä tämän jutun urlin headerit ovat, niin et näe niitä mitä backend on asettanut. Näet ne, jotka minä olen käskenyt Varnishin laittamaan.

vcl_deliver

Kun on saatu hoidettua cache-hommat, niin ollaan vaiheessa, että pyydetty juttu tai mitä sivuilta sitten on haettukaan, on valmis lähetettäväksi eteenpäin.

Jos aiemmin muutettiin ja lisättiin headereita sen mukaan mitä ja miten halutaan välimuistiin, niin nyt voidaan taas muuttaa headereita.

Nämä muutokset ovat sellaisia, jotka vaikuttavat selaimeen. Se mitä tehdään vaihtelee huomattavan paljon serverin tarpeesta ja mitä halutaan.

Minulla on työkalut säätää CORS asetuksia. CORS on turvamekanismi, joka säätää JavaScriptin suoritusta domainien välillä. Pystyisin muuttamaan Apachen asettamia, tai asettamaan ne, kun backendistä ei tietoa tule.

Kun kaikki sellainen on tehty, jota halutaan muokata, poistaa lisätä selaimen suuntaan, niin haettu sivu tai tieto palautuu Nginxin kautta vastauksena vierailijan selaimelle.

Oliko tuossa kaikki?

Ei ollut. Varnish-asetukseni tekee enemmänkin konepellin alla, mutta ne eivät oikein koske näkyvästi kävijää. Ne ovat joko vaikuttamassa cacheen, korjaamassa vikatilanteita tai suojelemassa serveriä. Kaikki kävijät kun eivät ole hyvillä aikeilla liikkeellä. Omat suojatoimenpiteeni ovat kevyitä ja helposti kierrettävissä. Ne eivät olekaan siellä niinkään luomassa turvallisuutta turvallisuuden takia, vaan pysäyttämässä roskaliikennettä kuormittamasta serveriä.

Jos sinua kiinnostaa käyttämäni Varnish-asennuksen toiminta, niin vilkaise GitHub repo. Siellä on myös muutama apuscripti, joita käytän WordPressissä cachen tyhjentämiseen.

Jos sinulla on kommentoitavaa tai kysyttävää, niin alla on linkki foorumille. Se toimii kommentointialustana tällekin jutulle, mutta toki siellä on paljon muutakin, yleisfoorumi kun on.