Veel bezoekers op uw site? Varnish!

Enkele maanden terug was de “cloud” de oplossing voor alles wat moest schalen. Vandaag de dag is die wolk ondertussen zowel doorprikt als voorbijgedreven, en ondertussen vraagt elke klant om zijn site te voorzien van “varnish”, zodat hij mega-hyper-snel wordt.

Hieronder een klein woordje uitleg, en de uitnodiging om onze techtalk “Varnish voor webbouwers” van woensdag 6 juli bij te wonen over dit onderwerp…

Varnish, wat is het?

Wanneer een bezoeker van uw site uw adres in de adresbalk intikt, worden de webpagina en alle bijhorende zaken (afbeeldingen, CSS, Javascript…) door een webserver (Apache, Nginx, Lighttpd) op je hostingserver ingelezen van de harde schijf, en wordt teruggestuurd naar de browser. Voor Ruby/PHP pagina’s komt er nog een verwerkingsstap bij, voor afbeeldingen is die er bijvoorbeeld niet.

Varnish is een reverse proxy, die tussen de webserver en de bezoeker geplaatst wordt, en die ervoor gaat zorgen dat twee identiek dezelfde vragen gedetecteerd worden. Meer nog, het is een HTTP cache, die gaat ongekende opvragingen doorsturen naar de webserver, en het antwoord intern bijhouden. Wanneer nogmaals deze aanvraag binnenkomt, moet dit niet langer gevraagd worden aan de achterliggende webserver maar kan het gewoon uit de cache teruggestuurd worden.

Aangezien er vandaag de dag flink wat rekenkracht komt kijken bij het opbouwen van een pagina (door bvb Drupal, Radiant, Wordpress, Fork, een eigen CMS, een framework, … ), is het interessant om enkel het hoogst-noodzakelijke te vragen aan de webserver en terug te vallen op de cache voor repetitieve aanvragen, zowel voor afbeeldingen als voor gegenereerde pagina’s.

Wat kan je cachen?

Je kan Varnish vragen om zowat alles te cachen, maar je moet er rekening mee houden dat je enkel zaken cachet die meermaals opgevraagd worden, en zaken die voor elke bezoeker gelijk zijn voor dezelfde aanvraag.

Wanneer we een logo op de hoofdpagina van een site nemen, is deze vermoedelijk gelijk voor eender welke bezoeker, onafhankelijk van het feit als hij ingelogd is of niet, of welke taal hij gekozen heeft, … Hetzelfde geldt voor flink wat afbeeldingen, javascript en CSS.

De dynamisch opgebouwde pagina’s zijn al wat moeilijker. Daar zit je met bepaalde parameters die de inhoud gaan bepalen, soms op dezelfde URL. Wanneer de taalkeuze bijgehouden wordt in een cookie, is de getoonde pagina niet gelijk voor elke bezoeker, terwijl ze wel dezelfde pagina gaan bezoeken.

De vraag van de browser en de server

Wanneer een browser een vraag stelt aan de webserver, wordt een “request” gestuurd, met een aantal headers erbij. Deze headers geven aan welke pagina gevraagd wordt, wat de aanvraag is (een GET of een POST bvb), en wat de extra informatie is die geweten is door de browser. Deze extra informatie bevat ook gekende cookies voor die pagina.

Varnish gaat standaard aan de hand van de combinatie van al die parameters opzoeken als deze pagina bestaat in zijn cache. Wanneer een gebruiker A de hoofdpagina van een site opvraagt met een eenvoudige GET, zonder cookies, en een gebruiker B doet hetzelfde, zijn dit voor Varnish gelijke aanvragen. Wanneer er bvb bij een tweede bezoek wel al een taalcookie gekend is, en gebruiker A heeft de waarde “Engels” en gebruiker B de waarde “Nederlands”, dan zijn die aanvragen niet gelijk. Wanneer gebruiker C echter ook met “engels” de site gaat bezoeken, is zijn aanvraag wel gelijk aan die van gebruiker A.

Een aanvraag is dus gelijk, zolang alle parameters gelijk zijn.

Het antwoord van de server naar de browser

Wanneer een server een pagina genereert, dient Varnish te beslissen als deze bijgehouden kan worden in de cache. Wanneer bij het antwoord een nieuwe cookie gezet werd, gaat Varnish beslissen dat dit niet bijgehouden kan worden. Ook wanneer de aanvraag een “POST” was (of een “DELETE”, "PUT", enz…) wordt het resultaat niet bijgehouden.

In de gegeneerde pagina zit normaal info over de geldigheid en de duur van de caching. Iedereen zal wel bekend zijn met het antieke “pragma: no-cache”, of de modernere “Cache-Control: no-cache, must-revalidate” headers die gezet kunnen worden. Voor afbeeldingen zijn er gekende “expires”-headers die gezet kunnen worden om de browser te informeren hoelang de afbeelding bijgehouden mag worden.

Soms worden nieuwe cookie-inhouden teruggestuurd naar de browser.

Een antwoord bepaalt hoelang de inhoud van het antwoord geldig is, en hoelang het door een browser bijgehouden mag worden.

Correcte caching

In een ideale wereld is caching eenvoudig. Elke aanvraag bevat enkele aanvraag-parameters (de headers), en elk antwoord die teruggestuurd wordt naar de browser, bevat ook informatie. Er zijn cache-headers, expire-headers, max-age-headers, … Een heleboel informatie om je op te baseren wat gecached kan worden, en wat niet. Echter gaat dit niet altijd zomaar op. Er zijn enkele zaken die zeer eenvoudig roet in het eten strooien, waardoor een standaard Varnish installatie niet zoveel gaat bijdragen. Enkele voorbeelden kan je hieronder vinden:

Anonieme bezoekers en sessie-cookies.

Veel frameworks en sites gaan altijd en overal een sessie starten voor een gebruiker. De sessie wordt klassiek opgeslagen in een cookie, en bij elke aanvraag van de bezoekers wordt het cookie meegestuurd. Varnish gaat elk van deze aanvragen als uniek aanzien ten opzichte van een andere gebruiker, aangezien deze andere gebruiker een andere sessie-cookie heeft.

De oplossing hier ligt erin om niet nodeloos cookies voor sessies te gaan zetten. Wanneer je voor anonieme (niet ingelogde) gebruikers toch bepaalde data wenst bij te houden, maak dan een expliciete cookie (bvb, een cookie “lang=en” of “lang=nl”), zodat twee bezoekers met dezelfde waarde, dezelfde pagina te zien krijgen.

Afbeeldingen

Afbeeldingen worden ingeladen vanaf hetzelfde domein, en de cookies die op het domein gezet zijn, worden meegestuurd met de aanvraag voor de afbeelding. Je krijgt dus meerdere versies van verschillende gelijke afbeeldingen: een “lang=en” logo of achtergrond, en een “lang=nl” logo of achtergrond, terwijl die eigenlijk gelijk zijn. De oplossing hier bestaat erin om Varnish zo te gaan configureren dat de binnenkomende cookies genegeerd worden waar dit mag, zodat de content eenvoudiger “gelijk” wordt voor Varnish.

Invalidatie

Wat met een aanpassing op je site? Varnish moet hiervan op de hoogte gesteld worden. Een klassiek voorbeeld is het schrijven van een nieuw artikel in je CMS, en het dan publiceren… Er zijn gelukkig methoden in Varnish ingebouwd om vanuit een CMS een signaal te sturen naar Varnish waarbij je aangeeft welke URL “vergeten” moet worden, zodat deze bij de volgende hit terug aan de server opgevraagd wordt.

En helpt dit nu zoveel?

Ja, eigenlijk wel. Wanneer een site veel bezoekers mag ontvangen, en deze komen allemaal dezelfde inhoud bekijken, kan het zeker lonen. Het meeste effect heb je natuurlijk wanneer de dynamisch gegeneerde pagina’s ook gecached kunnen worden.

In extreme gevallen hebben we gezien dat sites waar normaal maar enkele hits per seconde verwerkt kunnen worden, er mits het goede gebruik van Varnish en correcte instellingen, door dezelfde opstelling enkele 1000-den parallelle requests verwerkt kunnen worden.

Er is natuurlijk een grote maar. Als de inhoud van de pagina’s voor elke bezoeker aangepast moet worden (denk bvb aan een sociale netwerksite waar je altijd je eigen vrienden, info en andere zaken in je eigen volgorde ziet) kan je niet zoveel gaan cachen. Gelukkig zijn daar specifieke oplossingen voor, maar die zijn iets te lang om in een blogpost uit te leggen.

En wat met Varnish 3?

De makers van Varnish hebben een nieuwe versie van Varnish aangekondigd, en deze zou deze week normaal gereleased worden. Op zich is dit voor webbouwers weinig belangrijk, het zijn vooral de systeembeheerders die hier hun hart gaan ophalen. Het principe blijft echter hetzelfde voor de webbouwer.

Meer info hierover?

Er komt nog een tweede blogpost rond Varnish met enkele zeer duidelijke use-cases uitgewerkt.

We richten ook een techtalk in over Varnish, toegespitst op webbouwers, waarbij we de do’s en don’t gaan uitleggen, samen met enkele praktijkvoorbeelden.

Deze gaat door in het kantoor van Openminds, op woensdag 6 juli om 17u30 (techtalk start om 18u). Deze sessie is ondertussen uitverkocht. Indien je op de reservelijst wenst te komen mag je altijd e-mailen naar sales@openminds.be

Meer info over Varnish kan je vinden in Wikipedia en op hun eigen site . Openminds kan u natuurlijk bijstaan in een correcte configuratie en versnelling van uw site.