„JMeter“ yra populiarus apkrovos testavimo atvirojo kodo įrankis, turintis daug naudingų modeliavimo funkcijų, tokių kaip gijų grupė, laikmatis ir HTTP imties elementai. Šis straipsnis papildo „JMeter“ vartotojo vadovą ir pateikia gaires, kaip naudoti kai kuriuos „JMeter“ modeliavimo elementus kuriant kokybės testo scenarijų.
Šiame straipsnyje taip pat nagrinėjama svarbi problema platesniame kontekste: nurodomi tikslūs atsako laiko reikalavimai ir patvirtinami bandymų rezultatai. Konkrečiai, taikomas griežtas statistinis metodas - pasikliautino intervalo analizė.
Atkreipkite dėmesį, kad manau, kad skaitytojai žino „JMeter“ pagrindus. Šio straipsnio pavyzdžiai yra pagrįsti JMeter 2.0.3.
Nustatykite siūlų grupės perėjimo periodą
Pirmasis jūsų „JMeter“ scenarijaus ingredientas yra gijų grupė, todėl pirmiausia peržiūrėkime jį. Kaip parodyta 1 paveiksle, „Thread Group“ elemente yra šie parametrai:
- Siūlų skaičius.
- Perkėlimo laikotarpis.
- Testo atlikimo kartų skaičius.
- Pradėjus, nesvarbu, ar testas vykdomas iškart, ar laukiama, kol bus suplanuotas laikas. Jei pastarasis, „Thread Group“ elemente taip pat turi būti pradžios ir pabaigos laikas.
Kiekviena gija vykdo bandymo planą nepriklausomai nuo kitų gijų. Todėl, norint modeliuoti vienu metu veikiančius vartotojus, naudojama gijų grupė. Jei kliento mašinai, naudojančiai „JMeter“, trūksta pakankamai skaičiavimo pajėgumų, kad būtų galima modeliuoti didelę apkrovą, „JMeter“ paskirstomojo testavimo funkcija leidžia valdyti kelis nuotolinius „JMeter“ variklius iš vienos „JMeter“ konsolės.
Perkėlimo laikotarpis nurodo JMeteriui, kiek laiko sukuriamas bendras gijų skaičius. Numatytoji vertė yra 0. Jei paleidimo laikotarpis paliekamas nenurodytas, t.y., padidinimo laikotarpis yra lygus nuliui, „JMeter“ iškart sukurs visas gijas. Jei nustatymo laikotarpis nustatytas į T sekundes, o bendras gijų skaičius yra N, JMeter sukurs giją kas T / N sekundę.
Dauguma gijų grupės parametrų nėra aiškūs, tačiau perėjimo laikotarpis yra šiek tiek keistas, nes tinkamas skaičius ne visada akivaizdus. Viena vertus, padidinimo laikotarpis neturėtų būti lygus nuliui, jei turite daug siūlų. Apkrovos bandymo pradžioje, jei padidinimo laikotarpis yra lygus nuliui, „JMeter“ sukurs visas gijas vienu metu ir nedelsdamas išsiųs užklausas, taip potencialiai prisotindamas serverį ir, dar svarbiau, apgaulingai padidindamas apkrovą. Tai reiškia, kad serveris gali būti perkrautas ne todėl, kad vidutinis įvykių rodiklis yra aukštas, bet todėl, kad vienu metu siunčiate visas pirmąsias gijų užklausas, todėl atsiranda neįprastas pradinis didžiausio įvykio rodiklis. Šį efektą galite pamatyti naudodami „JMeter Aggregate Report“ klausytoją.
Kadangi ši anomalija nėra pageidautina, todėl norint nustatyti pagrįstą padidėjimo periodą, laikytis pirminės taisyklės yra išlaikyti pradinį pataikymo rodiklį artimą vidutiniam pataikymo rodikliui. Žinoma, jums gali tekti vieną kartą vykdyti bandymų planą, prieš atrandant pagrįstą skaičių.
Tuo pačiu principu didelis perėjimo laikotarpis taip pat nėra tinkamas, nes gali būti neįvertinta didžiausia apkrova. Tai yra, kai kurios gijos gali būti net neprasidėjusios, o kai kurios pradinės gijos jau baigtos.
Taigi, kaip patikrinti, ar perėjimo laikotarpis nėra nei per mažas, nei per didelis? Pirmiausia atspėkite vidutinį pataikymo rodiklį ir paskaičiuokite pradinį padidėjimo periodą, padalydami siūlų skaičių iš numanomo paspaudimų skaičiaus. Pvz., Jei gijų skaičius yra 100, o numatomas įvykių dažnis yra 10 įvykių per sekundę, numatomas idealus perėjimo laikotarpis yra 100/10 = 10 sekundžių. Kaip susidaryti įvertintą pataikymo rodiklį? Nėra lengvo būdo. Pirmiausia jums tereikia vieną kartą paleisti bandomąjį scenarijų.
Antra, prie bandymų plano pridėkite apibendrintų ataskaitų klausytoją, parodytą 2 paveiksle; joje nurodomas vidutinis kiekvienos atskiros užklausos įvykių dažnis („JMeter“ pavyzdžių rinkėjai). Pirmojo imtuvo įvykio dažnis (pvz., HTTP užklausa) yra glaudžiai susijęs su padidinimo periodu ir gijų skaičiumi. Sureguliuokite padidėjimo periodą taip, kad pirmojo bandymo plano mėginių ėmimo dažnis būtų artimas vidutiniam visų kitų ėminių ėmimo dažniui.
Trečia, „JMeter“ žurnale (esančiame „JMeter_Home_Directory / bin“) patikrinkite, ar pirmasis baigtas siūlas iš tikrųjų baigiamas paleidus paskutinį. Laiko skirtumas tarp jų turėtų būti kuo tolimesnis.
Apibendrinant galima teigti, kad gerą perkrovimo laiką nustato dvi šios taisyklės:
- Pirmojo mėginio atrankos dažnis turėtų būti artimas vidutiniam kitų mėginių ėmimo dažniui, taip išvengiant nedidelio perėjimo laikotarpio
- Pirmasis sriegis, kuris baigiasi, iš tikrųjų baigiasi po paskutinio sriegio pradžios, pageidautina kuo toliau vienas nuo kito, taip užkertant kelią dideliam perėjimo laikotarpiui
Kartais abi taisyklės prieštarauja viena kitai. Tai yra, jūs tiesiog negalite rasti tinkamo perėjimo laikotarpio, kuris atitiktų abi taisykles. Dažniausiai šią problemą sukelia trivialus bandymų planas, nes tokiame plane trūksta pakankamai mėginių kiekvienai gijai; taigi bandymo planas yra per trumpas, o siūlas greitai užbaigia savo darbą.
Vartotojo minties laikas, laikmatis ir tarpinis serveris
Svarbus elementas, į kurį reikia atsižvelgti atliekant apkrovos bandymą, yra galvoti laikas, arba pauzė tarp vienas po kito einančių prašymų. Vėlavimą lemia įvairios aplinkybės: vartotojui reikia laiko perskaityti turinį, užpildyti formą arba ieškoti tinkamos nuorodos. Jei tinkamai neatsižvelgiama į mąstymo laiką, dažnai gaunami labai šališki testų rezultatai. Pvz., Įvertintas mastelis, t. Y., Maksimali apkrova (tuo pačiu vartotojams), kurią sistema gali išlaikyti, pasirodys maža.
„JMeter“ pateikia laikmačio elementų rinkinį mąstymo laikui modeliuoti, tačiau vis tiek lieka klausimas: kaip nustatyti tinkamą mąstymo laiką? Laimei, „JMeter“ siūlo gerą atsakymą: „JMeter HTTP Proxy Server“ elementą.
Tarpinis serveris įrašo jūsų veiksmus, kai naršote žiniatinklio programą naudodami įprastą naršyklę (pvz., „Firefox“ ar „Internet Explorer“). Be to, „JMeter“ įrašo jūsų veiksmus, sukuria bandymų planą. Ši funkcija yra ypač patogi keliems tikslams:
- Jums nereikia rankiniu būdu kurti HTTP užklausos, ypač tų varginančių formos parametrų. (Tačiau ne angliški parametrai gali neveikti tinkamai.) „JMeter“ viską įrašys automatiškai sugeneruotose užklausose, įskaitant paslėptus laukus.
- Į sugeneruotą bandymų planą „JMeter“ įtraukia visas naršyklės sugeneruotas HTTP antraštes, pvz., „User-Agent“ (pvz., „Mozilla / 4.0“) arba „AcceptLanguage“ (pvz., Zh-tw, en-us; q = 0,7, zh- cn; q = 0,3).
- „JMeter“ gali sukurti jūsų pasirinktus laikmačius, kur uždelsimo laikas nustatomas atsižvelgiant į faktinį vėlavimą įrašymo laikotarpiu.
Pažiūrėkime, kaip sukonfigūruoti „JMeter“ su įrašymo funkcija. „JMeter“ konsolėje dešiniuoju pelės mygtuku spustelėkite „WorkBench“ elementą ir pridėkite HTTP tarpinio serverio elementą. Atminkite, kad dešiniuoju pelės mygtuku spustelėkite „WorkBench“ elementą, o ne „Test Plan“ elementą, nes čia esanti konfigūracija skirta įrašymui, o ne vykdomojo bandymo planui. Elemento „HTTP Proxy Server“ tikslas yra sukonfigūruoti naršyklės tarpinį serverį, kad visos užklausos vyktų per „JMeter“.
Kaip parodyta 3 paveiksle, HTTP tarpinio serverio elementui reikia sukonfigūruoti kelis laukus:
- Uostas: Klausymo prievadas, kurį naudoja tarpinis serveris.
- Tikslinis valdiklis: Valdiklis, kuriame tarpinis serveris saugo sugeneruotus pavyzdžius. Pagal numatytuosius nustatymus „JMeter“ ieškos įrašymo valdiklio dabartiniame bandymų plane ir ten laikys mėginius. Arba galite pasirinkti bet kurį meniu nurodytą valdiklio elementą. Paprastai numatytasis nustatymas yra gerai.
- Grupavimas: Kaip norėtumėte sugrupuoti sugeneruotus elementus bandymo plane. Galimos kelios parinktys, o protingiausia turbūt yra „Laikyti tik kiekvienos grupės pirmąjį pavyzdį“, priešingu atveju taip pat bus įrašyti URL, įterpti į puslapį, pvz., Vaizdams ir „JavaScripts“. Tačiau galbūt norėsite išbandyti numatytąją parinktį „Negrupuoti pavyzdžių“, kad sužinotumėte, ką tiksliai JMeter jums sukuria bandymo plane.
- Įtraukiami raštai ir Išskirtini modeliai: Padės filtruoti kai kurias nepageidaujamas užklausas.
Spustelėjus mygtuką Pradėti, tarpinis serveris paleidžiamas ir pradeda įrašyti gaunamas HTTP užklausas. Žinoma, prieš spustelėdami Pradėti, turite sukonfigūruoti savo naršyklės tarpinio serverio nustatymą.
Laikmatį galite pridėti kaip „HTTP“ tarpinio serverio elemento antrinį planą, kuris nurodys „JMeter“ automatiškai pridėti laikmatį kaip jos sugeneruotos HTTP užklausos antrinį. „JMeter“ automatiškai įrašo faktinį laiko atidėjimą į vadinamąjį „JMeter“ kintamąjį T, taigi, jei prie HTTP tarpinio serverio elemento pridėsite Gauso atsitiktinį laikmatį, turėtumėte įvesti {T} USD lauke „Pastovus delsimas“, kaip parodyta 4 paveiksle. Tai dar viena patogi funkcija, taupanti daug laiko.
Atkreipkite dėmesį, kad laikmatis vėluoja paveiktus mėginių ėmėjus. Tai yra, paveiktos atrankos užklausos nėra siunčiamos, kol nepraėjo nurodytas delsos laikas nuo paskutinio gauto atsakymo. Todėl turėtumėte rankiniu būdu pašalinti pirmąjį imtuvo sugeneruotą laikmatį, nes pirmajam mėginių imtuvui jo paprastai nereikia.
Prieš paleidžiant HTTP tarpinį serverį, turėtumėte pridėti gijų grupę prie bandymo plano, o tada prie gijų grupės pridėti įrašymo valdiklį, kuriame bus saugomi sugeneruoti elementai. Kitu atveju šie elementai bus tiesiogiai pridėti prie „WorkBench“. Be to, svarbu į įrašymo valdiklį įtraukti HTTP užklausos numatytųjų elementų elementą (konfigūracijos elementą), kad JMeter paliktų tuščius tuos laukus, kuriuos nurodo HTTP užklausos numatytieji nustatymai.
Po įrašymo sustabdykite HTTP tarpinį serverį; Dešiniuoju pelės mygtuku spustelėkite įrašymo valdiklio elementą, kad išsaugotumėte įrašytus elementus atskirame faile, kad galėtumėte juos vėliau gauti. Nepamirškite atnaujinti savo naršyklės tarpinio serverio nustatymo.
Nurodykite atsakymo laiko reikalavimus ir patvirtinkite bandymų rezultatus
Nors tai nėra tiesiogiai susiję su „JMeter“, atsakymo laiko reikalavimų nustatymas ir bandymų rezultatų patvirtinimas yra dvi kritinės užduotys atliekant apkrovos testavimą, o JMeter yra juos jungiantis tiltas.
Žiniatinklio programų kontekste atsakymo laikas reiškia laiką, praėjusį nuo užklausos pateikimo iki gauto HTML gavimo. Techniškai į atsakymo laiką turėtų būti įtrauktas laikas, per kurį naršyklė turi pateikti HTML puslapį, tačiau naršyklė paprastai rodo puslapį po truputį, todėl suvokiamas atsakymo laikas sutrumpėja. Be to, paprastai apkrovos bandymo įrankis apskaičiuoja atsako laiką neatsižvelgdamas į atvaizdavimo laiką. Todėl praktiniams eksploatacinių savybių tikrinimo tikslams mes taikome aukščiau aprašytą apibrėžimą. Jei abejojate, prie išmatuoto atsako laiko pridėkite konstantą, tarkime, 0,5 sekundės.
Atsakymo laiko kriterijų nustatymui yra gerai žinomų taisyklių rinkinys:
- Vartotojai nepastebi mažiau nei 0,1 sekundės vėlavimo
- Mažesnis nei 1 sekundės vėlavimas nenutraukia vartotojo minčių srauto, tačiau pastebimas tam tikras vėlavimas
- Vartotojai vis tiek lauks atsakymo, jei jis bus atidėtas mažiau nei 10 sekundžių
- Po 10 sekundžių vartotojai praranda dėmesį ir pradeda daryti ką nors kita
Šios ribos yra gerai žinomos ir nesikeis, nes jos yra tiesiogiai susijusios su žmonių pažintinėmis savybėmis. Nors turėtumėte nustatyti atsakymo laiko reikalavimus pagal šias taisykles, taip pat turėtumėte juos pritaikyti pagal savo konkrečią programą. Pvz., „Amazon.com“ pagrindiniame puslapyje laikomasi pirmiau pateiktų taisyklių, tačiau dėl to, kad ji teikia pirmenybę stilistiškesnei išvaizdai, aukojama šiek tiek atsakymo laiko.
Iš pirmo žvilgsnio atrodo, kad yra du skirtingi būdai nurodyti atsakymo laiko reikalavimus:
- Vidutinis atsakymo laikas
- Absoliutus atsako laikas; tai yra, visų atsakymų atsakymo laikas turi būti mažesnis už slenkstį
Nurodyti vidutinius atsako laiko reikalavimus yra nesudėtinga, tačiau nerimą kelia tai, kad taikant šį reikalavimą neatsižvelgiama į duomenų kitimą. Ką daryti, jei 20 procentų mėginių atsako laikas yra daugiau nei tris kartus didesnis už vidurkį? Atkreipkite dėmesį, kad „JMeter“ apskaičiuoja vidutinį atsako laiką ir standartinį nuokrypį diagramų rezultatų klausytuve.
Kita vertus, absoliutus atsako laiko reikalavimas yra gana griežtas ir statistiškai praktiškas. Ką daryti, jei tik 0,5 proc. Mėginių neišlaikė testų? Vėlgi, tai yra susiję su atrankos variantais. Laimei, griežtas statistinis metodas atsižvelgia į atrankos variantus: pasikliautino intervalo analizę.
Prieš eidami toliau, peržiūrėkime pagrindinę statistiką.
Centrinės ribos teorema
Centrinės ribos teoremoje teigiama, kad jei populiacijos pasiskirstymas turi vidutinį μ ir standartinį nuokrypį σ, tada, esant pakankamai dideliam n (> 30), imties vidurkio imties pasiskirstymas yra maždaug normalus, o vidutinis μreiškia = μ ir standartinis nuokrypis σreiškia = σ / √n.
Prisimink tai imties vidurkio pasiskirstymas yra normalu. Pats mėginių pasiskirstymas nebūtinai yra normalus. Tai yra, jei bandomąjį scenarijų vykdysite daug kartų, gauto vidutinio atsako laiko paskirstymas bus normalus.
Žemiau 5 ir 6 paveiksluose parodyti du normalūs pasiskirstymai. Mūsų kontekste horizontali ašis yra atsako laiko imties vidurkis, pasislinkęs, taigi populiacijos vidurkis yra ištakos. 5 paveiksle parodyta, kad 90 procentų laiko imties priemonės yra intervale ± Zσ, kur Z = 1,645 ir σ yra standartinis nuokrypis. 6 paveiksle parodytas 99 procentų atvejis, kai Z = 2,576. Esant tikimybei, tarkime, 90 procentų, mes galime ieškoti atitinkamos Z vertės su įprasta kreive ir atvirkščiai.