Problemen oplossen in Varnish

In de eerste Chalk Talk video’s over Varnish legden we uit wat Varnish ishoe het werkt en hoe je content kan optimaliseren voor Varnish. In deze laatste video uit de reeks bekijken we “ Problemen oplossen in Varnish ”. Hoe weet je of een pagina juist gecached wordt of niet? Wat zijn de meest voorkomende problemen na een implementatie van Varnish? En hoe los je die problemen op? (tip: je kan onderaan eenvoudig Nederlandstalige of Engelstalige ondertitels aanzetten)

<iframe width=”560″ height=”315″ src=”https://www.youtube.com/embed/B03Sv21z68E” frameborder=”0″ allow=”autoplay; encrypted-media” allowfullscreen></iframe>

De uitgeschreven tekst van deze Chalk Talk “Problemen oplossen in Varnish”

Welkom bij Chalk Talk, een reeks video’s waarin we complexe technologieën uitleggen met slechts één krijtbord. In deze laatste video bekijken we veelgemaakte fouten die gemaakt worden tijdens het implementeren van Varnish. Je zult merken dat ons bord erg lijkt op dat van de vorige keer. Dit is namelijk het deel waar we merken dat de meeste fouten worden gemaakt.

Session ID’s

Dit is de hashing-engine, het deel waar Varnish kijkt naar de invoer versus de uitvoer van de hash. Als de invoer hetzelfde is zal de hash hetzelfde zijn en kan de gecachte pagina verstuurd worden. Als je kijkt naar de input kom je eerst en vooral uit bij cookies. En die cookies zijn de grootste fout of het nummer 1 probleem dat we in Varnish zien.

Sessie-ID’s bijvoorbeeld. Niet alleen beperkt tot PHP overigens: hetzelfde gebeurt in Ruby, Perl, etc. waar frameworks vaak, uit gemakzucht, automatisch een sessie initialiseren. Een sessie is een willekeurige cookie om elke bezoeker op een unieke manier te identificeren. Maar een unieke sessie betekent ook een unieke invoer voor de hash en een unieke hash als resultaat.

Dus door het makkelijker te willen maken krijg je willekeurige pagina’s of willekeurige cookies die voor willekeurige hashes zorgen en zo vernietig je je cache volledig. Mijn hash verschilt van die van mijn collega en van die van jou.

Lazy session initialisation

Om dit te verhelpen, in het geval van sessies, kies je voor lazy session initialisation. Je initialiseert geen sessie voor elke pageload, je initialiseert gewoon wanneer je die specifieke sessie nodig hebt. Bij een webshop, kan je die toevoegen wanneer iemand iets in zijn mandje stopt of naar je betalingspagina gaat. Voeg het niet toe voor browsercategorieën of willekeurige pagina’s, omdat het daar niet echt waarde toevoegt.

Bovendien zien we voortdurend willekeurige gegevens in cookies. Als ontwikkelaar is het erg handig om data toe te voegen aan een cookie om later te kunnen gebruiken. Dat wordt ingesteld aan de client kant en voor elke nieuwe aanvraag wordt die info teruggestuurd naar de server. Dat betekent dat het gebruikt wordt als input om de hash van de pagina te bepalen. Gewoon een cookie toevoegen of het wijzigen van de data van een cookie zal de hash veranderen.

Gewoon een cookie toevoegen kan je cache drie of vier keer groter maken, omdat er meerdere permutaties zijn of meerdere versies van die pagina bestaan. Dus houd je cookies zo proper mogelijk en initialiseer alleen sessies als je ze nodig hebt en je zult de meeste problemen vermijden die wij tegenkomen met cookies.

URL-parameters

Daarnaast zijn URL-parameters soms wel eens moeilijk te herstellen. Opgelet daarmee dus. Willekeurige URL-parameters toevoegen kan nuttig zijn als ontwikkelaar als je iets wilt tracken aan de client kant met Google Analytics.

Maar elke wijziging in de URL creëert een andere pagina. Dus gewoon een tracking-ID toevoegen voor verschillende bezoekers na een nieuwsbrief zal elk van die nieuwsbrieven en hun kliks uniek maken voor Varnish. En dat zal je caching vernietigen. Onthoud dit en 9 van de 10 keer heb je geen probleem om Varnish te implementeren.

Problemen oplossen in Varnish

Hoe zie je welke input jij doet, wat eruit komt en of je caching werkt? Als je naar het eindresultaat kijkt: er komt iets in de cache en wordt teruggestuurd naar je client. Dat eindresultaat bevat cookies of toegevoegde headers. Als je naar je browser gaat en rechtsklikt op de pagina, het maakt niet uit waar, en dan “element inspecteren” en je kiest de tab “netwerk” aan de onderkant kan je de headers bekijken die worden teruggestuurd bij elk onderdeel of elk stuk content. Je kan naar de headers kijken van de hoofdpagina. Je kan ook naar de headers kijken van je CSS, Javascript, foto’s, enz. Elk van die zal waarschijnlijk een header hebben die cache-controle heet.

Cache-controle

Cache-controle bepaalt voor Varnish of iets gecached kan worden of niet. Als de cache control zegt:”deze pagina is privé”, zal Varnish dit verstaan als “dit is een unieke pagina en ik kan en zal die nooit kunnen cachen”. Als de cache control header zegt: “dit is een publieke pagina” kan hij ook optioneel vermelden hoe lang Varnish dit mag cachen. Technisch geeft dit aan hoe lang de client, de browser, dit mag cachen. Maar Varnish luistert ook naar deze header. In dit geval vertelt de header aan Varnish “je mag deze pagina cachen voor een uur.” 3600 seconden.

Age & X-Cache Header

Hoe weet je of iets effectief in de cache zit? Dan komen de age en X-cache header van pas. Bij een age header, weet je dat de specifieke pagina die je krijgt, in dit geval al bestaat voor 256 seconden binnen Varnish. Dus de pagina is niet “nieuw”, maar zit al een paar minuten in de cache. En de X-cache header, die kan worden toegevoegd kan het duidelijker maken. Was dit een cache-hit of een cache-misser?

Bovendien zal je merken dat als je een pagina terugkrijgt in 15 ms het allicht een pagina is uit de cache. Als het een paar seconden duurde zal het zeker geen pagina uit de cache zijn. Je kunt dus naar de resource headers kijken of de headers op elke pagina om te zien of een pagina gecached is. En voor hoe lang. Anders bekijk je de cache control headers of kijk je welke cookies worden teruggestuurd vanuit de applicatie om te bepalen wat de reden zou kunnen zijn. Want, vergeet niet, elke cookie die je instelt wordt bewaard aan de client kant, gebruikt binnen de hash om die hash zelf te bepalen. Daarom zal elke cookie deze hele motor opnieuw activeren en je caching-ervaring zal vernietigen.

Samengevat: houd rekening met de cookies, de header of de URL’s. Kijk naar de headers in de response of en wanneer een bepaalde pagina is opgeslagen. Dat is het voor onze Varnish-serie. Tot de volgende keer.

Wil je nog meer weten, kan je ons Varnish eBook downloaden.

Gerelateerde berichten
hoe voorkom je dat je gehackt wordt

Voorkomen is beter dan genezen: hoe voorkom je dat je gehackt wordt?

Breng alle cyberrisico’s op technisch en juridisch vlak in kaart en neem de passende technische en organisatorische maatregelen. Een overzicht.

Lees meer

communicatie bij een hack

Hoe moet je communiceren als je gehackt bent?

Hoe ga je als bedrijf, groot of klein, met veel of weinig gegevens, best om met de communicatie omtrent een hack en (eventueel) datalek?

Lees meer

welke juridische stappen na hack

Welke juridische maatregelen moet je nemen na een datalek?

In dit artikel willen we zo concreet mogelijk maken welke juridische stappen je moet ondernemen als je bedrijf geconfronteerd wordt met een datalek.

Lees meer