JMeter VS WRK

Úvod

zdroj obrázku [1]

JMeter byl široce používán pro testování výkonu. Je to proto, že jeho četné funkce, jako je testování schopností různých protokolů / aplikací / serverů, IDE, které umožňují rychlý vývoj plánu testů, dynamické vykazování HTML, multithreading a vzorkovatelné skripty.

WRK je další nástroj pro testování výkonu, který běží na jednom vícejádrových procesorech. WRK podporuje zpracování odpovědí, vlastní hlášení a generování zpráv požadavků HTTP prostřednictvím skriptů Lua.

V poslední době, když jsme dělali Ballerina (obecný účel, souběžný a silně typizovaný programovací jazyk s textovými i grafickými syntaxemi, optimalizované pro případy použití na mikroslužbách), jsme zjistili, že různé výsledky výkonu pod těmito dvěma nástroji pro určité scénáře, které jsme testovali .

To byl zejména případ při provádění testů výkonu s větším počtem souběžných uživatelů (např. 2000). To nás vedlo k prozkoumání chování těchto dvou nástrojů v celé řadě scénářů. Patří sem různé souběžnosti, velikosti zpráv a doba odezvy serveru.

Kvůli jednoduchosti jsme provedli naše vyhodnocení (dvou nástrojů) pomocí serveru NETTY (místo Balleriny).

Na tomto blogu uvedu některé z těchto výsledků a pozorování.

Souběžný model

Stojí za zmínku, že základní souběžné modely obou nástrojů jsou odlišné. Ve WRK „připojení“ představuje „uživatele“ a více připojení je zpracováno jedním vláknem. WRK distribuuje celkový počet připojení rovnoměrně mezi podprocesy a připojení jsou znovu použita v průběhu testu výkonu. Přestože můžeme řídit poměr mezi počtem vláken a připojeními, autor WRK doporučuje, aby se počet vláken rovnal počtu fyzických jader CPU. Následující obrázek ilustruje souběžný model implementovaný ve WRK. Další podrobnosti najdete v tomto článku (zdroj obrázků).

JMeter vytvoří vlákno a připojení pro každého uživatele a nemůžeme řídit poměr mezi počtem spojení a vlákny. To znamená, že při provádění testů výkonu pomocí velkého počtu uživatelů vytvoří JMeter velký počet podprocesů. V takových scénářích je možné, že přepínání kontextu mnoha vláken bude mít vliv na výkon. Tento efekt však můžeme minimalizovat pomocí několika instancí JMeter při provádění testů výkonu u velkého počtu uživatelů.

Prostředí pro testování výkonu

Jak již bylo zmíněno, cílem tohoto blogu je prozkoumat rozdíly ve výsledcích testů výkonnosti získané pomocí dvou nástrojů pro testování výkonu, jmenovitě WRK a JMeter. Náš scénář testování výkonu je implementován pomocí jednoduchého NETTY, který odešle zprávu HTTP, kterou obdrží zpět klientovi (tj. JMTER / WRK). Pro WRK byl test výkonu proveden na dvou instancích EC2 s 4vCPus: 1 instance WRK a 1 instance serveru NETTY. V případě JMeteru jsem použil klastrovanou sestavu a test výkonu byl proveden na pěti instancích EC2 s 4vCPus: 2 instancemi JMeter (server) (s klastrováním) a 1 instancí klienta JMeter a 1 serverem NETTY.

Hodnocení výkonnosti

Vyhodnocení výkonu se provádí změnou počtu současných uživatelů (500 až 4000), velikosti zprávy (0,1 K, 10k, 50K) a změnou doby odezvy serverů NETTY (10 ms, 1 000 ms). Zde doba odezvy serveru označuje čas, který čeká, než odešle odpověď zpět klientovi. Doba odezvy je generována spánkem. Podle doporučení autora jsem nastavil počet vláken ve WRK na 4 (= počet procesorů). Zvýšení počtu vláken nad 4 nevedlo k významným rozdílům ve výsledcích.

Server s rychlou odezvou (10ms)

Podívejme se nyní na chování serveru s rychlou odezvou. Následující obrázky ilustrují výsledky výkonu získané pod těmito dvěma nástroji, když je doba odezvy serveru 10 ms.

Bereme na vědomí, že pro malé velikosti zpráv (0,1 kB) JMeter přinesl lepší výsledky pro TPS ve srovnání s WRK. Pro malé velikosti zpráv jsou (průměrné) výsledky latence a WRK o něco lepší než JMeter. Jak se velikost zprávy zvětšuje, WRK má sklon produkovat lepší výsledky pro propustnost. Výsledky latence získané podle WRK jsou však ve srovnání s JMeterem vyšší. To platí zejména pro velké velikosti zpráv. Například, když počet souběžných uživatelů je 2000, průměrná latence pod WRK je 21 sekund, zatímco průměrná latence získaná za JMeter byla 1 sekunda. Pro stejný scénář je TPS pod WRK 1835 požadavků za sekundu, zatímco TPS pod JMeter je 1437 požadavků za sekundu.

Server s pomalou dobou odezvy (1000 ms)

Podívejme se nyní na chování, když je doba odezvy serveru 1000 ms. V tomto případě si všimneme, že oba nástroje vedou k (velmi) podobným výsledkům, s výjimkou testování s velkými souběžnostmi s použitím velkých zpráv. V tomto případě JMeter přinesl mnohem lepší výsledky pro latenci a zatímco v těchto dvou nástrojích nebyl žádný rozdíl v TPS. Následující obrázek ilustruje chování:

Závěr

V tomto článku jsem zkoumal výsledky výkonu získané pomocí dvou různých nástrojů pro testování výkonu: JMeter a WRK. Za nižších souběžností (<500) oba nástroje přinesly podobné výsledky. S rostoucím počtem souběžných uživatelů jsme zaznamenali významné odchylky ve výsledcích. Uvažovali jsme o serveru s pomalou a rychlou dobou odezvy. Jedním z hlavních pozorování bylo, že výsledky latence podle JMeter jsou mnohem (20 x) lepší ve srovnání s WRK pro řadu scénářů. V případě TPS nebyl žádný rozdíl ve výsledcích pro server s pomalou dobou odezvy. Pro server s rychlou odezvou vytvořil WRK lepší výsledky TPS (až 1,25 X) pro určité velikosti zpráv (> 1k) a JMeter produkoval lepší výsledky TPS (až 1,12 X), určité velikosti zpráv (<1K).