JMeter tip

JMeter er et populært open source-værktøj til belastningstest med mange nyttige modelleringsfunktioner såsom trådgruppe, timer og HTTP-samplerelementer. Denne artikel supplerer JMeter-brugervejledningen og giver retningslinjer for brug af nogle af JMeter-modelleringselementerne til at udvikle et kvalitetstestscript.

Denne artikel behandler også et vigtigt emne i en større sammenhæng: Angivelse af præcise krav til responstid og validering af testresultater. Specifikt anvendes en streng statistisk metode, konfidensintervalanalysen.

Bemærk, at jeg antager, at læserne kender det grundlæggende i JMeter. Denne artikels eksempler er baseret på JMeter 2.0.3.

Bestem en trådgruppes opstartsperiode

Den første ingrediens i dit JMeter-script er en trådgruppe, så lad os gennemgå den først. Som vist i figur 1 indeholder et trådgruppelement følgende parametre:

• Antal tråde.
• Opstartsperioden.
• Antallet af gange, testen skal udføres.
• Når startet, om testen kører med det samme eller venter til et planlagt tidspunkt. Hvis sidstnævnte, skal trådgruppeelementet også omfatte start- og sluttider.

Hver tråd udfører testplanen uafhængigt af andre tråde. Derfor bruges en trådgruppe til at modellere samtidige brugere. Hvis klientmaskinen, der kører JMeter, mangler nok computerkraft til at modellere en tung belastning, giver JMeters distributive testfunktion dig mulighed for at styre flere eksterne JMeter-motorer fra en enkelt JMeter-konsol.

Opstartsperioden fortæller JMeter, hvor lang tid der er til oprettelse af det samlede antal tråde. Standardværdien er 0. Hvis opstartsperioden ikke er specificeret, dvs. opstartsperioden er nul, opretter JMeter straks alle tråde. Hvis opstartsperioden er sat til T sekunder, og det samlede antal tråde er N, opretter JMeter en tråd hvert T / N sekund.

De fleste af en trådgruppes parametre er selvforklarende, men opstartsperioden er lidt underlig, da det passende antal ikke altid er indlysende. For det første bør opstartsperioden ikke være nul, hvis du har et stort antal tråde. I starten af ​​en belastningstest, hvis opstartsperioden er nul, opretter JMeter alle tråde på én gang og sender anmodninger med det samme, hvilket potentielt mætter serveren og, vigtigere, vildledende øger belastningen. Det vil sige, at serveren kan blive overbelastet, ikke fordi den gennemsnitlige hitrate er høj, men fordi du sender alle trådens første anmodninger samtidigt, hvilket forårsager en usædvanlig initial hitfrekvens. Du kan se denne effekt med en JMeter Aggregate Report-lytter.

Da denne anomali ikke er ønskelig, er tommelfingerreglen til bestemmelse af en rimelig opstartsperiode at holde den oprindelige hitrate tæt på den gennemsnitlige hitrate. Selvfølgelig kan det være nødvendigt at køre testplanen en gang, før du finder et rimeligt antal.

På samme måde er en stor opstartsperiode heller ikke passende, da spidsbelastningen kan undervurderes. Det vil sige, at nogle af tråde måske ikke engang er startet, mens nogle indledende tråde allerede er afsluttet.

Så hvordan kontrollerer du, at opstartsperioden hverken er for lille eller for stor? Gæt først den gennemsnitlige hitfrekvens, og bereg derefter den indledende opstartsperiode ved at dividere antallet af tråde med den gættede hitrate. For eksempel, hvis antallet af tråde er 100, og den estimerede hitrate er 10 hits pr. Sekund, er den estimerede ideelle opstartsperiode 100/10 = 10 sekunder. Hvordan finder du en estimeret hitrate? Der er ingen nem måde. Du skal bare køre testskriptet en gang først.

For det andet skal du tilføje en samlet rapportlytter, vist i figur 2, til testplanen; den indeholder den gennemsnitlige hitfrekvens for hver enkelt anmodning (JMeter-samplere). Hitfrekvensen for den første sampler (f.eks. En HTTP-anmodning) er tæt knyttet til opstartsperioden og antallet af tråde. Juster opstartsperioden, så hitfrekvensen for testplanens første sampler er tæt på den gennemsnitlige hitfrekvens for alle andre samplere.

For det tredje skal du kontrollere i JMeter-loggen (placeret i JMeter_Home_Directory / bin), at den første tråd, der er færdig, faktisk slutter, når den sidste tråd starter. Tidsforskellen mellem de to skal være så langt fra hinanden som muligt.

Sammenfattende bestemmes bestemmelsen af ​​en god opstartstid af følgende to regler:

• Den første samplers hitfrekvens skal være tæt på den gennemsnitlige hitfrekvens for andre samplere og derved forhindre en lille opstartsperiode
• Den første tråd, der er færdig, slutter faktisk efter den sidste tråd starter, helst så langt fra hinanden som muligt, hvorved en stor opstartsperiode forhindres

Nogle gange er de to regler i konflikt med hinanden. Det vil sige, du kan simpelthen ikke finde en passende opstartsperiode, der passerer begge regler. En triviel testplan forårsager normalt dette problem, fordi du i en sådan plan mangler nok samplere til hver tråd; testplanen er således for kort, og en tråd afslutter hurtigt sit arbejde.

Brugerens tænketid, timer og proxyserver

Et vigtigt element at overveje i en belastningstest er tænk tid, eller pause mellem successive anmodninger. Forskellige omstændigheder forårsager forsinkelsen: brugeren har brug for tid til at læse indholdet eller udfylde en formular eller søge efter det rigtige link. Manglende overvejelse korrekt tænker tid ofte fører til alvorligt partisk testresultater. For eksempel vises den estimerede skalerbarhed, dvs. den maksimale belastning (samtidige brugere), som systemet kan opretholde, lav.

JMeter leverer et sæt timerelementer til modellering af tænketiden, men der er stadig et spørgsmål: hvordan bestemmer du en passende tænketid? Heldigvis tilbyder JMeter et godt svar: JMeter HTTP Proxy Server-elementet.

Proxy-serveren registrerer dine handlinger, mens du gennemsøger et webapplikation med en normal browser (såsom FireFox eller Internet Explorer). Derudover opretter JMeter en testplan, når du optager dine handlinger. Denne funktion er yderst praktisk til flere formål:

• Du behøver ikke oprette en HTTP-anmodning manuelt, især de kedelige formparametre. (Ikke-engelske parametre fungerer dog muligvis ikke korrekt.) JMeter registrerer alt i de automatisk genererede anmodninger, inklusive skjulte felter.
• I den genererede testplan inkluderer JMeter alle browsergenererede HTTP-headere til dig, såsom User-Agent (f.eks. Mozilla / 4.0) eller AcceptLanguage (f.eks. Zh-tw, en-us; q = 0,7, zh- cn; q = 0,3).
• JMeter kan oprette timere efter eget valg, hvor forsinkelsestid indstilles i henhold til den faktiske forsinkelse i optagelsesperioden.

Lad os se, hvordan du konfigurerer JMeter med optagefunktionen. I JMeter-konsollen skal du højreklikke på WorkBench-elementet og tilføje HTTP-proxyserverelementet. Bemærk, at du højreklikker på WorkBench-elementet, ikke på Testplan-elementet, fordi konfigurationen her er til optagelse, ikke til en eksekverbar testplan. HTTP-proxyserverelementets formål er, at du konfigurerer browserens proxyserver, så alle anmodninger går gennem JMeter.

Som illustreret i figur 3 skal flere felter konfigureres til HTTP-proxyserverelementet:

• Havn: Lytteporten, der bruges af proxyserveren.
• Målcontroller: Den controller, hvor proxyen gemmer de genererede prøver. Som standard vil JMeter lede efter en optagecontroller i den aktuelle testplan og gemme prøverne der. Alternativt kan du vælge ethvert controller-element, der er angivet i menuen. Normalt er standard okay.
• Gruppering: Hvordan du vil gruppere de genererede elementer i testplanen. Flere muligheder er tilgængelige, og den mest fornuftige er sandsynligvis "Gem kun 1. sampler i hver gruppe", ellers registreres også webadresser indlejret i en side som dem til billeder og JavaScripts. Det kan dog være en god idé at prøve standardindstillingen "Gruppér ikke prøver" for at finde ud af, hvad JMeter præcist opretter til dig i testplanen.
• Mønstre, der skal medtages og Mønstre, der skal udelukkes: Hjælp dig med at filtrere nogle uønskede anmodninger ud.

Når du klikker på Start-knappen, starter proxyserveren og begynder at optage de HTTP-anmodninger, den modtager. Før du klikker på Start, skal du selvfølgelig konfigurere din browsers proxyserverindstilling.

Du kan tilføje en timer som barn af HTTP-proxyserverelementet, som vil instruere JMeter om automatisk at tilføje en timer som barn af den HTTP-anmodning, den genererer. JMeter gemmer automatisk den aktuelle forsinkelse i en kaldet JMeter-variabel T, så hvis du tilføjer en Gaussisk tilfældig timer til HTTP-proxyserverelementet, skal du skrive $ {T} i feltet Konstant forsinkelse, som vist i figur 4. Dette er en anden praktisk funktion, der sparer dig meget tid.

Bemærk, at en timer får de berørte samplere til at blive forsinket. Det vil sige, at de berørte samplingsanmodninger ikke sendes, før den specificerede forsinkelsestid er gået siden det sidst modtagne svar. Derfor skal du manuelt fjerne den første samplers genererede timer, da den første sampler normalt ikke har brug for en.

Inden du starter HTTP-proxyserveren, skal du tilføje en trådgruppe til testplanen og derefter tilføje en optagecontroller til trådgruppen, hvor de genererede elementer gemmes. Ellers tilføjes disse elementer direkte til WorkBench. Derudover er det vigtigt at tilføje et HTTP-anmodningsstandardelement (et konfigurationselement) til optagecontrolleren, så JMeter efterlader de felter, der er angivet af standardindstillingerne for HTTP-anmodning, blanke.

Efter optagelsen skal du stoppe HTTP-proxyserveren. højreklik på Recording Controller-elementet for at gemme de optagede elementer i en separat fil, så du kan hente dem senere. Glem ikke at genoptage din browsers proxyserverindstilling.

Angiv krav til responstid og valider testresultater

Selvom det ikke er direkte relateret til JMeter, er det to vigtige opgaver til belastningstest at specificere krav til responstid og validering af testresultater, idet JMeter er broen, der forbinder dem.

I forbindelse med webapplikationer henviser responstid til den forløbne tid mellem indsendelse af en anmodning og modtagelse af den resulterende HTML. Teknisk set skal svartid omfatte tid for browseren til at gengive HTML-siden, men en browser viser typisk siden stykke for stykke, hvilket gør den opfattede svartid mindre. Desuden beregner et belastningstestværktøj typisk responstiden uden at overveje gengivelsestid. Af praktiske grunde til præstationstest vedtager vi derfor den ovenfor beskrevne definition. Hvis du er i tvivl, tilføj en konstant til den målte responstid, sig 0,5 sekunder.

Der er et sæt velkendte regler til bestemmelse af svartidskriterier:

• Brugere bemærker ikke en forsinkelse på mindre end 0,1 sekund
• En forsinkelse på mindre end 1 sekund afbryder ikke brugerens tankegang, men der bemærkes en vis forsinkelse
• Brugere vil stadig vente på svaret, hvis det forsinkes med mindre end 10 sekunder
• Efter 10 sekunder mister brugerne fokus og begynder at gøre noget andet

Disse tærskler er velkendte og vil ikke ændre sig, da de er direkte relateret til menneskers kognitive egenskaber. Selvom du skal indstille dine svartidskrav i overensstemmelse med disse regler, skal du også justere dem til din specifikke applikation. For eksempel overholder Amazon.com's hjemmeside reglerne ovenfor, men fordi det foretrækker et mere stilistisk udseende, ofrer det lidt responstid.

Ved første øjekast ser der ud til at være to forskellige måder at specificere krav til svartid:

• Gennemsnitlig svartid
• Absolut responstid svarstiderne for alle svar skal være under tærsklen

At specificere gennemsnitlige svartidskrav er ligetil, men det faktum, at dette krav ikke tager højde for datavariation, er foruroligende. Hvad hvis svartiden på 20 procent af prøverne er mere end tre gange gennemsnittet? Bemærk, at JMeter beregner den gennemsnitlige responstid samt standardafvigelsen for dig i grafresultatlytteren.

På den anden side er det absolutte svartidskrav ret strengt og statistisk ikke praktisk. Hvad hvis kun 0,5 procent af prøverne ikke bestod prøverne? Igen er dette relateret til prøveudtagningsvariation. Heldigvis overvejer en streng statistisk metode prøveudtagningsvariation: konfidensintervalanalysen.

Lad os gennemgå grundlæggende statistikker, inden vi går videre.

Den centrale grænsesætning

Den centrale grænsesætning siger, at hvis populationsfordelingen har gennemsnit μ og standardafvigelse σ, så for tilstrækkelig stor n (> 30), er prøveuddelingen af ​​prøveudtagningsgennemsnittet omtrent normal med gennemsnit μ_betyde = μ og standardafvigelse σ_betyde = σ / √n.

Noter det fordelingen af ​​prøveudtagningsgennemsnittet er normalt. Fordelingen af ​​selve prøvetagningen er ikke nødvendigvis normal. Det vil sige, hvis du kører dit testscript mange gange, vil fordelingen af ​​de resulterende gennemsnitlige svartider være normal.

Figur 5 og 6 nedenfor viser to normale fordelinger. I vores sammenhæng er den vandrette akse samplingsgennemsnittet for responstid, forskudt, så populationsgennemsnittet er ved oprindelsen. Figur 5 viser, at prøveudtagningsmediet ligger 90% af tiden inden for intervallet ± Zσ, hvor Z = 1.645 og σ er standardafvigelsen. Figur 6 viser tilfældet med 99 procent, hvor Z = 2,576. For en given sandsynlighed, siger 90 procent, kan vi slå den tilsvarende Z-værdi op med en normal kurve og omvendt.