JMeter ir populārs atvērtā koda rīks slodzes testēšanai, ar daudzām noderīgām modelēšanas funkcijām, piemēram, pavedienu grupu, taimeri un HTTP paraugu ņemšanas elementiem. Šis raksts papildina JMeter lietotāja rokasgrāmatu un sniedz vadlīnijas dažu JMeter modelēšanas elementu izmantošanai, lai izstrādātu kvalitātes testa skriptu.
Šajā rakstā svarīgs jautājums tiek aplūkots arī plašākā kontekstā: precizējot precīzas reakcijas laika prasības un pārbaudot testa rezultātus. Konkrēti, tiek izmantota stingra statistikas metode - ticamības intervāla analīze.
Lūdzu, ņemiet vērā, ka pieņemu, ka lasītāji zina JMeter pamatus. Šī raksta piemēri ir balstīti uz JMeter 2.0.3.
Nosakiet pavedienu grupas pārejas periodu
Pirmā JMeter skripta sastāvdaļa ir pavedienu grupa, tāpēc vispirms to pārskatīsim. Kā parādīts 1. attēlā, Thread Group elementā ir šādi parametri:
- Vītņu skaits.
- Paaugstināšanas periods.
- Testa izpildes reižu skaits.
- Sākot, neatkarīgi no tā, vai pārbaude notiek uzreiz, vai arī jāgaida līdz noteiktam laikam. Ja pēdējais, Thread Group elementā jāiekļauj arī sākuma un beigu laiks.
Katrs pavediens izpilda testa plānu neatkarīgi no citiem pavedieniem. Tāpēc vienlaicīgu lietotāju modelēšanai tiek izmantota pavedienu grupa. Ja klienta mašīnai, kurā darbojas JMeter, trūkst pietiekamas skaitļošanas jaudas, lai modelētu smagu slodzi, JMeter izplatīšanas testēšanas funkcija ļauj kontrolēt vairākus JMeter attālinātos dzinējus no vienas JMeter konsoles.
Paaugstināšanas periods norāda JMeter par laiku, cik ilgi jāizveido kopējais pavedienu skaits. Noklusējuma vērtība ir 0. Ja palaišanas periods paliek nenoteikts, t.i., palielināšanas periods ir nulle, JMeter nekavējoties izveidos visus pavedienus. Ja palielināšanas periods ir iestatīts uz T sekundēm un kopējais pavedienu skaits ir N, JMeter izveidos pavedienu ik pēc T / N sekundes.
Lielākā daļa pavedienu grupas parametru ir pašsaprotami, taču palielināšanas periods ir nedaudz dīvains, jo atbilstošais skaitlis ne vienmēr ir acīmredzams. Pirmkārt, palielināšanas periodam nevajadzētu būt nullei, ja jums ir daudz pavedienu. Slodzes testa sākumā, ja palielināšanas periods ir nulle, JMeter izveidos visus pavedienus uzreiz un nekavējoties nosūtīs pieprasījumus, tādējādi potenciāli piesātinot serveri un, vēl svarīgāk, maldinoši palielinot slodzi. Tas nozīmē, ka serveris var pārslogot nevis tāpēc, ka vidējais trāpījumu līmenis ir augsts, bet gan tāpēc, ka visus pavedienu pirmos pieprasījumus sūtāt vienlaikus, izraisot neparastu sākotnējo maksimālo trāpījumu līmeni. Šo efektu var redzēt, izmantojot JMeter apkopoto pārskatu klausītāju.
Tā kā šī anomālija nav vēlama, tāpēc pamatnoteikums, lai noteiktu saprātīgu paaugstināšanas periodu, ir saglabāt sākotnējo trāpījumu līmeni tuvu vidējam trāpījumu līmenim. Protams, pirms saprātīga skaitļa atklāšanas jums, iespējams, būs jāizpilda testa plāns vienreiz.
Tāpat arī liels uzlaušanas periods nav piemērots, jo maksimālo slodzi var nenovērtēt. Tas ir, daži no pavedieniem, iespējams, pat nav sākušies, savukārt daži sākotnējie pavedieni jau ir beigušies.
Tātad, kā jūs pārbaudāt, vai uzlaušanas periods nav ne pārāk mazs, ne pārāk liels? Vispirms uzminiet vidējo trāpījumu līmeni un pēc tam aprēķiniet sākotnējo palielināšanas periodu, dalot pavedienu skaitu ar uzminēto trāpījumu līmeni. Piemēram, ja pavedienu skaits ir 100 un aprēķinātais trāpījumu līmenis ir 10 trāpījumi sekundē, aplēstais ideālais palielināšanas periods ir 100/10 = 10 sekundes. Kā jūs iegūstat aplēsto trāpījumu līmeni? Nav vienkārša ceļa. Vispirms jums vienreiz ir jāpalaiž testa skripts.
Otrkārt, testa plānam pievienojiet apkopoto ziņojumu klausītāju, kas parādīts 2. attēlā; tajā ir katra individuālā pieprasījuma vidējais trāpījumu līmenis (JMeter paraugu ņemšanas ierīces). Pirmā izlases parauga trāpījumu līmenis (piemēram, HTTP pieprasījums) ir cieši saistīts ar palielināšanas periodu un pavedienu skaitu. Pielāgojiet ātruma palielināšanas periodu tā, lai testa plāna pirmā paraugu ņemšanas trāpījumu līmenis būtu tuvu visu pārējo paraugu ņemšanas ierīču vidējam trāpījumu līmenim.
Treškārt, JMeter žurnālā (atrodas JMeter_Home_Directory / bin) pārbaudiet, vai pirmais pabeigtais pavediens patiešām beidzas pēc pēdējās pavediena sākšanas. Laika starpībai starp abām jābūt pēc iespējas tālāk.
Rezumējot, labu uzcelšanās laiku nosaka šādi divi noteikumi:
- Pirmā parauga atlasītāja trāpījumu līmenim jābūt tuvam citu paraugu ņemšanas ierīču vidējam trāpījumu līmenim, tādējādi novēršot nelielu uzcenšanās periodu
- Pirmais pavediens, kas beidzas, patiešām beidzas pēc pēdējā pavediena sākuma, vēlams, cik vien iespējams tālu viens no otra, tādējādi novēršot lielu uzlaušanas periodu
Dažreiz abi noteikumi ir pretrunā. Tas ir, jūs vienkārši nevarat atrast piemērotu paaugstināšanas periodu, kas atbilst abiem noteikumiem. Parasti triviāls testa plāns rada šo problēmu, jo šādā plānā katram pavedienam trūkst pietiekami daudz paraugu; tādējādi testa plāns ir pārāk īss, un pavediens ātri pabeidz savu darbu.
Lietotājs domā laiku, taimeri un starpniekserveri
Svarīgs elements, kas jāņem vērā slodzes testā, ir domāt laiku, vai pauze starp secīgiem pieprasījumiem. Aizkavēšanos izraisa dažādi apstākļi: lietotājam ir vajadzīgs laiks, lai lasītu saturu vai aizpildītu veidlapu, vai meklētu pareizo saiti. Ja pienācīgi netiek ņemts vērā domāšanas laiks, bieži tiek iegūti nopietni tendenciozi testa rezultāti. Piemēram, aplēstā mērogojamība, t.i., maksimālā slodze (vienlaicīgi lietotāji), ko sistēma var izturēt, šķiet zema.
JMeter nodrošina taimera elementu kopumu, lai modelētu domāšanas laiku, taču joprojām paliek jautājums: kā noteikt piemērotu domāšanas laiku? Par laimi, JMeter piedāvā labu atbildi: JMeter HTTP starpniekservera elements.
Starpniekserveris reģistrē jūsu darbības, kamēr jūs pārlūkojat tīmekļa lietojumprogrammu ar parastu pārlūku (piemēram, Firefox vai Internet Explorer). Turklāt, reģistrējot jūsu darbības, JMeter izveido testa plānu. Šī funkcija ir ļoti ērta vairākiem mērķiem:
- Jums nav manuāli jāizveido HTTP pieprasījums, īpaši tie, kas ir garlaicīgi formas parametri. (Tomēr parametri, kas nav angļu valodā, var nedarboties pareizi.) JMeter automātiski ierakstīs visu automātiski ģenerētajos pieprasījumos, ieskaitot slēptos laukus.
- Izveidotajā testa plānā JMeter ietver visas pārlūkprogrammas ģenerētās HTTP galvenes, piemēram, User-Agent (piemēram, Mozilla / 4.0) vai AcceptLanguage (piemēram, zh-tw, en-us; q = 0,7, zh- cn; q = 0,3).
- JMeter var izveidot taimerus pēc jūsu izvēles, kur aizkaves laiks tiek iestatīts atbilstoši faktiskajai aizkavei ierakstīšanas periodā.
Apskatīsim, kā konfigurēt JMeter ar ierakstīšanas funkciju. JMeter konsolē ar peles labo pogu noklikšķiniet uz elementa WorkBench un pievienojiet HTTP starpniekservera elementu. Ņemiet vērā, ka ar peles labo pogu noklikšķiniet uz elementa WorkBench, nevis uz testa plāna elementu, jo šeit konfigurācija ir paredzēta ierakstīšanai, nevis izpildāmam testa plānam. Elementa HTTP starpniekservera mērķis ir konfigurēt pārlūkprogrammas starpniekserveri, lai visi pieprasījumi tiktu veikti caur JMeter.
Kā parādīts 3. attēlā, HTTP starpniekservera elementam ir jākonfigurē vairāki lauki:
- Osta: Klausīšanās ports, kuru izmanto starpniekserveris.
- Mērķa kontrolieris: Kontrolieris, kurā starpniekserveris glabā ģenerētos paraugus. Pēc noklusējuma JMeter pašreizējā testa plānā meklēs ierakstīšanas kontrolieri un glabās paraugus tur. Varat arī izvēlēties jebkuru izvēlnē norādīto kontrollera elementu. Parasti noklusējums ir kārtībā.
- Grupēšana: Kā jūs vēlaties grupēt ģenerētos elementus testa plānā. Ir pieejamas vairākas opcijas, un visprātīgākais, iespējams, ir "Saglabāt tikai katras grupas 1. paraugu ņemšanu", pretējā gadījumā tiks ierakstīti arī lapā iegultie URL, piemēram, attēli un JavaScripti. Tomēr, iespējams, vēlēsities izmēģināt noklusējuma opciju “Nesagrupēt paraugus”, lai uzzinātu, ko tieši JMeter jums izveido testa plānā.
- Iekļaujamie modeļi un Izslēdzamie modeļi: Palīdzēs jums filtrēt dažus nevēlamus pieprasījumus.
Noklikšķinot uz pogas Sākt, starpniekserveris sāk darboties un sāk ierakstīt saņemtos HTTP pieprasījumus. Protams, pirms noklikšķināt uz Sākt, jums ir jākonfigurē pārlūkprogrammas starpniekservera iestatījumi.
Taimeri var pievienot kā elementu HTTP starpniekserveris, kas JMeter uzdos automātiski pievienot taimeri kā tā ģenerētā HTTP pieprasījuma pakārtoto. JMeter automātiski saglabā faktisko laika aizkavi uz izsaukto JMeter mainīgo T, tādēļ, ja HTTP starpniekservera elementam pievienojat Gausa izlases taimeri, jums vajadzētu ierakstīt $ {T} laukā Pastāvīga kavēšanās, kā parādīts 4. attēlā. Šī ir vēl viena ērta funkcija, kas ietaupa daudz laika.
Ņemiet vērā, ka taimeris aizkavē ietekmēto paraugu ņemšanu. Tas ir, ietekmētie izlases pieprasījumi netiek nosūtīti, pirms nav pagājis norādītais kavēšanās laiks kopš pēdējās saņemtās atbildes. Tādēļ jums vajadzētu manuāli noņemt pirmā paraugu ģenerētāja taimeri, jo pirmajam paraugam tas parasti nav vajadzīgs.
Pirms HTTP starpniekservera palaišanas testa plānam jāpievieno pavedienu grupa un pēc tam pavedienu grupai jāpievieno ierakstīšanas kontrolieris, kurā tiks glabāti ģenerētie elementi. Pretējā gadījumā šie elementi tiks tieši pievienoti WorkBench. Turklāt ir svarīgi pievienot HTTP pieprasījuma noklusējuma elementu (konfigurācijas elementu) ierakstīšanas kontrolierim, lai JMeter atstātu tukšus tos laukus, kurus norādījuši HTTP pieprasījuma noklusējumi.
Pēc ierakstīšanas pārtrauciet HTTP starpniekserveri; ar peles labo pogu noklikšķiniet uz elementa Recording Controller, lai ierakstītos elementus saglabātu atsevišķā failā, lai vēlāk tos varētu izgūt. Neaizmirstiet atsākt pārlūkprogrammas starpniekservera iestatījumus.
Norādiet reakcijas laika prasības un apstipriniet testa rezultātus
Lai gan tas nav tieši saistīts ar JMeter, atbildes laika prasību precizēšana un testa rezultātu apstiprināšana ir divi kritiski uzdevumi slodzes testēšanai, un JMeter ir tilts, kas tos savieno.
Tīmekļa lietojumprogrammu kontekstā atbildes laiks attiecas uz laiku, kas pagājis starp pieprasījuma iesniegšanu un iegūtā HTML saņemšanu. Tehniski atbildes laikam jāietver laiks, kad pārlūkprogramma atveido HTML lapu, taču pārlūks parasti lapu parāda pa daļai, padarot uztverto reakcijas laiku mazāku. Turklāt parasti slodzes pārbaudes rīks aprēķina reakcijas laiku, neņemot vērā renderēšanas laiku. Tāpēc praktiskiem veiktspējas testēšanas mērķiem mēs pieņemam iepriekš aprakstīto definīciju. Ja rodas šaubas, izmērītajam reakcijas laikam pievienojiet konstanti, teiksim, 0,5 sekundes.
Atbildes laika kritēriju noteikšanai ir plaši pazīstamu noteikumu kopums:
- Lietotāji nepamana kavēšanos, kas ir mazāka par 0,1 sekundi
- Kavēšanās, kas ir mazāka par 1 sekundi, nepārtrauc lietotāja domu plūsmu, taču tiek pamanīta zināma kavēšanās
- Lietotāji joprojām gaidīs atbildi, ja tā tiks aizkavēta mazāk nekā par 10 sekundēm
- Pēc 10 sekundēm lietotāji zaudē uzmanību un sāk darīt kaut ko citu
Šie sliekšņi ir labi zināmi un nemainīsies, jo tie ir tieši saistīti ar cilvēku kognitīvajām īpašībām. Lai gan jums jānosaka atbildes laika prasības saskaņā ar šiem noteikumiem, tās jāpielāgo arī konkrētajai lietojumprogrammai. Piemēram, Amazon.com mājas lapa ievēro iepriekš minētos noteikumus, taču, tā kā tā dod priekšroku stiliskākam izskatam, tā upurē nelielu atbildes laiku.
No pirmā acu uzmetiena šķiet, ka ir divi dažādi veidi, kā noteikt reakcijas laika prasības:
- Vidējais reakcijas laiks
- Absolūtais reakcijas laiks; tas ir, visu atbilžu reakcijas laikiem jābūt zem sliekšņa
Vidējo reakcijas laika prasību noteikšana ir vienkārša, taču fakts, ka šajā prasībā nav ņemtas vērā datu variācijas, ir satraucošs. Ko darīt, ja reakcijas laiks 20 procentiem paraugu ir vairāk nekā trīs reizes lielāks par vidējo? Ņemiet vērā, ka JMeter grafisko rezultātu klausītājā aprēķina vidējo reakcijas laiku, kā arī standarta novirzi.
No otras puses, absolūtā reakcijas laika prasība ir diezgan stingra un statistiski nav praktiska. Ko darīt, ja tikai 0,5 procenti paraugu neizturēja testus? Arī tas ir saistīts ar izlases variāciju. Par laimi, stingrā statistikas metodē tiek ņemtas vērā izlases variācijas: ticamības intervāla analīze.
Pirms iet tālāk, pārskatīsim pamatstatistiku.
Centrālās robežas teorēma
Centrālās robežas teorēma norāda, ka, ja populācijas sadalījumam ir vidējais μ un standartnovirze σ, tad pietiekami lielam n (> 30) izlases vidējais paraugu sadalījums ir aptuveni normāls, ar vidējo μnozīmē = μ un standartnovirze σnozīmē = σ / √n.
Pieraksti to izlases vidējā sadalījums ir normāli. Pašas izlases sadalījums ne vienmēr ir normāls. Tas ir, ja testa skriptu palaidīsit daudzas reizes, iegūto vidējo reakcijas laiku sadalījums būs normāls.
Zemāk 5. un 6. attēlā parādīti divi normāli sadalījumi. Mūsu kontekstā horizontālā ass ir atbildes laika izlases vidējais lielums, kas pārvietots, tāpēc populācijas vidējais lielums ir sākotnējais. 5. attēlā parādīts, ka 90 procenti laika paraugu ņemšanas līdzekļi atrodas intervālā ± Zσ, kur Z = 1,645 un σ ir standartnovirze. 6. attēlā parādīts 99 procentu gadījums, kur Z = 2,576. Dotai varbūtībai, teiksim, 90 procentiem, mēs varam meklēt atbilstošo Z vērtību ar normālu līkni un otrādi.
