om du har en e-handelsplats (eller någon webbplats för den delen) är det inte ovanligt att du förväntar dig en högre trafiknivå på vissa dagar, till exempel Black Friday. I stunder som dessa måste vi ta våra lasttester till nästa nivå och simulera större antal samtidiga användare. Om vi kör våra belastningstester lokalt med Apache jmeter bisexual, finns det vissa begränsningar för antalet användare du kan köra, även om din dator har tillräckligt med CPU och minne.
Hur kan vi skapa ett scenario med mer än 800 samtidiga användare som använder JMeter? Ett av svaren är att köra JMeter i distribuerat läge. För er som aldrig hört talas om det, här är en kort förklaring.
när vi pratar om att distribuera JMeter hänvisar vi till en Master-Slave-arkitektur där JMeter använder Java RMI för att interagera med objekt i ett distribuerat nätverk. Du kan se detta i bilden nedan.
distribuerad testning möjliggör att ha en lokal JMeter (master) som hanterar testkörningen, tillsammans med flera fjärranslutna JMeter-instanser (slavar) som skickar begäran till vår målserver.
men innan du kan köra JMeter på ett distribuerat sätt finns det några enkla steg du måste utföra.
först måste vi ha flera datorer.
då måste vi få JMeter-servern att köra på varje slavsystem som vi har. För detta ändamål måste vi köra jmeter-servern.bat (jmeter-server för Unix-användare) som finns i jmeter/bin. När vi kör det borde vi se något så här:
sedan, genom samma väg, men i mastersystemet, lokalisera jmeter.egenskaper fil. Redigera den här filen och Lägg till IP: erna för alla slavsystem som ska vara inblandade i egenskapen remote_hosts. Se till att master-och slavsystemen finns i samma delnät.
det är mycket viktigt att komma ihåg att alla värden måste separeras med kommatecken (i det här exemplet använder vi bara ett slavsystem, bara för att hålla det enkelt).
när alla dessa steg har uppnåtts kan vi starta JMeter och utföra de tester vi behöver. I det här fallet kommer vi att köra JMeter med GUI-läge, så vi kan få en bättre uppfattning om hur det fungerar. Icke-GUI-läge rekommenderas dock starkt för teständamål.
antalet användare, ramp upp och iterationer ska konfigureras i master systems Trådgrupp som vanligt. När du kör testet kommer dessa villkor att replikeras på varje slavsystem.
efter att ha startat JMeter och laddat vårt test har vi två alternativ. En, konfigurerad via mastersystemet, är genom Run- >fjärrstart och välj sedan slavsystemet där vi vill köra. Den andra, även konfigurerad via mastersystemet, körs->Remote Start All för att starta testet på alla tillgängliga slavsystem.
(eftersom vi bara ställer in ett slavsystem finns det ingen skillnad mellan de två alternativen i det här exemplet).
Här har vi ett enkelt scenario där vi kan söka och visa en artikel på en e-handelsplats:
som du kan se har vi lagt till en View Results Tree listener så att vi kan kontrollera om testet utfördes korrekt eller inte. När vi kör ett test på distans kommer vi att kunna lokalt se testresultatet på View Results Tree listener som jag redan nämnde, men i slave-systemen kan vi bara observera starttiden och sluttiden för testet.
Lokalt:
Distans:
bakom kulisserna utför varje slavsystem lasttesterna med de villkor som vi ställer in i mastersystemet. På så sätt uppnår vi ett högre antal samtidiga användare, och därmed en högre belastning på vår målserver.
därför, om vi verkligen vill fördela belastningen, måste vi göra det manuellt. T. ex: om vi vill nå 10 000 samtidiga användare och vi har 10 slavsystem, måste vår testplan ha 1000 användare, så vi har totalt 10 000.
en annan intressant sak vi kan göra är att lägga till logik i vårt test genom att lägga till en If-kontroller. If-styrenheten tillåter oss att välja ett visst flöde vi vill köra, beroende på vilket system som utför testet. Ao, olika slavsystem skulle köra olika delar av testet.
om vi till exempel lägger till en parameter när vi kör jmeter-servern på slavsystemen (./ jmeter-server-Jparam=1) Vi kan placera ett villkor som ${__javaScript(${param}==1)} inom If-kontrollen, så vi kan utföra särskilda förfrågningar beroende på slavsystemet.
det är det! Vi har framgångsrikt genomfört ett test över ett JMeter distribuerat system. Det här kanske inte ser väldigt komplicerat ut eftersom vi valde att bara använda ett slavsystem. Men om du behöver simulera 25 000 samtidiga användare är kostnaden för att underhålla alla dessa system enorm. Det kan finnas en möjlig lösning för underhållsproblemen och det är att montera all arkitektur som vi har sett över Docker-behållare (du kan se ett exempel här).
detta kommer dock fortfarande inte att vara tillräckligt bra om vårt mål är att köra belastningstester regelbundet. Vi har monterat all distribuerad arkitektur i en dator, så vi konsumerar en betydande mängd resurser. Konceptet att distribuera JMeter över Docker är mer meningsfullt om vi har möjlighet att eskalera antalet containrar på begäran, som i en molntjänst.
en annan svårighet när du kör JMeter i distribuerat läge är hur du hanterar CSV-filer när du har parametriserat data i dina tester. Detta beror på att vi måste ha separerade filer, och om vi måste uppdatera dem måste vi gå till varje slavsystem och göra ändringarna.
för att lösa alla dessa begränsningar och olägenheter kan vi använda BlazeMeter, vilket ger oss ett enkelt sätt att hantera våra lasttester. Allt vi behöver göra ladda upp vår JMX-fil till BlazeMeter. Vi kan också ladda upp en konsoliderad CSV-fil med all nödvändig data och BlazeMeter tar hand om att dela upp den, beroende på mängden motorer Vi har ställt in.
på BlazeMeter kan vi ställa in antalet användare eller kombinationen av motorer (slavsystem) och trådar som vi vill tillämpa på våra tester. Vi kan också konfigurera ytterligare värden som flera platser.
Testresultat:
det är det! Nu har du sett några lösningar för att köra lasttester i stor skala, min rekommendation till dig är att skapa din egen upplevelse och fatta ett beslut om vilket alternativ som ger dig större fördelar.
Läs mer om hur du använder JMeter från vår gratis JMeter academy.
