Hoe varnish jouw site sneller maakt

Wat is caching?

Vrij vertaald is cache een opslagplaats. Bij websites wordt cache gebruikt om handelingen die veel tijd kosten, niet telkens te herhalen. De eerste keer dat een handeling (b.v. een menu opbouwen) gevraagd wordt, wordt het resultaat van de handeling deze in de cache geplaatst. De volgende keren wordt die handeling niet meer gedaan, maar wordt het resultaat van de handeling uit de cache rechtstreeks aan de bezoeker geserveerd.

Hoe en wat kunnen we cachen?

Op verschillende plaatsen:

query cache
key/value cache
reverse proxy

Query cache (database)

In alle databases zit query cache ingebouwd. Dit zorgt ervoor dat de resultaten van een SQL-query die vaak voorkomt uit het geheugen geserveerd kan worden. Hiervoor is het belangrijk regelmatig je database-server te tunen. Ook kan het helpen om je query’s zodanig te schrijven dat er maximaal gecached kan worden door de database-server.

Query cache is echter geen wondermiddel, de database-server heeft moeite om te weten welke query’s goede kandidaten zijn om te cachen en hoe lang deze in de cache mogen blijven.

Key/value cache (PHP)

We kunnen ook proberen te voorkomen dat de database aangesproken moet worden. Met een key/value cache zoals Memcache of Redis, kan de programmeur zelf beslissen welke objecten gecached kunnen worden en hoelang.

Neem bijvoorbeeld een website met een grote navigatiestructuur. Deze wordt meestal in een boomstructuur in de database opgeslagen. Dit betekent dat er meestal meerdere SQL-query’s nodig zijn om de volledige structuur op te halen. Ook al worden die wel geserveerd uit de query cache, het blijven meerdere database-benaderingen.

Via de key/value cache kan het resultaat van die verschillende SQL-queries in het RAM-geheugen van de server worden opgeslagen, en dit voor verschillende uren, of zelfs totdat er een wijziging aan de structuur van de site wordt gemaakt!

Full page caching

Dit type caching gaat nog verder. In plaats van stukken van de site in het geheugen te steken, wordt de volledige HTML-code opgeslagen in het geheugen. Immers, dezelfde site wordt heel vaak geserveerd aan honderden of duizenden gebruikers.

Er zijn verschillende manieren om aan full page caching te doen. In Drupal is deze mogelijkheid ingebouwd. Wordpress heeft plugins die dit voor jou kunnen doen.

Een nog betere manier is om de bezoekers op te vangen voor ze aan je webserver geraken. Dit kan door een reverse proxy, waarvan Varnish met voorsprong de meest bekende is. In dit artikel leggen we uit wat Varnish is, waarom het voor jou van belang is en waar je zeker op moet letten.

Hoe werkt Varnish?

Dit is een voorstelling van hoe een standaard website nu in elkaar zit.

Dus de bezoeker gaat over het internet naar de web server. Op de webserver staat jouw website die uitgevoerd zal worden. Daarvoor gaat de website meestal gebruik maken van een database.

De tijd die verstrijkt tussen de vraag van de gebruiker en het tonen van een volledige pagina aan de gebruiker, varieert tussen de 100ms en de 2s, ten minste als de site goed in elkaar zit en de server niet overbelast is. Gemiddeld zitten we aan 250-500ms.

Nu met Varnish. We zetten Varnish tussen de gebruiker en de website.

Wat denk je nu? Of hoe kan een extra stap nu sneller zijn, de weg die een aanvraag aflegt is immers langer en dus trager?

Neen, dat is het mooie van de zaak. Als de aanvraag binnen komt bij Varnish zal Varnish in kijken of de gevraagde pagina misschien in zijn geheugen aanwezig is. En dat gaat supersnel: pagina’s die Varnish uit zijn geheugen kan serveren, zijn bij de bezoeker in minder dan 50ms!

Super. Dus met Varnish is mijn site supersnel?

Ja en nee. Zo eenvoudig is het niet, Varnish implementeren kost een inspanning van de programmeur en de serverbeheerder.

Laten we het even over de struikelblokken hebben die je kan tegenkomen en hoe we dit kunnen oplossen.

Voor we beginnen moeten we het over enkele begrippen hebben:

Een HIT is als Varnish iets uit zijn geheugen heeft kunnen serveren. Een MISS betekent dat Varnish de pagina aan de webserver heeft moeten vragen.
De HIT-ratio is het aantal pagina’s die Varnish uit zijn geheugen heeft kunnen serveren.

Er wordt niets gecached

In de standaardconfiguratie is Varnish conservatief. Dat betekent dat we er alles aan doen om ervoor te zorgen dat de site naar behoren functioneert, mogelijk ten koste van de HIT-ratio.

Dit is helemaal niet erg, we moeten gewoon wat finetunen. Mogelijke oorzaken van niet cachen:

cookies, bijvoorbeeld met een gebruikersnaam of tracking cookie
variabelen in de url (b.v. in een lange querystring)
onnodige session-id’s

In de meeste gevallen moeten we enkele wijzigingen in de configuratie doorvoeren om deze stap te overwinnen. Dit moet uiteraard oordeelkundig gebeuren.

Er wordt te lang gecached

Nu we Varnish zover hebben dat hij pagina’s uit zijn geheugen gaat serveren, is het de vraag hoe lang we deze pagina uit het geheugen mogen serveren.

We kunnen aan Varnish vertellen dat hij pagina’s gedurende 1 uur mag bijhouden. Na dat uur moet hij de pagina aan de webserver vragen om te kijken of er een nieuwe versie van is.

Een voorbeeldje. Om 13:00 bezoekt Jan onze website. De pagina zit niet in het geheugen van Varnish, dus wordt opgevraagd op de webserver. Dit noemen we een Fetch. De pagina wordt teruggegeven aan de gebruiker en wordt in het geheugen van Varnish opgeslagen:

Neem nu dat webmaster Sarah om 13:30 de pagina wijzigt. Dus in de webserver zit een nieuwe versie van de pagina (v2), maar Varnish weet nog van niets. Wat gebeurt er dan als een andere bezoeker Piet de website bezoekt:

Dat is minder leuk. Piet krijgt de versie te zien die Varnish om 13:00 voor Jan heeft opgehaald, en niet de supercoole aangepaste versie 2 van Sarah.

Nu kan Piet wachten tot het 14:00 is. Of Sarah kan aan haar programmeur vragen om de PURGE-module te installeren :)

Alle moderne CMS’en hebben purge-modules waarbij de website bij een wijziging van de inhoud aan Varnish zal vertellen om die specifieke pagina onmiddellijk uit zijn geheugen te verwijderen.

Dus op het moment dat Sarah haar aanpassing doet, gaat de website een Purge-request sturen naar Varnish, die de verouderde versie uit zijn geheugen verwijdert:

Als Piet daarna om 13:45 naar de site komt, krijgt hij versie 2 wel te zien.

Akkoord, het is niet eenvoudig om dit te implementeren. En we zien erg vaak dat deze stap gewoon overgeslagen wordt. Een ramp is dit niet, weinig sites worden zo vaak aangepast dat de standaard-instelling van 1h bijhouden best wel ok is.

‘t Is iets dat je voor jezelf moet uitmaken. Wij zijn alvast bereid om samen met jou die extra stap te zetten richting een perfecte configuratie.

Er wordt teveel gecached / mijn website werkt niet meer

Soms zijn we te enthousiast en cachen we te veel. Dan krijg je situaties waarbij verschillende bezoekers elkaars pagina te zien krijgen, of verkeerde info getoond wordt.

Daarom is het belangrijk om bij het instellen van Varnish een goede samenwerking tussen programmeur en systeembeheerder te hebben. Zo weten we samen perfect welke cookies en instellingen mogen gecached worden en welke niet.

Ik heb een webshop

Bij webshops of dynamische sites zitten meestal gepersonaliseerde blokken. Zie bijvoorbeeld:

Rechtsboven is plaats voorzien voor je naam als je aangemeld bent en hoeveel items er in je mandje liggen.

Deze pagina mag niet in zijn geheel in Varnish gestoken worden - want dan krijgt iedereen bovenaan te zien dat hij ‘Peter’ heet en net 1 iPhone in zijn mandje gegooid heeft.

Dus webshops zijn iets complexer. We kunnen beslissen om deze pagina’s niet te cachen. Maar dat zijn dan alle pagina’s, want die gepersonaliseerde info staat in de header… Dus kan er dan niets in Varnish gestoken worden, dan hebben we daar niets aan?

Toch wel - er zijn enkele opties die we kunnen toepassen!

Meestal maken we gebruik van ESI (Edge Side Includes). Hierbij gaan we de volledige pagina maken, maar zonder het blokje dat gepersonaliseerd moet worden. Die pagina kan gecached worden door Varnish zonder problemen. Het aparte blokje wordt daarna door Varnish rechtstreeks bij de webserver gehaald, voor elke gebruiker apart.

Een alternatief is Ajax calls te doen voor dit blokje, zo kan de volledige pagina nog steeds (als HIT) door Varnish geserveerd worden.