Tijdens de ontwikkelingsfase werkt de site erg snel, maar zodra ze in productie gaat en blootgesteld wordt aan het grote publiek, gaat het fout. Dit is de trieste realiteit waar wij als hoster haast dagelijks mee geconfronteerd worden.

Trage sites

Helaas wordt ook vandaag nog door heel wat developers nog steeds niet genoeg aandacht besteed aan performantie en schaalbaarheid. Toch wordt er in de internet industrie, maar ook in de verschillende gespecialiseerde developer communities al een tijdje het verhaal gepredikt dat schaalbaarheid start bij het uitteken van de architectuur van een applicatie of een site.

Ook de verschillende frameworks waarmee sites gebouwd worden, zijn steeds meer voorzien van de nodige tools om de site sneller te doen gaan.

Het is ook niet altijd nalatigheid of onkunde die oorzaak is van een trage site. In sommige gevallen is het een mix van omstandigheden:

  • Meer bezoekers dan oorspronkelijk ingeschat
  • Een grotere dichtheid van het bezoekersaantal
  • Te weinig serverkracht
  • Slechte tuning van de software
  • Slecht database design en slechte indexatie
  • Het gebruik van logge of instabiele 3rd party componenten.

Ingrijpen

Tijdens de ontwikkelingsfase is het natuurlijk altijd moeilijk om een realistische stresstest uit te voeren en daarom is het vaak pas wanneer er in productie veel bezoekers langskomen, dat de pijnpunten duidelijk worden.

In zo'n situaties is het vaak te laat en dienen wij als hoster in te grijpen. Een van de mogelijkheden is om meer servers in te zetten. Dit zou een erg lucratieve strategie voor ons kunnen zijn, maar wij opteren meestal voor een meer pragmatische aanpak: niet alle applicaties kunnen efficiënt op meerdere servers draaien en vaak kunnen performantieproblemen aangepakt worden door een goede caching laag toe te passen.

Caching

Caching is een techniek waarbij dynamische data (data die berekend worden), statisch bijgehouden worden, met een verhoogde performantie als doel.

Bij het gebruik van caching moeten helaas ook compromissen gesloten worden: dynamische data worden statisch en bijgevolg bestaat het risico dat er door caching oude data getoond worden. Door een doordachte expiratie of invalidatie strategie te hanteren, kan ervoor gezorgd worden dat nieuwe gegevens tijdig hun weg vinden naar de site.

De meeste vormen van caching moeten helaas ingebouwd worden in de programmering van de site en zijn bijgevolg architecturale beslissingen. Wanneer er geen correcte caching laag voorzien is, vormt dit een probleem.

Reverse proxy

Gelukkig bestaat er zoiets als een reverse proxy. We kennen nog de proxy servers van de tijd toen internetverbindingen nog traag waren: de proxy server zorgde ervoor dat de inhoud van reeds bezochte sites bijgehouden werd zodat die niet altijd opnieuw opgehaald moest worden op dat trage internet.

Internetverbindingen zijn veel sneller dan vroeger en een reverse proxy doet zoals de naam aangeeft net het omgekeerde: de server staat niet aan de kant van de gebruiker, maar in het datacenter. Een reverse proxy beschermt servers tegen een onverwacht grote hoeveelheid bezoekers.

Hoe doet een reverse proxy dit? Door (analoog met een gewone proxy) resultaten van de servers te cachen en in een statische vorm aan bezoekers aan te leveren. Op die manier moet een verzoek niet telkens naar de backend servers en worden sites als sneller ervaren.

Varnish is zo'n type reverse proxy.

Varnish

Varnish is een open source reverse proxy software, ontwikkeld door het Noorse LinPro. Wat begon als een project om een Noorse nieuwssite sneller te doen werken, is uitgegroeid tot een project dat nu als "industry standard" geldt.

Varnish kan makkelijk op een Linux server geïnstalleerd worden en wordt voor de effectieve webserver of webservers gezet. Door de DNS-records van de site (vb. www.domeinnaam.be) te linken aan Varnish, beschermt deze uw backend servers tegen een te hoge load.

Varnish spreekt HTTP

Doordat Varnish als proxy de brug slaat tussen de browser en de server, is het logisch dat Varnish HTTP spreekt. Dit is het protocol dat per conventie gebruikt wordt voor webverkeer op het internet.

HTTP voorziet in zijn specificatie een caching mechanisme dat in de volksmond vaak "browser cache" genoemd wordt.  Net zoals proxy servers, werd browser cache vroeger gebruikt als compensatie voor trage internetverbindingen. Nu wordt caching HTTP ook gebruikt om het gedrag van reverse proxy's te manipuleren. Dit gedrag staat duidelijk beschreven in hoofdstuk 14.9 van de HTTP specificatie.

Liefst willen we zo agressief mogelijk cachen, maar natuurlijk mag niet alles gecached worden.  Wanneer cachet Varnish niet:

  • Wanneer er cookies aanwezig zijn (duidt op "user specific" content).
  • Wanneer de time to live van de cache control headers kleiner of gelijk aan nul zijn.
  • Wanneer het verzoek van de bezoeker geen GET request is (een POST, PUT of DELETE dus).
  • Wanneer de backend om authenticatie van de gebruiker vraagt.

Alles wat niet voldoet aan bovenstaande criteria zal door Varnish gecachet worden. De geldigheid/duurtijd van de cache voor een pagina wordt bepaald door de time to live van de cache control header. Staat deze op 3600 seconden, dan wordt de pagina een uur gecachet.

Varnish Configuration Language

In de vorige paragraaf werd beschreven wat het standaard gedrag is van Varnish en wat er wel en niet gecachet kan worden.

Vaak zijn deze scenario's niet wenselijk voor bestaande software die soms zondigt tegen deze regels. Gelukkig is Varnish voorzien van een geïntegreerde programmeertaal waarmee het gedrag van Varnish op maat aangepast kan worden.

Aan de hand van de Varnish Configuration Language (VCL) kan men inhaken in de verschillende onderdelen van de Varnish cache en kan waar nodig bepaald worden wat er wel of niet gecachet moet worden onder welke omstandigheden.

Enkele courante acties die via de VCL uitgevoerd kunnen worden zijn onder andere:

  • Het wegnemen van bepaalde cookies waar die niet nodig zijn zodat bepaalde pagina's of andere documenten toch gecachet kunnen worden.
  • Het expliciet (niet) cachen van bepaalde URL's.
  • Het bepalen hoe lang specifieke pagina's gecachet mogen worden
  • Het uitwerken van een invalidatiemechanisme waarbij pagina's uit de cache gegooid worden, zelfs als is de time to live niet verstreken
  • Het herschrijven van HTTP headers.
  • Het verwerken van bepaalde cookie data in de caching identificatiesleutel.
  • Het loadbalancen van verzoeken naar specifieke backendeservers
  • Vastleggen hoe Varnish moet reageren wanneer de backendservers toch down zouden zijn of niet tijdig reageren.
  • ...

Elke site is verschillend en vereist een aparte VCL configuratie. Het is belangrijk dat de ontwikkelaar van de site de verschillende URL's in kaart kan brengen en kan zeggen welke cookies er op welke plaats gebruikt worden. Op basis daarvan kan de meest geschikte Varnish configuratie opgebouwd worden.

Snelheid

Varnish is snel, verdomd snel. Het is een tool die weinig kan, weinig moet kunnen en daarom zo efficiënt is. Van overhead is er haast geen sprake en alle cache items worden standaard in het RAM geheugen bijgehouden.

Enkele doelgerichte tests die wij uitgevoerd hebben toonden aan dat trage setups tot 500 maal sneller kunnen werken dankzij Varnish. Deze cijfers vertellen niet het volledige verhaal. De netto performantiewinst hangt vaak af van hoe traag de setup initieel is, hoeveel verschillende URL's er gecachet moeten worden en wat het surfgedrag is van de bezoekers.

Vast staat dat de meeste grote spelers op het web gebruik maken van deze technologie. In 2009 al werd een case study gemaakt over hoe NU.nl (de grootste traffic site in Nederland) mede dankzij het gebruik van Varnish tot 21 miljoen bezoekers op een dag kon verzetten.

Varnish bij Combell

Bij Combell gebruiken we nu ook al enkele jaren Varnish en het vormt de hoeksteen van heel wat setups. Meestal gebruiken we Varnish als joker wanneer een bestaande site slecht presteert, maar vaak voorzien we Varnish bij het uittekenen van het initiële plan.

Sommige van onze klanten hebben hun bestaande software in die mate getuned dat ze met Varnish een grotere groei op bestaande hardware kunnen voorzien.

Andere klanten gebruiken dan weer Varnish als goedkoop en evenwaardig alternatief voor hun dure Content Delivery Network (CDN) oplossingen. Deze klanten maken vooral gebruik van caching en in mindere mate van geografische distributie van de caches.

Het is duidelijk dat Varnish bij ons hoog aangeschreven staat. We investeren daarom voldoende in kennis over deze technologie. Verschillende mensen van ons team zullen zelfs aanwezig zijn op de Varnish User Group Meeting in London.

We proberen ook zoveel mogelijk kennis te delen via presentaties. Onze evangelist Thijs Feryn geeft wereldwijd presentaties over Varnish, performance en schaalbaarheid in het algemeen. Op dit Vimeo filmpje ziet u een presentatie die Thijs in  2011 in London gaf.

-- --
Vond je dit artikel waardevol? Deel het dan hieronder via Twitter, Facebook of Linkedin.

Volg je @bloovi al op Twitter? #bloovi