JMeter tips

JMeter er et populært verktøy for åpen kildekode for belastningstesting, med mange nyttige modelleringsfunksjoner som trådgruppe, tidtaker og HTTP samplerelementer. Denne artikkelen utfyller JMeter-brukerhåndboken og gir retningslinjer for bruk av noen av JMeter-modelleringselementene til å utvikle et kvalitetstestskript.

Denne artikkelen tar også opp et viktig spørsmål i en større sammenheng: spesifisering av presise krav til responstid og validering av testresultater. Nærmere bestemt brukes en streng statistisk metode, konfidensintervallanalysen.

Vær oppmerksom på at jeg antar at leserne vet det grunnleggende om JMeter. Denne artikkelens eksempler er basert på JMeter 2.0.3.

Bestem en trådgruppes oppstartperiode

Den første ingrediensen i JMeter-skriptet er en trådgruppe, så la oss gjennomgå den først. Som vist i figur 1 inneholder et trådgruppelement følgende parametere:

• Antall tråder.
• Oppstartsperioden.
• Antall ganger du skal utføre testen.
• Når startet, enten testen kjører umiddelbart eller venter til en planlagt tid. Hvis sistnevnte, må trådgruppelementet også inkludere start- og sluttider.

Hver tråd utfører testplanen uavhengig av andre tråder. Derfor brukes en trådgruppe for å modellere samtidige brukere. Hvis klientmaskinen som kjører JMeter, mangler nok datakraft til å modellere en tung belastning, lar JMeters distribuerende testfunksjon deg kontrollere flere eksterne JMeter-motorer fra en enkelt JMeter-konsoll.

Oppstartsperioden forteller JMeter hvor lang tid det er å lage det totale antallet tråder. Standardverdien er 0. Hvis oppstartsperioden ikke er spesifisert, dvs. oppstartsperioden er null, vil JMeter opprette alle trådene umiddelbart. Hvis oppstartsperioden er satt til T sekunder, og totalt antall tråder er N, vil JMeter opprette en tråd hvert T / N sekund.

De fleste parametrene til en trådgruppe er selvforklarende, men oppstartsperioden er litt rar, siden riktig antall ikke alltid er åpenbart. For det første bør ikke oppstartsperioden være null hvis du har et stort antall tråder. I begynnelsen av en belastningstest, hvis oppstartsperioden er null, vil JMeter opprette alle trådene på en gang og sende ut forespørsler umiddelbart, og dermed potensielt mette serveren og, enda viktigere, å bedra lasten. Det vil si at serveren kan bli overbelastet, ikke fordi den gjennomsnittlige trefffrekvensen er høy, men fordi du sender alle trådens første forespørsler samtidig, og forårsaker en uvanlig innledende topp hitfrekvens. Du kan se denne effekten med en JMeter Aggregate Report-lytter.

Siden denne avviket ikke er ønskelig, er derfor tommelfingerregelen for å bestemme en rimelig oppstartsperiode å holde den innledende trefffrekvensen nær gjennomsnittlig trefffrekvens. Selvfølgelig kan det hende du må kjøre testplanen en gang før du oppdager et rimelig antall.

På samme måte er en stor oppstartperiode heller ikke hensiktsmessig, siden toppbelastningen kan bli undervurdert. Det vil si at noen av trådene ikke engang har startet, mens noen innledende tråder allerede er avsluttet.

Så hvordan bekrefter du at oppstartsperioden verken er for liten eller for stor? Gjett først den gjennomsnittlige trefffrekvensen, og beregn deretter den innledende oppstartsperioden ved å dele antall tråder med den gjettede trefffrekvensen. For eksempel, hvis antall tråder er 100, og den estimerte trefffrekvensen er 10 treff per sekund, er den estimerte ideelle oppstartsperioden 100/10 = 10 sekunder. Hvordan kommer du opp med en estimert trefffrekvens? Det er ingen enkel måte. Du må bare kjøre testskriptet en gang først.

For det andre, legg til en totalrapportlytter, vist i figur 2, til testplanen; den inneholder gjennomsnittlig trefffrekvens for hver enkelt forespørsel (JMeter-samplere). Trefffrekvensen til den første sampleren (f.eks. En HTTP-forespørsel) er nært knyttet til oppstartsperioden og antall tråder. Juster oppstartsperioden slik at trefffrekvensen til testplanens første prøvetaker er nær gjennomsnittlig trefffrekvens for alle andre prøvetakere.

For det tredje kontrollerer du i JMeter-loggen (som ligger i JMeter_Home_Directory / bin) at den første tråden som avsluttes, faktisk avsluttes etter at den siste tråden starter. Tidsforskjellen mellom de to skal være så langt fra hverandre som mulig.

Oppsummert er bestemmelsen av en god oppstartstid styrt av følgende to regler:

• Den første samplerens trefffrekvens bør være nær gjennomsnittlig trefffrekvens for andre samplere, og dermed forhindre en liten oppstartperiode
• Den første tråden som er ferdig, avsluttes faktisk etter at den siste tråden starter, helst så langt fra hverandre som mulig, og forhindrer dermed en stor oppstartperiode

Noen ganger kommer de to reglene i konflikt med hverandre. Det vil si at du ganske enkelt ikke finner en passende oppstartsperiode som overholder begge reglene. En triviell testplan forårsaker vanligvis dette problemet, fordi du i en slik plan mangler nok samplere for hver tråd. dermed er testplanen for kort, og en tråd avslutter raskt sitt arbeid.

Brukerens tid, tidtaker og proxy-server

Et viktig element å vurdere i en lastetest er tenk tid, eller pause mellom påfølgende forespørsler. Ulike omstendigheter forårsaker forsinkelsen: brukeren trenger tid til å lese innholdet, eller for å fylle ut et skjema, eller for å søke etter riktig lenke. Unnlatelse av å vurdere riktig tenker tid ofte fører til alvorlig partisk testresultater. For eksempel vil estimert skalerbarhet, dvs. maksimal belastning (samtidige brukere) som systemet kan opprettholde, virke lav.

JMeter gir et sett med timerelementer for å modellere tenketiden, men det gjenstår fortsatt et spørsmål: hvordan bestemmer du en passende tenketid? Heldigvis tilbyr JMeter et godt svar: JMeter HTTP Proxy Server-elementet.

Proxy-serveren registrerer handlingene dine mens du surfer på et webapplikasjon med en vanlig nettleser (for eksempel FireFox eller Internet Explorer). I tillegg lager JMeter en testplan når du registrerer handlingene dine. Denne funksjonen er ekstremt praktisk for flere formål:

• Du trenger ikke å opprette en HTTP-forespørsel manuelt, spesielt de kjedelige skjemaparametrene. (Det kan imidlertid hende at ikke-engelske parametere ikke fungerer som de skal.) JMeter registrerer alt i de automatisk genererte forespørslene, inkludert skjulte felt.
• I den genererte testplanen inkluderer JMeter alle nettlesergenererte HTTP-overskrifter for deg, for eksempel 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 lage timere etter eget valg, der forsinkelsestiden er satt i henhold til den faktiske forsinkelsen i opptaksperioden.

La oss se hvordan du konfigurerer JMeter med innspillingsfunksjonen. Høyreklikk på WorkBench-elementet i JMeter-konsollen og legg til elementet HTTP-proxyserver. Merk at du høyreklikker på WorkBench-elementet, ikke på Testplan-elementet, fordi konfigurasjonen her er for opptak, ikke for en kjørbar testplan. HTTP-proxyserverelementets formål er at du konfigurerer nettleserens proxy-server slik at alle forespørsler går gjennom JMeter.

Som illustrert i figur 3, må flere felt konfigureres for HTTP-proxyserverelementet:

• Havn: Lytteporten som brukes av proxy-serveren.
• Målkontroller: Kontrolleren der proxyen lagrer de genererte prøvene. Som standard vil JMeter se etter en opptakskontroll i gjeldende testplan og lagre prøvene der. Alternativt kan du velge hvilket som helst kontrollerelement som er oppført i menyen. Vanligvis er standard OK.
• Gruppering: Hvordan du vil gruppere de genererte elementene i testplanen. Flere alternativer er tilgjengelige, og den mest fornuftige er antagelig "Lagre bare første sampler i hver gruppe", ellers blir også URL-er innebygd på en side som for bilder og JavaScripts registrert. Det kan imidlertid være lurt å prøve standardalternativet "Ikke grupper prøver" for å finne ut hva JMeter oppretter for deg i testplanen.
• Mønstre å inkludere og Mønstre som skal ekskluderes: Hjelper deg med å filtrere ut uønskede forespørsler.

Når du klikker på Start-knappen, starter proxy-serveren og begynner å registrere HTTP-forespørslene den mottar. Før du klikker Start, må du selvfølgelig konfigurere nettleserens proxy-serverinnstilling.

Du kan legge til en tidtaker som barn av HTTP Proxy Server-elementet, som vil instruere JMeter om automatisk å legge til en tidtaker som barn av HTTP-forespørselen den genererer. JMeter lagrer automatisk den faktiske tidsforsinkelsen til en JMeter-variabel kalt T, så hvis du legger til en Gauss random timer i HTTP Proxy Server-elementet, bør du skrive $ {T} i feltet Constant Delay, som vist i figur 4. Dette er en annen praktisk funksjon som sparer deg mye tid.

Merk at en tidtaker fører til at de berørte samplerne blir forsinket. Det vil si at de berørte prøvetakingsforespørslene ikke sendes før den angitte forsinkelsestiden har gått siden sist mottatte svar. Derfor bør du fjerne den første samplerens genererte timer manuelt, siden den første sampleren vanligvis ikke trenger en.

Før du starter HTTP-proxy-serveren, bør du legge til en trådgruppe i testplanen, og deretter legge til en opptakskontroll i trådgruppen, der de genererte elementene vil bli lagret. Ellers vil disse elementene bli lagt til WorkBench direkte. I tillegg er det viktig å legge til et HTTP-forespørsel standardelement (et konfigurasjonselement) til opptakskontrolleren, slik at JMeter vil la de feltene som er spesifisert av standardinnstillingene for HTTP-forespørsel være tomme.

Stopp HTTP-proxy-serveren etter opptaket; høyreklikk på Recording Controller-elementet for å lagre de innspilte elementene i en egen fil, slik at du kan hente dem senere. Ikke glem å gjenoppta nettleserens innstilling for proxy-server.

Spesifiser svartidskrav og valider testresultatene

Selv om det ikke er direkte relatert til JMeter, er det to viktige oppgaver for belastningstesting å spesifisere krav til responstid og validering av testresultater, med JMeter som broen som forbinder dem.

I sammenheng med webapplikasjoner refererer responstid til tiden som er gått fra innlevering av forespørsel og mottakelse av den resulterende HTML-en. Teknisk sett bør responstid inneholde tid for nettleseren til å gjengi HTML-siden, men en nettleser viser vanligvis siden stykke for stykke, noe som gjør den opplevde responstiden mindre. I tillegg beregner et lastetestverktøy vanligvis responstiden uten å vurdere gjengivelsestiden. Derfor, for praktiske formål med ytelsestesting, vedtar vi definisjonen beskrevet ovenfor. Hvis du er i tvil, legg til en konstant til den målte responstiden, si 0,5 sekunder.

Det er et sett med kjente regler for å bestemme responstidskriterier:

• Brukerne merker ikke en forsinkelse på mindre enn 0,1 sekund
• En forsinkelse på mindre enn 1 sekund forstyrrer ikke brukerens tankegang, men noen forsinkelser blir lagt merke til
• Brukere vil fortsatt vente på svaret hvis det blir forsinket med mindre enn 10 sekunder
• Etter 10 sekunder mister brukerne fokus og begynner å gjøre noe annet

Disse terskelene er velkjente og vil ikke endres siden de er direkte relatert til menneskers kognitive egenskaper. Selv om du bør stille dine responstidskrav i samsvar med disse reglene, bør du også justere dem for ditt spesifikke program. For eksempel overholder Amazon.coms hjemmeside reglene ovenfor, men fordi den foretrekker et mer stilistisk utseende, ofrer den litt responstid.

Ved første øyekast ser det ut til å være to forskjellige måter å spesifisere krav til svartid:

• Gjennomsnittlig responstid
• Absolutt responstid det vil si at responstidene for alle svarene må være under terskelen

Å spesifisere gjennomsnittlige svartidskrav er grei, men det faktum at dette kravet ikke tar hensyn til datavariasjon er urovekkende. Hva om responstiden på 20 prosent av prøvene er mer enn tre ganger gjennomsnittet? Merk at JMeter beregner gjennomsnittlig responstid og standardavvik for deg i grafresultatlytteren.

På den annen side er det absolutte responstidskravet ganske strengt og statistisk ikke praktisk. Hva om bare 0,5 prosent av prøvene ikke klarte å teste testene? Igjen, dette er relatert til utvalgsvariasjon. Heldigvis vurderer en streng statistisk metode utvalgsvariasjoner: konfidensintervallanalysen.

La oss se gjennom grunnleggende statistikk før vi går videre.

Den sentrale grensesetningen

Den sentrale grensesetningen sier at hvis populasjonsfordelingen har gjennomsnittet μ og standardavviket σ, så for tilstrekkelig stort n (> 30), er samplingsfordelingen av prøvetakingsmiddel gjennomsnittet normal, med gjennomsnittet μ_mener = μ og standardavvik σ_mener = σ / √n.

Noter det fordelingen av prøvetakingsmiddel er normalt. Distribusjonen av selve prøvetakingen er ikke nødvendigvis normal. Det vil si at hvis du kjører testskriptet mange ganger, vil fordelingen av de resulterende gjennomsnittlige responstidene være normal.

Figur 5 og 6 nedenfor viser to normale fordelinger. I vår sammenheng er den horisontale aksen samplingsgjennomsnittet for responstid, forskjøvet slik at populasjonsgjennomsnittet er ved opprinnelsen. Figur 5 viser at prøvetakingsmidlene er 90 prosent av tiden innenfor intervallet ± Zσ, hvor Z = 1.645 og σ er standardavviket. Figur 6 viser tilfellet 99 prosent, hvor Z = 2,576. For en gitt sannsynlighet, si 90 prosent, kan vi slå opp den tilsvarende Z-verdien med en normal kurve og omvendt.