hvis du har en e-handel (eller et nettsted for saks skyld), det er ikke uvanlig at du forventer et høyere nivå av trafikk på bestemte dager, Som Black Friday, for Eksempel. På øyeblikk som disse må vi ta våre lasttester til neste nivå og simulere større antall samtidige brukere. Hvis vi kjører belastningstestene våre lokalt med Apache JMeter™, er det visse begrensninger for antall brukere du kan kjøre, selv om datamaskinen din har NOK CPU og minne.
Hvordan kan vi lage et scenario med mer enn 800 samtidige brukere som bruker JMeter? Et av svarene kjører JMeter i distribuert modus. For de av dere som aldri har hørt om det, her er en kort forklaring.
når vi snakker om å distribuere JMeter, refererer Vi til En Master-Slave-arkitektur der JMeter bruker Java RMI til å samhandle med objekter i et distribuert nettverk. Du kan se dette i bildet nedenfor.
Distribuert testing gjør det mulig å ha en lokal jmeter (master) som håndterer testutførelsen, sammen med flere eksterne jmeter-forekomster (slaver) som sender forespørselen til målserveren vår.
Men før du kan kjøre JMeter på en distribuert måte, er det et par enkle trinn du må utføre.
Først må vi ha flere datamaskiner.
da må Vi få JMeter-Serveren til å kjøre på hvert slavesystem som vi har. For det formålet må vi utføre jmeter-serveren.bat (jmeter-server For Unix-brukere) som ligger i jmeter/bin. Når vi kjører det, bør vi se noe slikt:
deretter, gjennom samme bane, men i hovedsystemet, finn jmeteret.egenskaper fil. Rediger denne filen og legg Til Ip-ene til alle slavesystemene som skal være involvert i egenskapen remote_hosts. Kontroller at master-og slavesystemene er plassert i samme delnett.
Det er veldig viktig å huske at alle verdiene må skilles med kommaer (i dette eksemplet bruker vi bare ett slavesystem, bare for å holde det enkelt).
når alle disse trinnene er oppnådd, kan Vi starte JMeter og utføre testene vi trenger. I dette tilfellet skal Vi utføre JMeter ved HJELP AV GUI-Modus, slik at vi kan få en bedre ide om hvordan det fungerer. Imidlertid anbefales ikke-GUI-modus sterkt for testformål.
antall brukere, rampe opp og iterasjoner skal konfigureres i master systems Thread-Gruppen som vanlig. Når du kjører testen, vil disse forholdene bli replikert på hvert slavesystem.
Etter å ha startet JMeter og lastet vår test, har vi to alternativer. En, konfigurert gjennom master-systemet, er Gjennom Run – >Fjernstart og velg deretter slavesystemet der vi vil utføre. Den andre, også konfigurert gjennom master-systemet, Kjøres – >Fjernstart Alle for å starte testen på alle tilgjengelige slavesystemer.
(Som vi setter bare ett slavesystem, er det ingen forskjell mellom de to alternativene i dette eksemplet).
her har vi et enkelt scenario der vi kan søke og se en artikkel på et e-handelsnettsted:
Som du kan se, har vi lagt Til A Se Resultatene Tre lytteren slik at vi kan sjekke om testen ble utfort riktig eller ikke. Når vi kjører en test eksternt, skal vi kunne se testresultatet lokalt på Visningsresultattrelytteren som jeg allerede nevnte, men i slavesystemene kan vi bare observere starttid og sluttidspunkt for testen.
Lokalt:
Eksternt:
Bak kulissene utfører hvert slavesystem belastningstestene med forholdene vi satte i master-systemet. På denne måten oppnår vi et høyere antall samtidige brukere, og dermed en høyere belastning på målserveren vår.
derfor, Hvis vi virkelig vil distribuere lasten, må vi gjøre det manuelt. F. eks: hvis vi ønsker å nå 10.000 samtidige brukere og vi har 10 slavesystemer, må vår testplan ha 1000 brukere, så vi ender opp med å ha 10.000 totalt.
En annen interessant ting vi kan gjøre er å legge til logikk i testen vår ved å legge Til En If-Kontroller. Hvis-Kontrolleren lar Oss velge en bestemt flyt vi vil utføre, avhengig av systemet som utfører testen. Ao, forskjellige slavesystemer ville kjøre forskjellige deler av testen.
for eksempel, hvis vi legger til en parameter når du kjører jmeter-serveren på slavesystemene (./jmeter-server-Jparam=1) vi kan plassere en tilstand som ${__javaScript (${param}==1)} i If-Kontrolleren, slik at vi kan utføre spesielle forespørsler avhengig av slavesystemet.
Det er det! Vi har utført en test over Et JMeter distribuert system. Dette kan ikke se veldig komplisert ut fordi vi valgte å bruke bare ett slavesystem. Men hvis du trenger å simulere 25.000 samtidige brukere, er kostnadene ved å opprettholde alle disse systemene enorme. Det kan være en mulig løsning for vedlikeholdsproblemene, og det er å montere all arkitekturen vi har sett over Docker-beholdere (du kan se et eksempel her).
dette vil imidlertid fortsatt ikke være bra nok hvis vårt mål er å kjøre belastningstester med jevne mellomrom. Vi har montert all distribuert arkitektur i en datamaskin, så vi bruker en betydelig mengde ressurser. Konseptet med å distribuere JMeter Over Docker gir mer mening hvis vi har mulighet til å eskalere antall containere på forespørsel, som i en cloud computing-tjeneste.
Et annet problem når du kjører JMeter i distribuert modus, er hvordan du håndterer CSV-filer når du har parametrized data i testene dine. Dette skyldes at vi må ha separerte filer, og hvis vi må oppdatere dem, må vi gå til hvert slavesystem og gjøre endringene.
for å løse alle disse begrensningene og ulempene, kan Vi bruke BlazeMeter, som gir oss en enkel måte å håndtere våre lasttester. Alt vi trenger å gjøre laste OPP VÅR jmx fil Til BlazeMeter. Vi kan også laste opp en konsolidert CSV-fil med alle nødvendige data, Og BlazeMeter vil ta seg av å dele den, avhengig av mengden motorer vi har satt.
På BlazeMeter kan vi angi antall brukere eller kombinasjonen av motorer (slavesystemer) og tråder som vi vil søke på våre tester. Vi kan også konfigurere flere verdier som flere steder.
Testresultater:
Det er det! Nå har du sett noen løsninger for å kjøre lasttester i stor skala, min anbefaling for deg er å lage din egen erfaring og ta en beslutning om hvilket alternativ som gir deg større fordeler.
Lær mer om Hvordan du bruker JMeter fra vår gratis jmeter academy.
