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

Alvorens een nieuwe versie van uw project te lanceren, is het aan te raden om enkele belastingstesten uit te voeren op de applicatie. De resultaten van deze tests zullen u vertellen hoeveel gelijktijdige bezoekers uw applicatie kan verwerken in de huidige infrastructuur en welke serverbron het meest waarschijnlijk het eerst zal crashen.

Door te weten hoeveel gelijktijdige gebruikers uw applicatie kan verwerken, kunt u de configuratie van de servers aanpassen om er zeker van te zijn dat de infrastructuur het vooraf gedefinieerde aantal bezoekers kan verwerken. U kunt waarschuwingen toevoegen aan specifieke drempels zodat u de tijd hebt om op te schalen wanneer uw applicatie extra middelen nodig heeft. Door u bewust te zijn van de beperkingen van uw applicatie, kunt u zich aanpassen aan een toename van het verkeer.

Hoe kan ik laadtesten maken?

Het eerste wat u moet doen voordat u laadtesten kunt maken, is het specificeren van testscenario's. Een belangrijk onderdeel van het bepalen van deze scenario's is de kennis van het gedrag van de bezoeker in de website. Voor nieuwe sites kan dit een berekende gok zijn. Voor bestaande websites kunt u deze informatie ophalen uit tools zoals Google Analytics.

Bijvoorbeeld: wanneer u een gemiddelde webwinkel maakt, kunt u uw verkeer in de volgende scenario's opsplitsen:

• 20% Homepage
• 20% Landing pagina bezoekers
• 20% Catalogus / productpagina bezoekers
• 20% Bezoekers zoeken
• 20% Bestellen van bezoekers

Tijdens het uitvoeren van de laadtest wordt het verkeer over deze scenario's verspreid. Dit geeft u een reële spreiding van de belasting van de applicatie.

Zodra u de bovenstaande scenario's heeft gespecificeerd, is het tijd om de laadtesten te schrijven. Ons favoriete wapen is JMeter. Intern slaat de tool zijn configuratie op in een XML-formaat. Gelukkig is er ook een GUI voorzien die het gemakkelijk maakt om de testsuites te configureren. U kunt zich JMeter voorstellen als een krul workflow tool op steroïden. Het JMeter-project bestaat uit de volgende hoofdelementen:

• Testplan: Bevat door de gebruiker gedefinieerde variabelen zoals de omgeving, het pad, ...
• Draadgroepen: Is vergelijkbaar met een test suite
• Configureer elementen: U kunt hulpmiddelen toevoegen die cookie managers, browser cache, ....
• Controllers: Een controller bestaat uit samplers en kan logica bevatten, zoals als, terwijl, ....
• Sampler: Hiermee worden de HTTP-verzoeken uitgevoerd.
• Pre-processor: Zal geavanceerde dingen uitvoeren zoals het herschrijven van URL's voor het verzenden van de aanvraag.
• Post-processor: Verzamelt gegevens van een antwoord. U kunt bijvoorbeeld JSON- of formulierwaarden ontleden op basis van het CSS-selectorpad.
• Beweringen: Valideert of een antwoord de waarde bevat die het verwacht beschikbaar te zijn.
• Luisteraars: Listeners worden meestal gebruikt om rapporten en grafieken weer te geven.
• Timers: U kunt willekeurige wachttijden tussen de verzoeken opgeven.

Met de bovenstaande blokken kunt u de testscenario's opbouwen die u eerder hebt bepaald. Een voorbeeld kan er zo uitzien:

Zoals u kunt zien, zullen we in dit testscenario de Google homepage laden en controleren of het antwoord het woord "Zoeken" bevat. We slaan ook een fictief CSRF-token uit het formulier op in een variabele met behulp van een XPath extractor. Door het toevoegen van een cache en cookie manager, simuleren we een echte browser. Wanneer het testscenario een tweede verzoek bevat, zal het de opgeslagen afbeeldingen rechtstreeks vanuit de cache server server serveren in plaats van ze van de externe server te laden.

Op welke omgeving moet ik mijn laadtesten uitvoeren?

Om het beste idee te krijgen hoeveel verkeer uw infrastructuur kan verwerken, is het het beste om deze testen uit te voeren op het productiesysteem. U kunt proberen een moment te vinden waarop er niet veel verkeer op de website is en dit tijdens die uren te doen. Wanneer dit niet mogelijk is, is het aan te raden om een dubbele omgeving op te zetten met precies 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 resources is dat je met minder moeite de zwakste service kunt vinden.

Hoe voer ik mijn laadtesten uit?

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

Een van de diensten die gedistribueerde bezoekers voor het testen van de belasting leveren is BlazeMeter. U kunt een nieuwe loadtest maken op de 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. U kunt ze verdelen over meerdere threads en meerdere fysieke engines. Merk op dat het aantal gebruikers wordt vermenigvuldigd met het aantal threads in uw JMeter project. Tot slot kunt u kiezen hoe lang u de test wilt uitvoeren of hoeveel iteraties er moeten worden uitgevoerd. De configuratie kan er zo uitzien:

Na het uitvoeren van de laadtesten krijgt u een grote verscheidenheid aan resultaten. Voor de hierboven gespecificeerde test kan het resultaat er als volgt uitzien:

Hoe kan ik mijn serverbronnen monitoren?

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

Tijdens de tests controleren we de serverprocessen met het bovenste commando. Ook installeren we 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, applicatiefouten, mysql-fouten, .... tijdens de belastingstest.

Uiteraard is het mogelijk dat de performantieproblemen te maken hebben met trage code in uw applicatie. De Transacties sectie in New Relic toont de top 10 van langzaamste pagina's met hun stack sporen. Op deze manier kunt u snel detecteren welke code de trage reactietijden veroorzaakt. U kunt de code verbeteren of wat caching toevoegen en de belastingstests opnieuw uitvoeren. Als u nog een stap verder gaat, kunt u geautomatiseerde Blackfire-tests toevoegen voor dit specifieke scenario om ervoor te zorgen dat een deel van de code uw toepassing nooit meer zal vertragen.

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