JMeter je priljubljeno odprtokodno orodje za preskušanje obremenitve z veliko uporabnimi funkcijami modeliranja, kot so elementi niti, časovnik in vzorčevalni elementi HTTP. Ta članek dopolnjuje uporabniški priročnik JMeter in vsebuje smernice za uporabo nekaterih elementov modeliranja JMeter za razvoj skripta za preizkus kakovosti.
Ta članek obravnava tudi pomembno vprašanje v širšem kontekstu: natančno določanje zahtev odzivnega časa in potrjevanje rezultatov preskusov. Natančneje, uporabljena je stroga statistična metoda, analiza intervala zaupanja.
Upoštevajte, da domnevam, da bralci poznajo osnove JMeter-ja. Primeri tega članka temeljijo na JMeter 2.0.3.
Določite obdobje povečevanja skupine niti
Prva sestavina vašega skripta JMeter je skupina niti, zato jo najprej preglejmo. Kot je prikazano na sliki 1, element skupine niti vsebuje naslednje parametre:
- Število niti.
- Obdobje povečanja.
- Število izvedb preizkusa.
- Ob zagonu, ali se test zažene takoj ali počaka do predvidenega časa. Če je slednje, mora element skupine niti vključevati tudi začetni in končni čas.
Vsaka nit izvede preskusni načrt neodvisno od drugih niti. Zato se skupina niti uporablja za modeliranje sočasnih uporabnikov. Če odjemalskemu računalniku, v katerem je nameščen JMeter, primanjkuje dovolj računalniške moči za modeliranje velike obremenitve, vam JMeterjeva funkcija distribucijskega testiranja omogoča nadzor nad več oddaljenimi motorji JMeter z ene same konzole JMeter.
Obdobje rasti pove JMetru, koliko časa je ustvaril skupno število niti. Privzeta vrednost je 0. Če obdobje podaljšanja ni določeno, tj. Obdobje podaljšanja je nič, bo JMeter takoj ustvaril vse niti. Če je obdobje povečanja nastavljeno na T sekund in je skupno število niti N, bo JMeter ustvaril nit vsakih T / N sekund.
Večina parametrov skupine niti je samoumevnih, vendar je obdobje rasti nekoliko čudno, saj ustrezna številka ni vedno očitna. Najprej obdobje povečevanja ne sme biti nič, če imate veliko število niti. Na začetku preskusa obremenitve, če je obdobje povečanja nič, bo JMeter ustvaril vse niti hkrati in takoj poslal zahteve, s čimer bi lahko nasičil strežnik in, kar je še pomembneje, zavajajoče povečal obremenitev. To pomeni, da se strežnik lahko preobremeni, ne zato, ker je povprečna hitrost zadetkov visoka, temveč zato, ker hkrati pošljete vse zahteve vseh niti, kar povzroči nenavadno začetno največjo hitrost zadetkov. Ta učinek si lahko ogledate s poslušalcem zbirnega poročila JMeter.
Ker ta anomalija ni zaželena, je zato osnovno pravilo za določitev razumnega obdobja povečanja začetna stopnja zadetkov blizu povprečne stopnje zadetkov. Seveda boste morda morali enkrat preizkusiti načrt preizkusa, preden odkrijete primerno število.
Iz istega razloga tudi veliko podaljšanje obdobja ni primerno, saj je največja obremenitev lahko podcenjena. To pomeni, da se nekatere niti morda niti niso začele, medtem ko so nekatere začetne niti že zaključene.
Torej, kako preverite, ali obdobje povečevanja ni premajhno niti preveliko? Najprej uganite povprečno stopnjo zadetkov in nato izračunajte začetno obdobje rasti, tako da število niti delite s predvidevano stopnjo zadetkov. Če je na primer število niti 100 in ocenjena hitrost zadetkov 10 zadetkov na sekundo, je ocenjeno idealno obdobje povečanja 100/10 = 10 sekund. Kako najti ocenjeno stopnjo zadetkov? Enostavne poti ni. Preprosto morate enkrat zagnati testni skript.
Drugič, v načrt preskusa dodajte poslušalca zbirnega poročila, prikazanega na sliki 2; vsebuje povprečno stopnjo zadetkov za vsako posamezno zahtevo (vzorčevalniki JMeter). Stopnja zadetkov prvega vzorčevalnika (npr. Zahteva HTTP) je tesno povezana z obdobjem povečevanja in številom niti. Prilagodite obdobje povečevanja, tako da bo stopnja zadetkov prvega vzorčevalnika načrta preskusa blizu povprečni stopnji zadetkov vseh drugih vzorčevalnikov.
Tretjič, v dnevniku JMeter (ki se nahaja v JMeter_Home_Directory / bin) preverite, ali se prva nit, ki se konča, res konča po zagonu zadnje niti. Časovna razlika med njima mora biti čim bolj narazen.
Če povzamemo, določitev dobrega časa pospeševanja urejajo naslednja pravila:
- Stopnja zadetkov prvega vzorčevalnika mora biti blizu povprečni stopnji zadetkov drugih vzorčevalcev, s čimer se prepreči majhno obdobje rasti
- Prva nit, ki se konča, se res konča po zagonu zadnje niti, po možnosti čim bolj narazen, s čimer se prepreči veliko obdobje povečevanja
Včasih sta si pravila v nasprotju. To pomeni, da preprosto ne najdete ustreznega obdobja za povečanje, ki bi ustrezalo obema praviloma. Trivialni testni načrt običajno povzroči to težavo, ker vam v takšnem načrtu primanjkuje dovolj vzorčevalcev za vsako nit; tako je testni načrt prekratek in nit hitro zaključi svoje delo.
Uporabnik misli čas, časovnik in proxy strežnik
Pomemben element, ki ga je treba upoštevati pri preskusu obremenitve, je pomisli čas, ali pavza med zaporednimi zahtevami. Zamude povzročajo različne okoliščine: uporabnik potrebuje čas, da prebere vsebino, izpolni obrazec ali poišče pravo povezavo. Neupoštevanje časa razmišljanja pogosto privede do resno pristranskih rezultatov testov. Na primer, ocenjena razširljivost, tj. Največja obremenitev (sočasni uporabniki), ki jo lahko sistem vzdržuje, se zdi nizka.
JMeter ponuja nabor elementov časovnika za modeliranje časa razmišljanja, vendar še vedno ostaja vprašanje: kako določiti primeren čas razmišljanja? Na srečo JMeter ponuja dober odgovor: element JMeter HTTP Proxy Server.
Proxy strežnik beleži vaša dejanja med brskanjem po spletni aplikaciji z običajnim brskalnikom (na primer FireFox ali Internet Explorer). Poleg tega JMeter pri snemanju vaših dejanj ustvari testni načrt. Ta funkcija je izjemno priročna za več namenov:
- Zahteve HTTP vam ni treba ustvariti ročno, še posebej tistih dolgočasnih parametrov obrazca. (Vendar neangleški parametri morda ne bodo delovali pravilno.) JMeter bo zapisal vse v samodejno ustvarjene zahteve, vključno s skritimi polji.
- V ustvarjeni preskusni načrt JMeter vključuje vse glave HTTP, ki jih ustvari brskalnik, na primer User-Agent (npr. Mozilla / 4.0) ali AcceptLanguage (npr. Zh-tw, en-us; q = 0,7, zh- cn; q = 0,3).
- JMeter lahko ustvari časovnike po vaši izbiri, kjer se čas zakasnitve nastavi glede na dejansko zakasnitev med snemanjem.
Poglejmo, kako nastaviti JMeter s funkcijo snemanja. V konzoli JMeter z desno miškino tipko kliknite element WorkBench in dodajte element HTTP Proxy Server. Upoštevajte, da z desno miškino tipko kliknete element WorkBench in ne element Test Plan, ker je tukaj konfiguracija namenjena snemanju in ne izvedljivemu preskusnemu načrtu. Namen elementa HTTP Proxy Server je, da konfigurirate proxy strežnik brskalnika, tako da vse zahteve gredo skozi JMeter.
Kot je prikazano na sliki 3, je treba za element HTTP Proxy Server konfigurirati več polj:
- Pristanišče: Vrata za poslušanje, ki jih uporablja proxy strežnik.
- Ciljni krmilnik: Krmilnik, kjer proxy shrani generirane vzorce. JMeter privzeto poišče krmilnik snemanja v trenutnem preskusnem načrtu in tam shrani vzorce. Lahko pa izberete kateri koli element krmilnika, naveden v meniju. Običajno je privzeto v redu.
- Razvrščanje v skupine: Kako želite združiti ustvarjene elemente v preskusnem načrtu. Na voljo je več možnosti, najbolj smiselna pa je verjetno »Shrani 1. vzorčevalnik iz vsake skupine«, sicer bodo zabeleženi tudi URL-ji, vdelani na strani, kot so tisti za slike in JavaScripts. Vendar boste morda želeli preizkusiti privzeto možnost »Ne združuj vzorcev«, če želite izvedeti, kaj natančno JMeter ustvari za vas v preskusnem načrtu.
- Vzorci za vključitev in Vzorci za izključitev: Pomagajo vam filtrirati nekatere neželene zahteve.
Ko kliknete gumb Start, se proxy strežnik zažene in začne snemati prejete zahteve HTTP. Preden kliknete Start, morate v brskalniku konfigurirati nastavitve proxy strežnika.
Časovnik lahko dodate kot podrejeni element HTTP Proxy Server, ki bo naročil JMeterju, naj samodejno doda časovnik kot podrejeni zahtevi HTTP, ki jo ustvari. JMeter samodejno shrani dejansko časovno zakasnitev v spremenljivko JMeter, ki se imenuje T, torej, če elementu HTTP Proxy Server dodate Gaussov naključni časovnik, vnesite $ {T} v polju Constant Delay, kot je prikazano na sliki 4. To je še ena priročna funkcija, ki vam prihrani veliko časa.
Upoštevajte, da časovnik povzroči zakasnitev prizadetih vzorčevalnikov. To pomeni, da prizadete zahteve za vzorčenje niso poslane, preden poteče določeni čas zakasnitve od zadnjega prejetega odgovora. Zato morate ročno odstraniti ustvarjeni časovnik prvega vzorčevalnika, saj ga prvi vzorčevalnik običajno ne potrebuje.
Preden zaženete strežnik proxy HTTP, dodajte načrt niti v testni načrt, nato pa v skupino niti dodajte snemalni krmilnik, kjer bodo ustvarjeni elementi shranjeni. V nasprotnem primeru bodo ti elementi dodani v WorkBench neposredno. Poleg tega je pomembno, da v krmilnik snemanja dodate element privzetih zahtev HTTP (element konfiguracije), tako da bo JMeter pustil prazna polja, določena s privzetimi zahtevami HTTP.
Po snemanju zaustavite strežnik proxy HTTP; z desno miškino tipko kliknite element Recording Controller, da shranite posnete elemente v ločeno datoteko, da jih boste lahko pozneje pridobili. Ne pozabite nadaljevati nastavitve proxy strežnika v brskalniku.
Navedite zahteve glede odzivnega časa in potrdite rezultate preskusov
Navedba zahtev za odzivni čas in potrjevanje rezultatov preskusov sicer ni neposredno povezana z JMeter, vendar sta ključni nalogi za preskušanje obremenitve, pri čemer je JMeter most, ki ju povezuje.
V kontekstu spletnih aplikacij se odzivni čas nanaša na čas, ki je pretekel med oddajo zahteve in prejemom nastalega HTML-ja. Tehnično bi moral odzivni čas vključevati čas, ko brskalnik upodobi stran HTML, vendar brskalnik stran običajno prikaže po delih, tako da zaznani odzivni čas postane manjši. Poleg tega orodje za preizkus obremenitve običajno izračuna odzivni čas, ne da bi upošteval čas upodabljanja. Zato za praktične namene preizkušanja zmogljivosti sprejemamo zgoraj opisano definicijo. Če ste v dvomih, izmerjenemu odzivnemu času dodajte konstanto, recimo 0,5 sekunde.
Obstaja niz dobro znanih pravil za določanje meril odzivnega časa:
- Uporabniki ne opazijo zamude, krajše od 0,1 sekunde
- Zakasnitev, krajša od 1 sekunde, ne prekine uporabnikovega miselnega toka, opazimo pa nekaj zamude
- Uporabniki bodo še vedno čakali na odgovor, če bo zamudo za manj kot 10 sekund
- Po 10 sekundah uporabniki izgubijo fokus in začnejo početi kaj drugega
Ti pragovi so dobro znani in se ne bodo spremenili, saj so neposredno povezani s kognitivnimi značilnostmi ljudi. Čeprav bi morali zahteve za odzivni čas nastaviti v skladu s temi pravili, jih prilagodite tudi svoji aplikaciji. Domača stran Amazon.com na primer spoštuje zgornja pravila, a ker ima raje bolj stilski videz, žrtvuje malo odzivnega časa.
Na prvi pogled se zdi, da je mogoče na dva načina določiti zahteve glede odzivnega časa:
- Povprečni odzivni čas
- Absolutni odzivni čas; to pomeni, da morajo biti odzivni časi vseh odzivov pod pragom
Določanje povprečnih zahtev za odzivni čas je enostavno, vendar dejstvo, da ta zahteva ne upošteva sprememb podatkov, je moteče. Kaj pa, če je odzivni čas 20 odstotkov vzorcev več kot trikrat večji od povprečja? Upoštevajte, da JMeter izračuna vaš povprečni odzivni čas in standardni odklon v poslušalcu Graph Results.
Po drugi strani pa je zahteva po absolutnem odzivnem času precej stroga in statistično nepraktična. Kaj pa, če le 0,5 odstotka vzorcev ni uspešno prestalo testov? Še enkrat, to je povezano z variacijami vzorčenja. Na srečo stroga statistična metoda upošteva spremembe vzorčenja: analiza intervala zaupanja.
Pred nadaljevanjem si oglejmo osnovne statistike.
Izrek o osrednji meji
Izrek o osrednji meji pravi, da če ima porazdelitev populacije povprečje μ in standardni odklon σ, potem je za dovolj velike n (> 30) porazdelitev vzorčenja srednje vrednosti vzorčenja približno normalna, s povprečno μpomeni = μ in standardni odklon σpomeni = σ / √n.
Upoštevajte to porazdelitev srednje vrednosti vzorčenja je normalno. Sama porazdelitev vzorčenja ni nujno normalna. Se pravi, če preizkusni skript zaženete večkrat, bo porazdelitev nastalih povprečnih odzivnih časov normalna.
Sliki 5 in 6 spodaj prikazujeta dve normalni porazdelitvi. V našem kontekstu je vodoravna os srednja vrednost vzorčenja odzivnega časa, premaknjena tako, da je povprečna populacija v izvoru. Slika 5 kaže, da so sredstva za vzorčenje v 90 odstotkih v intervalu ± Zσ, kjer je Z = 1,645 in σ standardni odklon. Slika 6 prikazuje 99-odstotni primer, kjer je Z = 2,576. Za določeno verjetnost, recimo 90 odstotkov, lahko poiščemo ustrezno vrednost Z z normalno krivuljo in obratno.
