Programování

Tipy JMeter

JMeter je populární open source nástroj pro testování zátěže s mnoha užitečnými funkcemi modelování, jako je skupina vláken, časovač a prvky vzorníku HTTP. Tento článek doplňuje uživatelskou příručku JMeter a poskytuje pokyny pro používání některých prvků modelování JMeter k vývoji skriptu pro testování kvality.

Tento článek se také věnuje důležitému problému v širším kontextu: upřesnění přesných požadavků na dobu odezvy a ověření výsledků testů. Konkrétně se používá přísná statistická metoda, analýza intervalu spolehlivosti.

Vezměte prosím na vědomí, že předpokládám, že čtenáři znají základy JMeteru. Příklady tohoto článku jsou založeny na JMeter 2.0.3.

Určete období rozběhu skupiny vláken

První ingrediencí ve vašem skriptu JMeter je skupina vláken, tak si to nejprve přečtěte. Jak je znázorněno na obrázku 1, prvek skupiny vláken obsahuje následující parametry:

  • Počet vláken.
  • Náběhové období.
  • Počet pokusů o provedení testu.
  • Po spuštění, zda test proběhne okamžitě nebo počká do naplánovaného času. Pokud je to poslední, musí prvek skupiny vláken obsahovat také počáteční a koncový čas.

Každé vlákno provádí plán testování nezávisle na ostatních vláknech. Proto se k modelování souběžných uživatelů používá skupina vláken. Pokud klientskému počítači se spuštěným JMeterem chybí dostatek výpočetního výkonu k modelování velkého zatížení, funkce distribučního testování JMeteru umožňuje ovládat více vzdálených motorů JMeter z jedné konzoly JMeter.

Období náběhu sděluje JMeteru dobu potřebnou k vytvoření celkového počtu vláken. Výchozí hodnota je 0. Pokud je doba rozběhu ponechána nespecifikovaná, tj. Doba rozběhu je nula, JMeter okamžitě vytvoří všechna vlákna. Pokud je doba rozběhu nastavena na T sekund a celkový počet vláken je N, JMeter vytvoří vlákno každých T / N sekund.

Většina parametrů skupiny vláken je vysvětlitelná, ale doba rozběhu je trochu divná, protože příslušné číslo není vždy zřejmé. Za prvé, období rozběhu by nemělo být nula, pokud máte velký počet vláken. Na začátku zátěžového testu, pokud je doba náběhu nulová, vytvoří JMeter všechna vlákna najednou a okamžitě odešle požadavky, čímž potenciálně nasycuje server a, což je důležitější, klamně zvyšuje zátěž. To znamená, že by se server mohl přetížit, ne proto, že je průměrná míra úspěšnosti vysoká, ale proto, že odešlete všechny první požadavky vláken současně, což způsobí neobvyklou počáteční špičkovou míru zásahu. Tento efekt můžete vidět pomocí posluchače JMeter Aggregate Report.

Jelikož tato anomálie není žádoucí, je pravidlem pro stanovení přiměřené doby rozběhu udržovat počáteční míru úspěšnosti blízko průměrné míry úspěšnosti. Pravděpodobně možná budete muset spustit testovací plán jednou, než zjistíte přiměřené číslo.

Ze stejného důvodu není také vhodná velká doba rozběhu, protože může být podhodnoceno špičkové zatížení. To znamená, že některá vlákna možná ani nezačala, zatímco některá počáteční vlákna již byla ukončena.

Jak tedy ověříte, že doba rozběhu není ani příliš malá, ani příliš velká? Nejprve uhodněte průměrnou míru zásahu a poté vypočítejte počáteční období náběhu vydělením počtu vláken odhadovanou rychlostí zásahu. Například pokud je počet vláken 100 a odhadovaná rychlost zásahu je 10 zásahů za sekundu, odhadovaná ideální doba rozběhu je 100/10 = 10 sekund. Jak přijdete s odhadovanou mírou úspěšnosti? Není snadný způsob. Musíte pouze jednou spustit testovací skript.

Zadruhé, přidejte do plánu testování posluchače agregovaných zpráv, který je znázorněn na obrázku 2; obsahuje průměrnou míru zásahu každého jednotlivého požadavku (vzorníky JMeter). Míra požadavku na první vzorkovač (např. Požadavek HTTP) úzce souvisí s dobou náběhu a počtem vláken. Upravte dobu náběhu tak, aby se míra úspěšnosti prvního vzorkovače plánu testu blížila průměrné míře úspěšnosti všech ostatních vzorkovačů.

Za třetí ověřte v protokolu JMeter (umístěném v JMeter_Home_Directory / bin), že první podproces, který skončí, skutečně skončí po spuštění posledního podprocesu. Časový rozdíl mezi nimi by měl být co nejdále od sebe.

Stručně řečeno, stanovení dobré doby rozběhu se řídí následujícími dvěma pravidly:

  • Míra úspěšnosti prvního vzorkovače by se měla blížit průměrné míře zásahu ostatních vzorkovačů, čímž by se zabránilo malé době náběhu
  • První vlákno, které končí, skutečně skončí po spuštění posledního vlákna, nejlépe co nejdále od sebe, čímž se zabrání velké době doběhu

Někdy jsou obě pravidla v rozporu. To znamená, že jednoduše nemůžete najít vhodné období rozběhu, které by vyhovovalo oběma pravidlům. Triviální testovací plán obvykle způsobí tento problém, protože v takovém plánu chybí dostatek vzorníků pro každé vlákno; plán testu je tedy příliš krátký a vlákno rychle dokončí svou práci.

Uživatel si myslí čas, časovač a proxy server

Důležitým prvkem, který je třeba vzít v úvahu při zátěžové zkoušce, je myslet čas, nebo pauza mezi po sobě jdoucími požadavky. Zpoždění způsobují různé okolnosti: uživatel potřebuje čas na přečtení obsahu nebo na vyplnění formuláře nebo na hledání správného odkazu. Nesprávné zvážení doby myšlení často vede k vážně předpojatým výsledkům testu. Například odhadovaná škálovatelnost, tj. Maximální zatížení (souběžní uživatelé), které systém dokáže udržet, se bude jevit jako nízké.

JMeter poskytuje sadu prvků časovače pro modelování času na přemýšlení, ale stále zůstává otázka: jak určíte vhodný čas na přemýšlení? Naštěstí JMeter nabízí dobrou odpověď: prvek JMeter HTTP Proxy Server.

Server proxy zaznamenává vaše akce, když procházíte webovou aplikaci v normálním prohlížeči (například FireFox nebo Internet Explorer). Kromě toho JMeter vytvoří plán testování při záznamu vašich akcí. Tato funkce je velmi pohodlná z několika důvodů:

  • Nemusíte ručně vytvářet požadavek HTTP, zejména ty zdlouhavé parametry formuláře. (Jiné než anglické parametry však nemusí fungovat správně.) JMeter zaznamená vše v automaticky generovaných požadavcích, včetně skrytých polí.
  • V generovaném testovacím plánu JMeter zahrnuje všechny hlavičky HTTP generované prohlížečem, jako je User-Agent (např. Mozilla / 4.0) nebo AcceptLanguage (např. Zh-tw, en-us; q = 0,7, zh- cn; q = 0,3).
  • JMeter může vytvářet časovače podle vašeho výběru, kde je čas zpoždění nastaven podle skutečného zpoždění během doby záznamu.

Podívejme se, jak nakonfigurovat JMeter s funkcí nahrávání. V konzole JMeter klepněte pravým tlačítkem na prvek WorkBench a přidejte prvek HTTP Proxy Server. Všimněte si, že kliknete pravým tlačítkem na prvek WorkBench, ne na prvek Test Plan, protože zde uvedená konfigurace je pro záznam, nikoli pro spustitelný testovací plán. Účelem prvku HTTP Proxy Server je nakonfigurovat proxy server prohlížeče tak, aby všechny požadavky procházely JMeter.

Jak je znázorněno na obrázku 3, pro prvek serveru proxy HTTP musí být nakonfigurováno několik polí:

  • Přístav: Naslouchající port používaný serverem proxy.
  • Ovladač cíle: Řadič, kde proxy ukládá vygenerované vzorky. Ve výchozím nastavení bude JMeter hledat záznamový řadič v aktuálním testovacím plánu a ukládat tam vzorky. Alternativně můžete vybrat libovolný prvek řadiče uvedený v nabídce. Výchozí nastavení je obvykle v pořádku.
  • Seskupení: Jak byste chtěli seskupit vygenerované prvky v plánu testování. K dispozici je několik možností a nejrozumnější z nich je pravděpodobně „Store 1st sampler only of each group“, jinak budou zaznamenány také adresy URL vložené do stránky, například pro obrázky a JavaScripty. Možná však budete chtít vyzkoušet výchozí možnost „Neseskupovat vzorky“, abyste zjistili, co přesně JMeter pro vás vytvoří v plánu testování.
  • Vzory k zahrnutí a Vyloučené vzory: Pomůže vám odfiltrovat některé nežádoucí požadavky.

Když kliknete na tlačítko Start, spustí se proxy server a začne zaznamenávat požadavky HTTP, které přijímá. Samozřejmě před kliknutím na Start musíte nakonfigurovat nastavení proxy serveru vašeho prohlížeče.

Můžete přidat časovač jako podřízený prvek prvku HTTP Proxy Server, který instruuje JMeter, aby automaticky přidal časovač jako podřízený požadavek HTTP, který generuje. JMeter automaticky ukládá skutečné časové zpoždění do volané proměnné JMeter T, takže pokud přidáte Gaussian náhodný časovač k prvku HTTP Proxy Server, měli byste zadat $ {T} v poli Konstantní zpoždění, jak je znázorněno na obrázku 4. Toto je další pohodlná funkce, která vám ušetří spoustu času.

Pamatujte, že časovač způsobí zpoždění ovlivněných vzorkovačů. To znamená, že ovlivněné požadavky na vzorkování se neodesílají před uplynutím zadaného času zpoždění od poslední přijaté odpovědi. Proto byste měli ručně odebrat vygenerovaný časovač prvního vzorkovače, protože první vzorkovač ho obvykle nepotřebuje.

Před spuštěním serveru proxy HTTP byste měli přidat skupinu podprocesů do plánu testování a poté do skupiny podprocesů přidat řadič záznamu, kde budou uloženy vygenerované prvky. Jinak budou tyto prvky přidány přímo do WorkBench. Kromě toho je důležité přidat prvek záznamu požadavku HTTP (prvek konfigurace) na řadič záznamu, takže JMeter ponechá pole vyplněná výchozími požadavky HTTP prázdná.

Po záznamu zastavte HTTP proxy server; pravým tlačítkem myši na prvek Recording Controller uložíte zaznamenané prvky do samostatného souboru, abyste je mohli později načíst. Nezapomeňte obnovit nastavení serveru proxy prohlížeče.

Určete požadavky na dobu odezvy a ověřte výsledky testů

I když to přímo nesouvisí s JMeter, zadání požadavků na dobu odezvy a ověření výsledků testu jsou dva důležité úkoly pro testování zátěže, přičemž JMeter je most, který je spojuje.

V kontextu webových aplikací doba odezvy označuje dobu, která uplynula mezi podáním žádosti a přijetím výsledného kódu HTML. Technicky by doba odezvy měla zahrnovat čas, který má prohlížeč k vykreslení stránky HTML, ale prohlížeč obvykle zobrazuje stránku kousek po kousku, čímž je vnímaná doba odezvy kratší. Kromě toho nástroj pro zátěžový test obvykle vypočítává dobu odezvy bez zohlednění doby vykreslení. Z praktických důvodů testování výkonu proto přijímáme výše popsanou definici. Pokud máte pochybnosti, přidejte k naměřené době odezvy konstantu, řekněme 0,5 sekundy.

K určení kritérií doby odezvy existuje sada dobře známých pravidel:

  • Uživatelé si nevšimnou zpoždění kratšího než 0,1 sekundy
  • Zpoždění kratší než 1 sekunda nepřerušuje tok myšlenek uživatele, ale je zaznamenáno určité zpoždění
  • Uživatelé budou i nadále čekat na odpověď, pokud je zpožděna o méně než 10 sekund
  • Po 10 sekundách uživatelé ztratí pozornost a začnou dělat něco jiného

Tyto prahové hodnoty jsou dobře známé a nezmění se, protože přímo souvisejí s kognitivními charakteristikami lidí. Ačkoli byste měli nastavit své požadavky na dobu odezvy v souladu s těmito pravidly, měli byste je také upravit pro konkrétní aplikaci. Například domovská stránka Amazon.com se řídí výše uvedenými pravidly, ale protože upřednostňuje stylističtější vzhled, obětuje trochu času odezvy.

Na první pohled se zdá, že existují dva různé způsoby, jak určit požadavky na dobu odezvy:

  • Průměrná doba odezvy
  • Absolutní doba odezvy; to znamená, že doby odezvy všech odpovědí musí být pod prahovou hodnotou

Zadání průměrných požadavků na dobu odezvy je jednoduché, ale skutečnost, že tento požadavek nebere v úvahu datovou variaci, je znepokojující. Co když je doba odezvy 20 procent vzorků více než trojnásobek průměru? Všimněte si, že JMeter pro vás v posluchači výsledků grafu vypočítá průměrnou dobu odezvy a standardní odchylku.

Na druhou stranu je požadavek na absolutní dobu odezvy poměrně přísný a statisticky nepraktický. Co když pouze 0,5 procenta vzorků neprošlo testy? To opět souvisí s variací vzorkování. Naštěstí přísná statistická metoda zvažuje variaci vzorkování: analýzu intervalu spolehlivosti.

Než půjdeme dále, podívejme se na základní statistiky.

Centrální limitní věta

Centrální limitní věta uvádí, že pokud má populační distribuce střední μ a směrodatnou odchylku σ, pak je pro dostatečně velké n (> 30) distribuční vzorek vzorkovacího průměru přibližně normální, se střední μznamenat = μ a směrodatná odchylka σznamenat = σ / √n.

Všimněte si, že rozdělení vzorkovacího průměru je normální. Distribuce samotného odběru není nutně normální. To znamená, že pokud testovací skript spustíte mnohokrát, bude distribuce výsledných průměrných dob odezvy normální.

Obrázky 5 a 6 níže ukazují dvě normální rozdělení. V našem kontextu je vodorovná osa vzorkovací průměr doby odezvy, posunutý tak, že střední hodnota populace je na počátku. Obrázek 5 ukazuje, že v 90 procentech času jsou prostředky vzorkování v intervalu ± Zσ, kde Z = 1,645 a σ je směrodatná odchylka. Obrázek 6 ukazuje 99% případ, kde Z = 2,576. Pro danou pravděpodobnost, řekněme 90 procent, můžeme vyhledat odpovídající hodnotu Z s normální křivkou a naopak.

$config[zx-auto] not found$config[zx-overlay] not found