15 april 2011

Bij de Drupal GovDays in Brussel

event

Vorig weekend bezocht ik met veel enthousiasme de Drupal Government Days in Brussel. Het was bijzonder interessant om te kunnen praten met andere Drupal aanhangers, en te merken dat iedere developer die zich met Drupal bezighoudt, eigenlijk tegen dezelfde problemen aanloopt. Het was een eye opener, omdat er ruimte was om de standaard oplossingen voor standaard problemen te bespreken.

Een veel bediscussieerd onderwerp was dan ook de performance van Drupal, die sterk afneemt naar mate het aantal modules van een website groeit. Laat ik beginnen dit verder te illustreren.

Het is de hoogwaardige modulaire aanpak van Drupal die ervoor zorgt dat iedere module invloed kan uitoefenen op de uiteindelijke vorm en presentatie van content. Ook kunnen modules elkaar beinvloeden, en dit gebeurt dan ook vaak. Dit gegeven is heel prettig, en maakt Drupal tot een van de beste frameworks / content management systemen die er zijn. Er zijn namelijk (bijna) geen grenzen aan functionaliteit te stellen, omdat je te allen tijde de standaard gedragingen van een bepaalde module kunt overstemmen. Bovendien staat het iedereen vrij om zelf aan de gang te gaan met modules en de meest waanzinnige applicaties in elkaar te zetten.

Om deze modulaire aanpak tot een succes te brengen, is natuurlijk een hoop digitale logistiek nodig. Voordat een pagina er in zijn volledigheid staat, kletsen de hapklare Drupalblokken veelvuldig met elkaar, via de database. Het is bij Drupal helemaal niet gek als er duizend database queries voor nodig zijn om een simpele pagina te renderen. Als er dus honderd gebruikers tegelijk dezelfde pagina opvragen, kan het aantal transacties tussen Drupal en de database oplopen tot zo’n honderd duizend.
In andere systemen zou dit inderdaad met tien of minder queries kunnen, hetgeen de snelheid absoluut ten goede komt. Maar ja, deze systemen zijn niet zo flexibel in hun gedragingen als Drupal. En het zou natuurlijk te mooi voor woorden zijn om van beide werelden het beste te nemen: de modulaire aanpak van Drupal, en de snelheid van veel andere systemen? Fout gedacht.

Een razendsnelle Drupal website is met weinig inspanning te bereiken. Het sleutelwoord dat hierbij van toepassing is, is ‘caching’.
Door pagina’s op te slaan in het werkgeheugen nadat deze voor het eerst geladen worden, kan het oorverdovende gebabbel tussen modules en de database beperkt worden tot een paar zakelijke woorden, en kan de pagina vele malen sneller aan de eindgebruiker ontsloten worden. Er hoeven immers geen database queries meer uitgevoerd te worden, want het caching mechanisme weet de benodigde informatie al. Met andere woorden: de eerste keer duurt het opvragen van de pagina een tijdje, maar de tweede keer kan het binnen 1 miliseconde gepiept zijn.

Een voor de hand liggende vraag luidt: ‘wat moet er gedaan worden met dynamische content, die per gebruiker verschilt?’ Wat nou als er een blokje rechts in de pagina staat met de inhoud van een winkelmandje? Als we caching gebruiken, zien we de inhoud van het winkelwagentje van de eerste bezoeker, en niet van onszelf – dit kan natuurlijk niet de bedoeling zijn. Of een blokje met de allerlaatste reacties op blogs? Hoe verversen we deze content?
Er zijn verschillende manieren om hiermee om te gaan. In het geval van de ‘allerlaatste reacties’ zou je ervoor kunnen kiezen om de data elk kwartier op te schonen, en vervolgens alsnog te cachen. Zo zorg je ervoor dat in ieder geval elke vijftien minuten de juiste content wordt ingeladen. Het spreekt voorzich dat hetzelfde principe opgaat als je nieuwe content toevoegt, of bestaande content bewerkt. Verschoon de cache wanneer je dit doet, en er zouden geen problemen moeten optreden.

Bij het winkelwagentje gaat dit helaas niet op. Omdat het winkelwagentje per gebruiker anders is, kun je dit natuurlijk niet per kwartier opschonen en hetzelfde winkelwagentje tonen voor alle gebruikers. Hiervoor is een ander principe nodig: AJAX. Als je ervoor zorgt dat de gehele pagina uniform is voor elke gebruiker, kun je de pagina met gemak cachen. De gepersonaliseerde stukken kun je vervolgens inladen met AJAX. Nu zijn er voor deze pagina dus alleen transacties nodig met de database voor het kleine stukje gepersonaliseerde content, en niet voor de gehele pagina. Om deze oplossing te kunnen implementeren, moet er een module geschreven worden, en dat betekent: werk aan de winkel!
 

Geschreven door: Bas van der Heijden
Cookies?

We gebruiken cookies om het functioneren van onze website te verbeteren. De gegevens worden volledig anoniem verzameld.