als u een e-commerce site hebt (of een andere site), is het niet ongewoon dat u een hoger niveau van verkeer verwacht op bepaalde dagen, zoals bijvoorbeeld Black Friday. Op momenten als deze, we nodig hebben om onze belasting testen naar het volgende niveau en simuleren grotere aantallen gelijktijdige gebruikers. Als we onze load tests lokaal uitvoeren met Apache JMeter™, zijn er bepaalde beperkingen aan het aantal gebruikers dat u kunt uitvoeren, zelfs als uw computer voldoende CPU en geheugen heeft.
Hoe kunnen we een scenario maken met meer dan 800 gelijktijdige gebruikers die JMeter gebruiken? Een van de antwoorden is het draaien van JMeter in gedistribueerde modus. Voor degenen onder jullie die er nog nooit van gehoord hebben, hier is een korte uitleg.
wanneer we het hebben over het distribueren van JMeter, verwijzen we naar een Master-Slave architectuur waar JMeter Java RMI gebruikt om te interageren met objecten in een gedistribueerd netwerk. U kunt dit zien in de afbeelding hieronder.
gedistribueerde testen maakt het mogelijk om een lokale Jmeter (master) te hebben die de testuitvoering afhandelt, samen met meerdere externe Jmeter-instanties (slaves) die het verzoek naar onze doelserver sturen.
maar voordat u JMeter op een gedistribueerde manier kunt uitvoeren, zijn er een paar eenvoudige stappen die u moet uitvoeren.
eerst moeten we meerdere computers hebben.
dan moeten we de Jmeter Server draaien op elk slave systeem dat we hebben. Daarvoor moeten we de Jmeter-server uitvoeren.bat (jmeter-server voor Unix gebruikers) die zich in de Jmeter/bin bevindt. Als we het eenmaal draaien, zien we zoiets als dit.:
dan, via hetzelfde pad, maar in het mastersysteem, lokaliseer de jmeter.eigenschappen fil. Bewerk dit bestand en voeg de IP ‘ s toe van alle slave systemen die betrokken zouden moeten zijn bij de property remote_hosts. Zorg ervoor dat de master en de slave systemen zich in hetzelfde subnet bevinden.
het is heel belangrijk om te onthouden dat alle waarden gescheiden moeten worden door komma ‘ s (in dit voorbeeld gebruiken we slechts één slave systeem, om het simpel te houden).
zodra al deze stappen zijn uitgevoerd, kunnen we JMeter starten en de tests uitvoeren die we nodig hebben. In dit geval gaan we Jmeter uitvoeren met behulp van de GUI-modus, zodat we een beter idee hebben van hoe het werkt. Echter, niet-GUI-modus wordt sterk aanbevolen voor testdoeleinden.
het aantal gebruikers, opritten en iteraties moeten zoals gewoonlijk worden geconfigureerd in de threadgroep master systems. Bij het uitvoeren van de test worden deze voorwaarden op elk slavesysteem herhaald.
na het starten van JMeter en het laden van onze test, hebben we twee opties. Een, geconfigureerd via het master systeem, is via Run->Remote Start en selecteer vervolgens het slave systeem waar we willen uitvoeren. De tweede, ook geconfigureerd via het master systeem, wordt uitgevoerd->Remote Start All om de test op alle beschikbare slave systemen te starten.
(aangezien we slechts één slave systeem instellen, is er geen verschil tussen de twee opties in dit voorbeeld).
hier hebben we een eenvoudig scenario waarin we een artikel kunnen zoeken en bekijken op een e-commerce site:
zoals u kunt zien, hebben we een view Results Tree listener toegevoegd zodat we kunnen controleren of de test correct is uitgevoerd of niet. Als we een test op afstand uitvoeren, zullen we lokaal het testresultaat kunnen zien op de View Results Tree listener zoals ik al zei, maar in de slave-systemen kunnen we alleen de begin-en eindtijd van de test observeren.
Lokaal:
Op Afstand:
achter de schermen voert elk slavesysteem de load tests uit met de voorwaarden die we in het mastersysteem hebben gesteld. Op deze manier bereiken we een hoger aantal gelijktijdige gebruikers, en dus een hogere belasting op onze doelserver.
daarom, als we de lading echt willen verdelen, moeten we het handmatig doen. Bijvoorbeeld: als we 10.000 gelijktijdige gebruikers willen bereiken en we hebben 10 slave-systemen, moet ons testplan 1000 gebruikers hebben, dus hebben we uiteindelijk in totaal 10.000.
een ander interessant ding dat we kunnen doen is om logica aan onze test toe te voegen door een If Controller toe te voegen. De If Controller stelt ons in staat om een bepaalde flow te kiezen die we willen uitvoeren, afhankelijk van het systeem dat de test uitvoert. Ao, verschillende slave systemen zouden worden uitgevoerd verschillende delen van de test.
bijvoorbeeld, als we een parameter toevoegen bij het draaien van de Jmeter-server op de slave systemen (./ jmeter-server-Jparam = 1) We kunnen een voorwaarde als ${__javaScript(${param}==1)} binnen de IF Controller plaatsen, zodat we bepaalde verzoeken kunnen uitvoeren afhankelijk van het slave systeem.
dat is het! We hebben met succes een test uitgevoerd over een Jmeter gedistribueerd systeem. Dit ziet er misschien niet erg complex uit omdat we er voor kozen om slechts één slave systeem te gebruiken. Maar als je nodig hebt om 25.000 gelijktijdige gebruikers te simuleren, de kosten van het onderhoud van al deze systemen zijn enorm. Er kan een mogelijke oplossing voor het onderhoud problemen en dat is om alle architectuur die we hebben gezien over Docker containers monteren (u kunt een voorbeeld hier zien).
echter, dit zal nog steeds niet goed genoeg zijn als ons doel is om load tests periodiek uit te voeren. We hebben alle gedistribueerde architectuur in één computer gemonteerd, dus we verbruiken een aanzienlijke hoeveelheid middelen. Het concept van het verdelen van JMeter over Docker is zinvoller als we de mogelijkheid hebben om het aantal containers op aanvraag te verhogen, zoals in een cloud computing service.
een ander probleem bij het uitvoeren van JMeter in gedistribueerde modus is hoe CSV-bestanden te behandelen wanneer u gegevens hebt geparametriseerd in uw tests. Dit is omdat we gescheiden bestanden moeten hebben, en als we ze moeten updaten, moeten we naar elk slave systeem gaan en de wijzigingen aanbrengen.
om al deze beperkingen en ongemakken op te lossen, kunnen we BlazeMeter gebruiken, wat ons een gemakkelijke manier biedt om onze load tests af te handelen. Alles wat we nodig hebben om ons JMX bestand te uploaden naar BlazeMeter. We kunnen ook een geconsolideerd CSV-bestand uploaden met alle benodigde gegevens en BlazeMeter zal zorgen voor het splitsen, afhankelijk van het aantal engines dat we hebben ingesteld.
op BlazeMeter kunnen we het aantal gebruikers of de combinatie van motoren (slave-systemen) en threads instellen die we op onze tests willen toepassen. We kunnen ook aanvullende waarden zoals meerdere locaties configureren.
testresultaten:
dat is het! Nu heb je een paar oplossingen gezien voor het uitvoeren van load tests op grote schaal, mijn aanbeveling voor u is om uw eigen ervaring te creëren en een beslissing te nemen over welke optie biedt u meer voordelen.
leer meer over het gebruik van JMeter via onze gratis Jmeter academy.
