Nieuws

10 min leestijd
Running load tests met Jmeter via BlazeMeter

Een van de belangrijkste dingen om te weten tijdens het lanceren van webapplicaties is onder welke hoeveelheid " load " deze zal crashen. Elke server heeft zijn grenzen. Niet weten wat die grenzen zijn, kan veel schade toebrengen aan het imago van uw bedrijf.

Voordat u een nieuwe versie van uw project start, is het aanbevolen om enkele "load tests" op de applicatie uit te voeren. De resultaten van deze tests vertellen u hoeveel gelijktijdige bezoekers uw applicatie kan verwerken in de huidige infrastructuur en welke server resource het meest waarschijnlijk het eerst zal crashen.

Door te weten hoeveel gelijktijdige gebruikers uw applicatie aankan, kunt u de configuratie van de servers wijzigen om ervoor te zorgen dat de infrastructuur het vooraf gedefinieerde aantal bezoekers aankan. U kunt waarschuwingen aan specifieke drempels toevoegen, zodat u de tijd hebt om op te schalen wanneer uw toepassing extra resources nodig heeft. Door u bewust te zijn van de grenzen van uw toepassing, kunt u zich aanpassen aan een toename van het verkeer.

HOE KAN IK LOAD TESTS MAKEN?

Het eerste wat u moet doen voordat u load tests schrijft, is testscenario's specificeren. Een belangrijk onderdeel van het bepalen van deze scenario's is het kennen van het gedrag van de bezoeker op de website. Voor nieuwe sites kan dit een berekende schatting zijn. Voor bestaande websites kunt u deze informatie opvragen via tools zoals Google Analytics.

Bijvoorbeeld: als je een gemiddelde webshop aanmaakt, kun je je verkeer opsplitsen in de volgende scenario's:

  • 20% Homepage
  • 20% Landingpagina bezoekers
  • 20% Catalogus / productpagina bezoekers
  • 20% Zoeken bezoekers
  • 20% Bestellen bezoekers

Tijdens het uitvoeren van de load tests wordt het verkeer over deze scenario's verspreid. Dit geeft u een echte spreiding van de load op de toepassing.

Nadat u de bovenstaande scenario's hebt gespecificeerd, is het tijd om de belastingstests te schrijven. Onze voorkeur gaat uit naar JMeter. De tool slaat zijn configuratie op in een XML-formaat. Gelukkig is er ook een GUI aanwezig waarmee het configureren van de testsuites eenvoudig is. Je kunt je JMeter voorstellen als een curl workflow tool op steroïden. Het JMeter-project bestaat uit de volgende hoofdelementen:

  • Testplan: Bevat door de gebruiker gedefinieerde variabelen zoals omgeving, pad, ...
  • Thread groups: Is vergelijkbaar met een test suite
  • Elementen configureren: U kunt tools toevoegen die cookie managers, browser cache, ... gaan simuleren
  • Controllers: Een controller bestaat uit samplers en kan logica bevatten zoals if, while, ...
  • Sampler: Deze voert de HTTP requests uit.
  • Pre-processor: Voert geavanceerde zaken uit, zoals het herschrijven van URL's, voordat u het verzoek verzendt.
  • Post-processor: Verzamelt gegevens van een antwoord. U kunt bijvoorbeeld JSON analyseren of form values ophalen op basis van het pad van het CSS selector patch.
  • Beweringen: Wordt gevalideerd als een antwoord de waarde bevat die het beschikbaar verwacht te hebben.
  • Listeners: Listeners worden meestal gebruikt om rapporten en grafieken weer te geven.
  • Timers: U kunt willekeurige wachttijden tussen verzoeken opgeven.

Met de blokken hierboven kun je de testscenario's opbouwen die je eerder hebt bepaald. Een voorbeeld kan er zo uitzien: 

performance_testplan

Zoals u kunt zien, zullen we in dit testscenario de Google homepage laden en controleren of het antwoord het woord "Search" bevat. Ook slaan we met behulp van een XPath-extractor een fictieve CSRF-loper uit de vorm op in een variabele. Door een cache en cookie manager toe te voegen, simuleren we een echte browser. Als het testscenario een tweede verzoek bevat, worden de opgeslagen beelden direct vanuit de cache in plaats van vanaf de externe server geladen.

OP WELKE OMGEVING MOET IK MIJN LOAD TESTS UITVOEREN?

Om een zo goed mogelijk beeld te krijgen van het verkeer dat uw infrastructuur aankan, kunt u deze tests het beste uitvoeren op het productiesysteem. U kunt proberen een moment te vinden waarop er niet veel verkeer op de website is en doe dit dan het tijdens deze uren. Wanneer dit niet mogelijk is, wordt geadviseerd een duplicaatomgeving op te zetten met exact dezelfde middelen. Het is mogelijk om de resources te downgraden, maar dan weet je niet bij hoeveel verbindingen de applicatie zal crashen. Een voordeel van het downgraden van de middelen is dat u met minder moeite de zwakste service kunt vinden.

HOE VOER IK MIJN LOAD TESTS UIT?

Een van de keerzijden van de JMeter is dat hij draait op het systeem waarop hij is geïnstalleerd. Daarom beperkt u zich tot de resources van uw computer of de bandbreedte van uw netwerk. U kunt zich voorstellen dat dit niet voldoende zal zijn om de grenzen van uw systeem te detecteren. Daarom moeten we de tests uitvoeren via een gedistribueerd netwerk van bezoekers.

Een van de diensten die gedistribueerde bezoekers leveren voor load testing is BlazeMeter. U kunt een nieuwe load test maken op BlazeMeter en het JMeter-configuratiebestand uploaden. Vervolgens kunt u aangeven op welke locatie u de test wilt uitvoeren. Mogelijke opties zijn AWS, Google Compute of Microsoft Azure. Vervolgens kunt u aangeven hoeveel gelijktijdige gebruikers u wilt simuleren. Je kunt ze over meerdere threads en meerdere fysieke engines verspreiden. Houd er rekening mee dat het aantal gebruikers wordt vermenigvuldigd met het aantal threads in uw JMeter-project. Ten slotte kunt u kiezen hoe lang u de test wilt uitvoeren of hoeveel herhalingen u wilt uitvoeren. De configuratie kan er zo uitzien:

performance2_load_configuration

Na het uitvoeren van de load tests, krijg je een breed scala aan resultaten. Voor de bovenstaande test kan het resultaat er als volgt uitzien:

Natuurlijk zijn deze resultaten niet erg nauwkeurig: Google ziet geen 10 extra gebruikers op hun systeem. Echter, het geeft u een idee van hoe de load resultaten eruitzien. Naast deze statistieken is het mogelijk om uw eigen statistieken te genereren met de monitoring tools die u graag gebruikt. Bijvoorbeeld: Er is een New Relic plugin beschikbaar om de data van de load tests te koppelen aan de data van New relic.

HOE KAN IK MIJN SERVER RESOURCES MONITOREN?

Zoals u kunt zien, bevatten de statistieken van New Relic informatie over de reactietijd, het aantal fouten en soortgelijke generieke statistieken. Als u wilt weten hoe de load uw infrastructuur infecteert, moet u extra resource logging inschakelen tijdens de load test.

Tijdens de tests controleren we de serverprocessen met het top command. We installeren ook New Relic op de machines zodat we achteraf geavanceerde systeemstatistieken kunnen genereren. Op deze manier is het mogelijk om geavanceerde statistieken weer te geven zoals: CPU-gebruik, geheugengebruik, netwerkverkeer, toepassingsfouten, mysql-fouten, ... tijdens de load tests.

Natuurlijk is het mogelijk dat de prestatieproblemen te maken hebben met trage code in uw applicatie. De Transaction sectie in New Relic toont de top 10 langzaamste pagina's, inclusief details. Op deze manier kunt u snel detecteren welke code de oorzaak is van de langzame reactietijden. U kunt de code verbeteren of wat caching toevoegen en de load tests opnieuw uitvoeren. Als u nog een stap verder gaat, kunt u automatische Blackfire-tests toevoegen voor dit specifieke scenario om ervoor te zorgen dat een deel van de code uw toepassing nooit meer vertraagt.

In New Relic is het mogelijk om op maat gemaakte ladingsdashboards te maken. Als u regelmatig load tests op uw systeem uitvoert, kunt u dit dashboard als rapportagetool gebruiken. Dit maakt het mogelijk om load tests uit te voeren en de resultaten in een paar uur te rapporteren. Het dashboard kan ook worden gebruikt om het echte verkeer op uw toepassing te monitoren.

performance3_load_response time