JMeter Distribuert testing: Master-Slave-konfigurasjon

by: Thomas Hamilton Thomas Hamilton
Hours oppdatert

⚡ Smart oppsummering

Distribuert testing i JMeter bruker en master-slave-konfigurasjon for å generere last fra flere maskiner mot én enkelt målserver. Denne gjennomgangen forklarer klient-server-modellen og de nøyaktige trinnene for å konfigurere, kjøre og feilsøke en ekstern JMeter test.

  • 🖥️ Master-Slave-modell: Mesteren driver JMeter GUI og kontrollerer hver slave, mens slaver sender forespørsler til målserveren.
  • 🌐 Nettverksforutsetninger: Alle maskiner må dele samme delnett, kjøre det samme JMeter versjon, og ha brannmurer deaktivert.
  • ⚙️ Slavekonfigurasjon: Start jmeter-server.bat på hver slave, og oppgi deretter alle slave-IP-adressene i masterens jmeter.properties-fil.
  • ▶ ️ Kjører testen: Fra hovedgrensesnittet velger du Kjør > Ekstern start og velger slave-IP-adressen for å starte generering av last.
  • 🛠️ Feilsøkingsgrenser: Start jmeter-server.bat på nytt og deaktiver brannmurer; hver slave håndterer omtrent 100 til 300 tråder.
Les mer

JMeter Distribuert testing

Hva er distribuert testing?

distribuert Testing er en type testing som bruker flere systemer for å utføre Stresstesting. Distribuert testing brukes for å teste nettsteder og serverapplikasjoner når de jobber med flere klienter samtidig.

Distribuert testing bruker en klient-server-modell, som vist i figuren nedenfor:

Distribuert testing

  • Master: systemet som kjører JMeter GUI, som styrer hver slave.
  • Slave: systemet kjører JMeter-server, som mottar en kommando fra masteren og sender en forespørsel til en server under testing.
  • Target: webserveren under testing, som mottar forespørsler fra slavene.

Eksempel på fjerntest

Forutsetning:

  • Brannmurene på systemene er slått av. I noen tilfeller kan brannmuren fortsatt blokkere trafikken. Du bør deaktivere Windows brannmur eller Linux brannmur.
  • Alle maskinene bør være på samme delnett. Hvis maskinene ikke er på samme delnett, kan det hende at de ikke gjenkjenner hverandre i nettverket.
  • Bruk samme versjon av JMeter for å unngå uforutsette feil/problemer.

Her er det veikart for denne testen:

Eksempel på fjerntest

Trinn 1) Systemkonfigurasjon

Sett opp slave systemer: gå til jmeter/bin-katalogen og kjør filen «jmeter-server.bat».

Anta at en slavemaskin har IP-adressen 192.168.0.10. På Windows, bør du se et vindu som ser ut som på følgende figur:

Systemkonfigurasjon

På Master systemer, gå til /bin-katalogen og rediger filen jmeter.egenskaper, og legg deretter til IP-adressen til slavemaskinen som vist nedenfor:

Systemkonfigurasjon

Trinn 2) Kjør testen

Nå er du klar til å starte lasttesting. Kjør på hovedmaskinen JMeter GUI og åpne testplanen.

Klikk på Kjør på menylinjen, og velg deretter Fjernstart -> velg IP-adresse av slavemaskinen.

Kjør testen

Trinn 3) Feilsøking

Hvis du ikke klarer å kjøre testen fra maskinen ovenfor og ser feilen nedenfor, kan du ganske enkelt be eieren av en slavemaskin om å kjøre jmeter-server.bat-filen.

Feilsøking

Deaktiver brannmuren på både master- og slavemaskinene for å fikse denne feilen.

RELATERTE ARTIKLER

begrensning

Det er noen grunnleggende begrensninger for distribuert testing. Her er en liste over de kjente elementene:

  • Serveren og alle klientene må være på det samme subnett.
  • Distribuert testing krever at målserveren har stor prosessorkraft. Målserveren kan enkelt belastet i tilfelle den får for mange forespørsler fra distribuerte JMeter tester.
  • En enkelt JMeter slavesystemet kan vanligvis håndtere et begrenset antall tråder, fra 100 til 300 tråder, avhengig av maskinvarekonfigurasjonen og kompleksiteten til testplanen.
  • Den distribuerte JMeter tester er komplekse og vanskelige å lage for en nybegynner.

Spørsmål og svar

Ja. AI-verktøy kan oppsummere store resultatsett, oppdage ytelsesavvik og fremheve flaskehalser på tvers av slavemaskiner. De fremskynder analysen, men du konfigurerer og kjører fortsatt den distribuerte testinfrastrukturen selv.

Nei. AI hjelper med skripting og resultatanalyse, men å generere realistisk høy samtidighetsbelastning mot en server krever fortsatt distribuerte testmaskiner. AI utfyller distribuert testing i stedet for å erstatte infrastrukturen.

En enkelt master kan kjøre flere slaver. Den praktiske grensen avhenger av masterens CPU, minne og nettverkskapasitet. Hver slave håndterer vanligvis 100 til 300 tråder, så kapasiteten skaleres med antall slaver.

Lasttesting måler hvordan et system oppfører seg under forventet belastning. Distribuert testing sprer seg som laster på tvers av flere maskiner, noe som tillater langt høyere samtidighet enn en enkelt maskin kan generere alene.

Oppsummer dette innlegget med: