JMeter-vinkkejä

JMeter on suosittu avoimen lähdekoodin työkalu kuormitustestaukseen, ja siinä on monia hyödyllisiä mallinnusominaisuuksia, kuten ketjuryhmä, ajastin ja HTTP-näytteistyselementit. Tämä artikkeli täydentää JMeter-käyttöohjetta ja tarjoaa ohjeita joidenkin JMeter-mallinnuselementtien käyttämiseen laatutestiohjelman kehittämiseen.

Tässä artikkelissa käsitellään myös tärkeää asiaa laajemmassa kontekstissa: tarkkojen vasteaikavaatimusten määrittäminen ja testitulosten vahvistaminen. Erityisesti käytetään tiukkaa tilastollista menetelmää, luottamusvälianalyysiä.

Huomaa, että oletan lukijoiden tuntevan JMeterin perusteet. Tämän artikkelin esimerkit perustuvat JMeter 2.0.3: een.

Määritä ketjuryhmän siirtymäaika

JMeter-komentosarjan ensimmäinen ainesosa on ketjuryhmä, joten tarkistetaan se ensin. Kuten kuvassa 1 on esitetty, ketjuryhmäelementti sisältää seuraavat parametrit:

• Lankojen määrä.
• Ramp-up-aika.
• Testin suorittamiskertojen määrä.
• Kun testi aloitetaan, suoritetaanko testi välittömästi vai odotetaanko aikataulun mukaista aikaa. Jos tämä on viimeksi mainittu, ketjuryhmä-elementin on sisällettävä myös aloitus- ja lopetusajat.

Jokainen lanka suorittaa testisuunnitelman muista säikeistä riippumatta. Siksi ketjuryhmää käytetään samanaikaisten käyttäjien mallintamiseen. Jos JMeteria käyttävällä asiakaskoneella ei ole tarpeeksi laskentatehoa raskaan kuormituksen mallintamiseen, JMeterin jakelutestausominaisuuden avulla voit hallita useita JMeter-etämoottoreita yhdestä JMeter-konsolista.

Ramp-up-jakso kertoo JMeterille kuinka monta kertaa ketjut luodaan. Oletusarvo on 0. Jos käynnistysjakso jätetään määrittelemättömäksi, ts. Käynnistysjakso on nolla, JMeter luo kaikki ketjut välittömästi. Jos käynnistysjaksoksi on asetettu T sekuntia ja ketjujen kokonaismäärä on N, JMeter luo langan joka T / N sekunti.

Suurin osa ketjuryhmän parametreista on itsestään selviä, mutta ylösajo on hieman outo, koska sopiva numero ei ole aina ilmeinen. Ensinnäkin, käynnistysjakson ei pitäisi olla nolla, jos sinulla on suuri määrä ketjuja. Kuormitustestin alussa, jos ylösajoaika on nolla, JMeter luo kaikki ketjut kerralla ja lähettää pyynnöt välittömästi, mikä kyllästää palvelinta ja mikä vielä tärkeämpää, lisää pettää kuormaa. Toisin sanoen, palvelin saattaa ylikuormittua, ei siksi, että keskimääräinen osumisprosentti on korkea, vaan siksi, että lähetät kaikkien ketjujen ensimmäiset pyynnöt samanaikaisesti aiheuttaen epätavallisen alun huippuosumien määrän. Voit nähdä tämän vaikutuksen JMeter-aggregaattiraportin kuuntelijan kanssa.

Koska tämä poikkeama ei ole toivottava, nyrkkisääntönä kohtuullisen ylösajan määrittämiseksi on pitää alkuperäinen osumisnopeus lähellä keskimääräistä osumisastetta. Tietenkin sinun on ehkä suoritettava testisuunnitelma kerran, ennen kuin löydät kohtuullisen määrän.

Samalla tavoin suuri nousuaika ei myöskään ole sopiva, koska huippukuormitusta voidaan aliarvioida. Toisin sanoen jotkut säikeet eivät ehkä ole edes alkaneet, kun taas jotkut alkuperäiset säikeet ovat jo päättyneet.

Joten miten varmistat, että ylösajo ei ole liian pieni eikä liian suuri? Arvaa ensin keskimääräinen osumisnopeus ja laske sitten alkuperäinen nousuaika jakamalla säikeiden lukumäärä arvatulla osumisnopeudella. Esimerkiksi, jos säikeiden lukumäärä on 100 ja arvioitu osumisnopeus on 10 osumaa sekunnissa, arvioitu ihanteellinen ylösajoaika on 100/10 = 10 sekuntia. Kuinka saat aikaan arvioidun osumaprosentin? Ei ole helppoa tapaa. Sinun on vain suoritettava testiskripti kerran kerran.

Lisää toiseksi koesuunnitelmaan kuvaruudussa 2 esitetty aggregaattiraportin kuuntelija; se sisältää kunkin yksittäisen pyynnön keskimääräisen osumisnopeuden (JMeter-näytteenottajat). Ensimmäisen näytteenottimen osumaprosentti (esim. HTTP-pyyntö) liittyy läheisesti käynnistysjaksoon ja ketjujen määrään. Säädä käynnistysjakso siten, että testisuunnitelman ensimmäisen näytteenottimen osumisnopeus on lähellä kaikkien muiden näytteistimien keskimääräistä osumisnopeutta.

Kolmanneksi, tarkista JMeter-lokista (sijaitsee JMeter_Home_Directory / bin), että ensimmäinen päättyvä ketju todella loppuu viimeisen säikeen alkamisen jälkeen. Kahden välisen aikaeron tulisi olla mahdollisimman kaukana toisistaan.

Yhteenvetona voidaan todeta, että hyvän käynnistysajan määrittämistä säätelevät seuraavat kaksi sääntöä:

• Ensimmäisen näytteenottajan osumisnopeuden tulisi olla lähellä muiden näytteenottajien keskimääräistä osumisnopeutta, mikä estää pienen käynnistysjakson
• Ensimmäinen päättyvä lanka päättyy todellakin viimeisen langan alkaessa, mieluiten mahdollisimman kauas toisistaan, mikä estää suuren ylösajon

Joskus nämä kaksi sääntöä ovat ristiriidassa keskenään. Eli et yksinkertaisesti löydä sopivaa nousuaikaa, joka läpäisi molemmat säännöt. Triviaali testisuunnitelma aiheuttaa yleensä tämän ongelman, koska tällaisessa suunnitelmassa sinulla ei ole tarpeeksi näytteitä jokaiselle langalle; siten testisuunnitelma on liian lyhyt, ja lanka saa työnsä nopeasti päätökseen.

Käyttäjä ajattelee aikaa, ajastinta ja välityspalvelinta

Tärkeä tekijä, joka on otettava huomioon kuormitustestissä, on ajatella aikaa, tai tauko peräkkäisten pyyntöjen välillä. Eri olosuhteet aiheuttavat viiveen: käyttäjä tarvitsee aikaa sisällön lukemiseen, lomakkeen täyttämiseen tai oikean linkin etsimiseen. Ajatusajan huomioimatta jättäminen johtaa usein vakavasti puolueellisiin testituloksiin. Esimerkiksi arvioitu skaalautuvuus, ts. Järjestelmän suurin mahdollinen kuormitus (samanaikaiset käyttäjät), näyttää alhaiselta.

JMeter tarjoaa joukon ajastinelementtejä ajatusajan mallintamiseksi, mutta kysymys on edelleen jäljellä: kuinka määrität sopivan ajatusajan? Onneksi JMeter tarjoaa hyvän vastauksen: JMeter HTTP Proxy Server -elementin.

Välityspalvelin tallentaa toiminnot, kun selaat verkkosovellusta tavallisella selaimella (kuten Firefox tai Internet Explorer). Lisäksi JMeter luo testisuunnitelman tallennettaessa toimintojasi. Tämä ominaisuus on erittäin kätevä useisiin tarkoituksiin:

• Sinun ei tarvitse luoda HTTP-pyyntöä manuaalisesti, etenkään niitä tylsiä lomakeparametreja. (Muut kuin englanninkieliset parametrit eivät välttämättä toimi oikein.) JMeter tallentaa kaiken automaattisesti luotuihin pyyntöihin, myös piilotetut kentät.
• Luodussa testisuunnitelmassa JMeter sisältää kaikki selaimen luomat HTTP-otsikot, kuten User-Agent (esim. Mozilla / 4.0) tai AcceptLanguage (esim. Zh-tw, fi; q = 0,7, zh- cn; q = 0,3).
• JMeter voi luoda valitsemiasi ajastimia, joissa viiveaika asetetaan tallennusvaiheen todellisen viiveen mukaan.

Katsotaanpa, miten JMeter määritetään tallennusominaisuudella. Napsauta hiiren kakkospainikkeella JMeter-konsolissa WorkBench-elementtiä ja lisää HTTP-välityspalvelin-elementti. Huomaa, että napsautat hiiren kakkospainikkeella WorkBench-elementtiä, ei Test Plan -elementtiä, koska tässä olevat määritykset on tarkoitettu tallennusta varten, ei suoritettavaa testisuunnitelmaa varten. HTTP-välityspalvelin-elementin tarkoituksena on määrittää selaimen välityspalvelin, jotta kaikki pyynnöt menevät JMeterin kautta.

Kuten kuvassa 3 on esitetty, HTTP-välityspalvelin-elementille on määritettävä useita kenttiä:

• Satama: Välityspalvelimen käyttämä kuunteluportti.
• Kohdeohjain: Ohjain, johon välityspalvelin tallentaa generoidut näytteet. Oletuksena JMeter etsii tallennusohjainta nykyisestä testisuunnitelmasta ja tallentaa näytteet sinne. Vaihtoehtoisesti voit valita minkä tahansa valikossa luetellun ohjainelementin. Yleensä oletus on kunnossa.
• Ryhmittely: Kuinka haluat ryhmittää luodut elementit testisuunnitelmaan. Saatavilla on useita vaihtoehtoja, ja järkevin vaihtoehto on todennäköisesti "Tallenna vain kunkin ryhmän ensimmäinen näytteenotin", muuten sivulle upotetut URL-osoitteet, kuten kuvat ja JavaScripts, tallennetaan myös. Voit kuitenkin kokeilla oletuksena "Älä ryhmittele näytteitä" -vaihtoehtoa saadaksesi selville, mitä JMeter tarkalleen luo sinulle testisuunnitelmassa.
• Sisältyvät mallit ja Poissuljettavat mallit: Auttaa suodattamaan ei-toivotut pyynnöt.

Kun napsautat Käynnistä-painiketta, välityspalvelin käynnistyy ja alkaa tallentaa vastaanotettuja HTTP-pyyntöjä. Tietenkin, ennen kuin napsautat Käynnistä, sinun on määritettävä selaimesi välityspalvelimen asetukset.

Voit lisätä ajastimen HTTP-välityspalvelin-elementin alatasona, mikä kehottaa JMeteriä lisäämään ajastimen automaattisesti luomansa HTTP-pyynnön lapsena. JMeter tallentaa todellisen aikaviiveen automaattisesti kutsutulle JMeter-muuttujalle T, joten jos lisäät Gaussin satunnainen ajastin HTTP-välityspalvelin-elementtiin, kirjoita {T} dollaria Constant Delay -kentässä kuvan 4 mukaisesti. Tämä on toinen kätevä ominaisuus, joka säästää paljon aikaa.

Huomaa, että ajastin viivästyttää kyseisiä näytteistimiä. Eli asianomaisia ​​näytteenottopyyntöjä ei lähetetä ennen kuin määritetty viiveaika on kulunut viimeisestä vastaanotetusta vastauksesta. Siksi sinun on poistettava manuaalisesti ensimmäisen näytteenottimen luoma ajastin, koska ensimmäinen näytteenotin ei yleensä tarvitse sitä.

Ennen kuin aloitat HTTP-välityspalvelimen, sinun on lisättävä ketjusryhmä testisuunnitelmaan ja lisättävä sitten ketjuryhmään tallennusohjain, johon luodut elementit tallennetaan. Muuten nämä elementit lisätään suoraan WorkBenchiin. Lisäksi on tärkeää lisätä HTTP Request Defaults -elementti (määrityselementti) tallennusohjaimeen, jotta JMeter jättää tyhjiksi HTTP-pyynnön oletusarvojen määrittelemät kentät.

Pysäytä tallennuksen jälkeen HTTP-välityspalvelin; Napsauta hiiren kakkospainikkeella Tallennusohjain-elementtiä tallentaaksesi tallennetut elementit erilliseen tiedostoon, jotta voit hakea ne myöhemmin. Älä unohda jatkaa selaimesi välityspalvelinasetuksia.

Määritä vasteajan vaatimukset ja vahvista testitulokset

Vaikka se ei liity suoraan JMeteriin, vasteaikavaatimusten määrittäminen ja testitulosten vahvistaminen ovat kaksi kriittistä tehtävää kuormitustestauksessa, ja JMeter on silta, joka yhdistää ne.

Verkkosovellusten yhteydessä vasteaika tarkoittaa aikaa, joka on kulunut pyynnön lähettämisen ja tuloksena olevan HTML: n vastaanottamisen välillä. Teknisesti vasteajan tulisi sisältää aika, jonka selain antaa HTML-sivun, mutta selain näyttää tyypillisesti sivun palalta, jolloin havaittu vasteaika on lyhyempi. Lisäksi tyypillisesti kuormitustestaustyökalu laskee vasteajan ottamatta huomioon renderointiaikaa. Siksi käytämme suorituskykytestauksen käytännön tarkoituksiin yllä kuvattua määritelmää. Jos olet epävarma, lisää vakio mitattuun vasteaikaan, esimerkiksi 0,5 sekuntia.

Vastausaikakriteerien määrittämiseksi on joukko tunnettuja sääntöjä:

• Käyttäjät eivät huomaa alle 0,1 sekunnin viivettä
• Alle 1 sekunnin viive ei keskeytä käyttäjän ajatuksia, mutta havaitaan jonkin verran viivettä
• Käyttäjät odottavat vastausta edelleen, jos vastauksen viivästyminen on alle 10 sekuntia
• 10 sekunnin kuluttua käyttäjät menettävät keskittymisensä ja alkavat tehdä jotain muuta

Nämä kynnysarvot ovat hyvin tunnettuja eivätkä muutu, koska ne liittyvät suoraan ihmisten kognitiivisiin ominaisuuksiin. Vaikka sinun pitäisi asettaa vasteaikavaatimuksesi näiden sääntöjen mukaisesti, sinun on myös mukautettava ne omaan sovellukseesi. Esimerkiksi Amazon.comin kotisivu noudattaa yllä olevia sääntöjä, mutta koska se haluaa tyylikkäämmän ilmeen, se uhraa vähän vasteaikaa.

Ensi silmäyksellä näyttää olevan kaksi erilaista tapaa määrittää vasteajan vaatimukset:

• Keskimääräinen vasteaika
• Absoluuttinen vasteaika; toisin sanoen kaikkien vastausten vasteaikojen on oltava kynnyksen alapuolella

Keskimääräisten vasteaikavaatimusten määrittäminen on yksinkertaista, mutta se, että tässä vaatimuksessa ei oteta huomioon tietojen vaihtelua, on huolestuttavaa. Entä jos 20 prosentin näytteiden vasteaika on yli kolme kertaa keskiarvo? Huomaa, että JMeter laskee keskimääräisen vasteajan sekä standardipoikkeaman sinulle Kaavio Tulokset -luettelossa.

Toisaalta absoluuttinen vasteajan vaatimus on melko tiukka eikä tilastollisesti ole käytännöllinen. Entä jos vain 0,5 prosenttia näytteistä ei läpäissyt testejä? Tämä liittyy jälleen näytteen vaihteluun. Onneksi tiukassa tilastollisessa menetelmässä otetaan huomioon otoksen vaihtelu: luottamusvälianalyysi.

Tarkastellaan perustilastot ennen kuin menemme pidemmälle.

Keskirajan lause

Keskirajalausekkeen mukaan jos populaatiojakaumalla on keskiarvo μ ja keskihajonta σ, niin riittävän suurelle n: lle (> 30) näytteenottokeskiarvon näytteenottojakauma on suunnilleen normaali, kun keskiarvo μ_tarkoittaa = μ ja keskihajonta σ_tarkoittaa = σ / √n.

Ota huomioon, että näytteenottokeskiarvon jakauma on normaalia. Itse otoksen jakautuminen ei ole välttämättä normaalia. Toisin sanoen, jos suoritat testiskriptisi monta kertaa, tuloksena olevien keskimääräisten vasteaikojen jakauma on normaalia.

Alla olevat kuvat 5 ja 6 esittävät kahta normaalijakaumaa. Kontekstissamme vaaka-akseli on vasteajan näytteenottokeskiarvo, siirretty siten, että populaatiokeskiarvo on alkuperä. Kuvio 5 osoittaa, että 90 prosenttia ajasta näytteenottovälineet ovat välillä ± Zσ, missä Z = 1,645 ja σ on keskihajonta. Kuvassa 6 on esitetty 99 prosentin tapaus, jossa Z = 2,576. Annetulle todennäköisyydelle, esimerkiksi 90 prosentille, voimme etsiä vastaavan Z-arvon normaalikäyrällä ja päinvastoin.