Load testing in Drupal 8

14 mrt 2017

Joris Snoek - Project lead
Vragen? Let me know!
020 - 261 14 99

Voordat een Drupal website live gaat, is het belangrijk om te weten of hij niet down zal gaan wanneer de eerste bezoekers zich gaan melden. Voornamelijk bij een Drupal site die veel bezoekers verwacht, zul je vóór de livegang moeten load testen.

Bij load testen meet je de performance (prestatie) van een Drupal systeem aan de hand van de verwachte traffic.

Wat is Drupal performance

Simpel samengevat: hoe lang het duurt voordat één bezoeker een pagina te zien krijgt zodra hij deze opvraagt. Of wanneer hij resultaat ziet, na aanklikken van een bepaalde actie (Bijvoorbeeld: een status update plaatsen in een Drupal social intranet)

Schaalbaarheid in Drupal

Wanneer je gaat load testen, dan gaat het om schaalbaarheid. Als je meer gebruikers toevoegt, wat gebeurd dan? Dus je test bijvoorbeeld met 10, 100 of 1000 ingelogde bezoekers; blijft je Drupal systeem in de lucht?

Je kunt op twee manieren je servers opschalen: verticaal of horizontaal. Horizontaal is meer servers toevoegen, verticaal is ‘grotere’ servers toevoegen.

Load testen in Drupal

Je hebt allerlei scenario’s waar je rekening mee kunt houden bij load tests:

  • Hoe lang duurt het voordat je 100 gebruiker hebt
  • Hoe zwaar belasten deze bezoekers je systeem
  • Zijn deze in of uitgelogd
  • Hoe veel pagina's vragen ze op per minuut
  • Piek traffic

Maar uiteindelijk is het meest belangrijke: test je Drupal site zoals deze waarschijnlijk elke dag gebruikt zal worden door een specifiek aantal ingelogde en uitgelode bezoekers.

Stress testen

Bij load testen meet je met een specifiek aantal verwachte bezoekers, bij stress testen heb je geen idee hoeveel users er zijn. Je test tot hoever de server maximaal kan gaan. Dus niet het dagelijks gebruik, maar: wat kan de server aan voordat hij omvalt?

Zolang dit makkelijk boven je dagelijkse verwachte traffic blijft zit je veilig. De stress test kan goed zijn om toekomstige scenario’s enigszins in kaart te hebben. Voor het geval je website snel succesvol is, of wordt ‘ge-slashdot’.

Contention

Dit is wellicht het moeilijkste en meest belangrijkste bij load testen van een Drupal website.

Er zijn binnen Drupal momenten waarop alle andere request door Drupal on hold gezet worden, bijvoorbeeld bij het legen van caches. Na de eerste request door hiervoor, moeten alle andere requests on hold gezet worden, totdat de caches geleegd zijn. Hierin maakt het niet uit hoeveel servers er zijn.

Voor deze ‘contention issues’ moet je de code en de Drupal applicatie goed onder controle hebben. Zodat je exact weet wanneer deze bottlenecks op kunnen treden en hoe deze af te vangen.

Het testen van contention issues vangt tijdens het load testen de echte bottlenecks en uitzonderingen in Drupal af, een belangrijk onderdeel dus. Want hierin hangen alle requests van bezoekers af van slechts één resource (bv legen cache). De Drupal applicatie moet pauzeren totdat de actie is uitgevoerd en pas daarna zullen alle requests beantwoord worden, oftewel: bezoekers hun pagina’s te zien krijgen.

Probeer dus alle mogelijke contention issues in kaart te hebben en hierop goed te load testen.

Alle paden bewandelen

Test niet alleen de veelgebruikte pagina's, zoals de homepage van je Drupal cms. Het lijkt logisch dat je alleen de veelgebruikte pagina’s test, maar schijnt bedriegt. De duvel zit meestal in niet-voor-de-hand-liggende-pagina’s en tevens 'gebruikers-paden’. Dus de volgorde van pagina’s die gebruiker aanklikt.

Bijvoorbeeld: gebruikers deeplinken van een andere website naar jouw Drupal site, waardoor een bepaald cookie gezet wordt. Dit kan een uitzondering veroorzaken die een enorme performance impact kan hebben.

Test dus:

  • Met allerlei verschillende gebruikers, ingelogd en uitgelogd.
  • Zoveel mogelijk pagina’s
  • Verschillende soorten zoekopdrachten
  • Verschillende bezoekerspaden 
  • Verschillende manier om binnen te komen op de website

Traffic breakdown

Geschatte traffic voor een live Drupal website:

Alle scenario’s die je kunt verzinnen voor een normale bezoeker zorgen voor ongeveer 75% van alle traffic.

Dan zal ongeveer 15% veroorzaakt worden door bots van bijvoorbeeld Google en Yahoo en de laatste 10% is ruis.

Ruis wordt veroorzaakt doordat bezoekers niet bestaande of verlopen links opvragen. Of bv Wordpress / phphadmin / directadmin login pagina’s proberen te bezoeken. Ook aanvallen op je Drupal website vallen hier onder. De hoeveelheid ruis is moeilijk te voorspellen.

Belangrijk is rekening te houden met bots en ruis bij load testing. Bots gedragen zich anders dan echte, menselijke bezoekers. Het kan vóórkomen dat bots bepaalde pagina’s bezoeken die daarvoor niet bedoelt zijn. Als dit er te veel zijn, zou de site kunnen crashen door bots.

De ruis zal je ook moeten testen door een aantal niet-bestaande url’s en andere meuk op te nemen in je scripts.

Backend handelingen

Ook kan er vanuit het Drupal backend (administratie) vertraging op de website ontstaan. Test dus tevens zoveel mogelijk Drupal backend handelingen:

  • Wat gebeurd er als je Drupal nodes (artikelen) opslaat, worden er bijvoorbeeld dan caches geleegd? Of wordt er een externe service aangeroepen?
  • Wordt er gebruik gemaakt van workflow modules?
  • Wijzigen van content kan anders gedragen dan opslaan nieuwe content.

Deployment

Vergeet ook niet de verschillende scenario's te testen wanneer je een nieuwe versie van je Drupal website deployt (van test -naar liveserver overzetten). Kan dit alleen ’s nachts? Of wellicht gebeurt dit meerdere keren op een dag in een continuous integration keten? Meer issue waar je rekening mee kunt houden:

  • Wat gebeurt er bij een hotfix / bugfix: heeft die kleine wijziging impact bij staging?
  • Wat gebeurt er bij cron jobs en content syncs? Worden er externe web services aangeroepen?
  • Bij een nieuw theme zullen alle Drupal caches leeg moeten.

Allemaal belangrijke aandachtspunt bij load tests, zodat je voorbereid bent op toekomstige deployments.

Drupal 8 aandachtspunten

Headless Drupal

Headless Drupal: je gebruikt een frontend framework (bv AngularJS, een iOS of Android App) als frontend en zet Drupal in alleen als backend met een RESTfull API. Zie ook:

Headless Drupal. Waarom & hoe een RESTful API in Drupal?

De Drupal 8 core kent deze RESTfull web services en geven bijvoorbeeld JSON of XML terug; geen HTML/JS. Dus binnen browsers hoef je hier niet op te testen, maar je zult evengoed moeten load testen:

  • Je headless Drupal systeem wordt door bots bezocht, op een andere manier dan een standaard bezoeker.
  • Je headless Drupal wordt belast door het frontend framework.

Page caching

Page Caching staat standaard ingeschakeld in Drupal 8. Hierdoor kunnen issues ontstaan, die je over het hoofd ziet. Houdt daar dus rekening mee.

Cache tags

Drupal 8 kent ‘caching tags’. Bijvoorbeeld: een item op de homepage wijzigt, dan wil je dat alleen de homepage-cache geflusht wordt; niet alle andere Drupal caches. Middels cache tags kan je in juiste koppelingen voorzien:

  • Stale caches bestaan niet meer.
  • ‘Cache clear all’ zal niet meer nodig zijn.
  • Niet alle pages hoeven eenzelfde cache tijd te hebben.

Dit cache tag mechanisme was in Drupal 7, erg fijn dat het in Drupal 8 wel zit.

Service containers

Drupal 8 kent zogenaamde ‘service container’, voorbeelden hiervan zijn:

  • Meertaligheid
  • Menu structuur
  • Symfony componenten

Deze worden altijd direct weg geschreven en kunnen een contention issue geven, zie hierboven.

Niet extrapoleren

Wanneer je eenmaal je load tests gedaan met met bijvoorbeeld jMeter of Blazemeter dan zul je statistieken te zien krijgen. Extrapoleer deze grafieken niet: testen met 150 bezoekers betekent bijvoorbeeld niet dat de site bij 300 gebruiker dubbel zo traag zijn.

Final thoughts

  • Het is raadzaam om 50% boven je doel te testen, voor als je site succesvol blijkt.
  • Voer de load test altijd uit op exact eenzelfde server als live site.
  • Een ingeschakelde CDN kan statistieken boel vertroebelen, het is namelijk moeilijk te zien wat er écht aan request binnen komt.
  • Analyseer ook de uitzonderingen: piek momenten bijvooorbeeld

Nóg meer
kennis nodig?

Check ons ons blog archief.

Digitale strategie en realisatie

Bel ons op 020 - 261 14 99, mail op hallo@luciuswebsystems.nl, of stuur een bericht: