Sdílet prostřednictvím

Azure Load Testing s využitím vlastních modulů plug-in

  • Článek

Nápady na řešení

Tento článek popisuje myšlenku řešení. Váš cloudový architekt může pomocí těchto pokynů vizualizovat hlavní komponenty pro typickou implementaci této architektury. Tento článek slouží jako výchozí bod k návrhu dobře navrženého řešení, které odpovídá konkrétním požadavkům vaší úlohy.

Toto řešení obsahuje pokyny pro použití služby Azure Load Testing, která umožňuje spouštět skripty Apache JMeter a vlastní moduly plug-in pro simulaci chování uživatelů a zařízení. Toto řešení také vysvětluje, jak navrhovat klíčové ukazatele výkonu (KPI) a vyvíjet řídicí panel pro monitorování a analýzu výsledků zátěžového testu v ukázkové aplikaci pomocí Azure Functions a Azure Event Hubs. Článek předpokládá, že znáte JMeter, jeho moduly plug-in a vlastní moduly plug-in, stejně jako Azure Functions a Event Hubs.

Architektura

K provedení zátěžového testování potřebujete testovací plán, což je sada pokynů, které říká JMeter, co má během testu dělat. Testovací plán může obsahovat několik testovacích scénářů, z nichž každý má různá nastavení a konfigurace. Můžete mít například jeden scénář, který simuluje jednoho uživatele, který přistupuje k webové aplikaci, a jiný scénář, který simuluje více uživatelů současně přistupující ke stejné aplikaci.

Testovací plán může obsahovat také několik testovacích případů, z nichž každý má různá nastavení a konfigurace. V našem případě předpokládáme, že v určitém časovém období existuje zařízení, které hlásí teplotu a vlhkost. Zařízení odesílá data do centra událostí v Azure. Centrum událostí aktivuje funkci Azure, která je zodpovědná za zpracování dat a následné odesílání dat do jiných podřízených služeb, jako je Azure SQL Database. Funkce Azure je služba, kterou chceme otestovat. Testovací plán je navržený tak, aby simuluje chování zařízení a odesílá data do centra událostí.

Diagram ukázkové architektury pro zátěžové testování

Stáhněte si soubor aplikace Visio s touto architekturou.

Tok dat

V tomto příkladu je tok dat následující:

  1. Simulované zařízení odesílá data do centra událostí prostřednictvím agenta Azure Load Testing. Jakékoli chování zařízení je možné simulovat pomocí vlastních modulů plug-in JMeter. Agent zátěžového testu Azure zodpovídá za odesílání dat do centra událostí po spuštění vlastního modulu plug-in pro všechny typy simulovaných zařízení.
  2. Centrum událostí aktivuje funkci Azure Functions, která je zodpovědná za zpracování dat a následné odesílání dat do jiných podřízených služeb, jako je Azure SQL Database a Azure Digital Twins.
  3. Služba Azure Monitor se používá k monitorování služby Azure Functions a Event Hubs.
  4. Služba Azure Load Testing shromažďuje data ze služby Azure Monitor a pak je zobrazuje na řídicím panelu.

Komponenty

V tomto příkladu se používají následující komponenty:

  • Zátěžové testování Azure: Azure Load Testing umožňuje spouštět skripty Apache JMeter a vlastní moduly plug-in pro simulaci chování uživatelů a zařízení. Poskytuje webové rozhraní pro správu a spouštění zátěžových testů a sadu rozhraní API, která lze použít k automatizaci procesu. Azure Load Testing je plně spravovaná služba, což znamená, že se nemusíte starat o správu serverů nebo infrastruktury. Můžete nahrát skripty JMeter a vlastní moduly plug-in a Azure Load Testing zpracuje zbytek.
  • Azure Event Hubs: Azure Event Hubs je cloudová služba pro zpracování událostí, která se dá použít ke shromažďování, zpracování a analýze událostí a streamování dat z různých zdrojů v reálném čase. Event Hubs podporuje více protokolů, včetně protokolu AMQP (Advanced Message Queuing Protocol), HTTPS, Kafka Protocol, MQTT (Message Queuing Telemetry Transport) a AMQP over WebSockets. Volba správného protokolu závisí na několika faktorech, včetně typu dat, se kterými pracujete, konkrétních požadavků aplikace a možností a omezení samotných protokolů.
  • Azure Functions: Azure Functions je bezserverová výpočetní služba, která umožňuje spouštět kód bez nutnosti spravovat servery nebo infrastrukturu. Podporuje více programovacích jazyků, včetně C#, F#, Java, JavaScriptu, PowerShellu, Pythonu a TypeScriptu. Azure Functions je možné použít ke zpracování událostí a streamování dat ze služby Event Hubs a také k dalším zdrojům, jako je Azure Storage a Azure Cosmos DB.
  • JMeter GUI: JMeter GUI je opensourcový nástroj pro zátěžové testování, který se primárně používá k testování výkonu webových aplikací. Původně byla vyvinuta pro testování webových aplikací. Dá se ale použít také k testování jiných typů aplikací, jako jsou webové služby SOAP a REST, servery FTP a databáze.
  • Azure Monitor: Azure Monitor poskytuje možnosti monitorování a upozorňování pro prostředky Azure. Umožňuje také monitorovat výkon a stav aplikací a základní infrastrukturu. Azure Monitor se dá použít k monitorování služeb Event Hubs a Azure Functions a dalších služeb Azure, jako je Azure Storage a Azure Cosmos DB.

Podrobnosti scénáře

Azure Load Testing umožňuje použít existující skript Apache JMeter a použít ho ke spuštění zátěžového testu v cloudovém měřítku na jakémkoli prostředku Azure.

JMeter umožňuje testerům vytvářet a spouštět zátěžové testy, zátěžové testy a funkční testy. Simuluje více uživatelů současně přistupující k webové aplikaci a umožňuje testerům identifikovat potenciální kritické body výkonu nebo jiné problémy, které mohou nastat při velkém zatížení. JMeter lze použít k měření různých metrik výkonu, jako je doba odezvy, propustnost a míra chyb.

JMeter používá rozhraní založené na grafickém uživatelském rozhraní, které uživatelům umožňuje vytvářet testovací plány, které můžou zahrnovat více testovacích scénářů, z nichž každý má různá nastavení a konfigurace. Testeři mohou také přizpůsobit JMeter pomocí modulů plug-in nebo napsáním vlastního kódu, což jim umožní rozšířit jeho funkce nad rámec toho, co se dodává z krabice. Moduly plug-in nám můžou pomoct pracovat se službami, které používají jiné protokoly než HTTP, jako jsou AMQP a Websocket.

I když JMeter poskytuje širokou škálu funkcí a funkcí pro zátěžové testování, můžou existovat konkrétní případy použití nebo požadavky, které nejsou součástí integrované funkce. Vývojem vlastních modulů plug-in můžou testeři přidat nové funkce nebo přizpůsobit stávající funkce, aby lépe vyhovovaly jejich potřebám.

Můžete například vytvořit vlastní modul plug-in, který simuluje konkrétní typ chování uživatele nebo vygeneruje realističtější testovací data. Kromě toho je možné vyvíjet vlastní moduly plug-in pro integraci JMeter s jinými nástroji nebo systémy, jako jsou nástroje protokolování a vytváření sestav nebo kanály kontinuální integrace a nasazování. Vlastní moduly plug-in mohou zjednodušit proces testování a usnadnit začlenění zátěžového testování do celkového pracovního postupu vývoje softwaru. Celkově umožňují testerům přizpůsobit JMeter svým konkrétním potřebám a zlepšit přesnost a efektivitu úsilí při zátěžovém testování.

V tomto příkladu předpokládáme, že existuje zařízení, které hlásí teplotu a vlhkost v nastaveném časovém období. Toto jednoduché chování můžeme simulovat pomocí vlastního modulu plug-in JMeter. V aktuální implementaci vlastního modulu plug-in, který zde poskytujeme, vygenerujeme náhodná data pomocí poskytnuté šablony. Modul plug-in však může obsahovat jakékoli možné složité chování pro všechna zařízení. V tomto příkladu zařízení odesílá data do centra událostí v Azure. Centrum událostí aktivuje funkci Azure Functions, která je zodpovědná za zpracování dat a následné odesílání dat do jiných podřízených služeb, jako je Azure SQL Database. Funkce Azure je služba, kterou chceme otestovat. Testovací plán je navržený tak, aby simuluje chování zařízení a odesílá data do centra událostí.

Potenciální případy použití

Použití zátěžového testování Azure s vlastními moduly plug-in může být užitečné v různých scénářích, například:

  • Testování výkonu aplikace, která používá jiné protokoly než HTTP, jako jsou AMQP a Websocket.
  • Testování výkonu aplikace, která používá vlastní protokol
  • Testování výkonu aplikace, která používá sadu SDK jiné společnosti než Microsoft.
  • Simulace konkrétního typu chování uživatele nebo zařízení nebo generování realističtějších testovacích dat

Vlastní moduly plug-in

Vlastní moduly plug-in v kontextu JMeter jsou softwarové komponenty, které je možné přidat do JMeter, aby se rozšířily jeho funkce nad rámec toho, co přichází z krabice. Uživatelé nebo vývojáři jiných výrobců než Microsoft můžou vyvíjet vlastní moduly plug-in pro přidání nových funkcí, funkcí nebo integrací do JMeter. Vlastní moduly plug-in lze vyvíjet pomocí programovacího jazyka Java a sady JMeter Plugin Development Kit (PDK). PdK poskytuje sadu nástrojů a rozhraní API, které usnadňují vytváření nových modulů plug-in, včetně prvků grafického uživatelského rozhraní, naslouchacích procesů a vzorkovníků.

Vlastní moduly plug-in mohou do JMeter přidat širokou škálu funkcí. Mohou také integrovat JMeter s jinými systémy, jako jsou nástroje protokolování a vytváření sestav, nebo povolit použití jiných zdrojů dat pro testovací data. Vlastní moduly plug-in umožňují uživatelům rozšířit JMeter tak, aby vyhovovaly jejich konkrétním potřebám, a zlepšily přesnost a efektivitu úsilí při zátěžovém testování.

Pokud chcete implementovat vlastní sampler pro Službu Event Hubs v JMeteru, postupujte podle pokynů uvedených v modulech plug-in Azure Load Testing. Po implementaci vlastního sampleru ho můžete použít v testovacím plánu JMeter ve službě Azure Load Test stejně jako jakýkoli jiný sampler.

Testovací plán je možné implementovat pomocí skupiny vláken, která řídí počet vláken (virtuálních uživatelů a zařízení) ke spuštění konkrétního scénáře. Každá skupina vláken může mít různá nastavení pro počet vláken, období nájezdu, počet smyček a dobu trvání. Skupiny vláken je možné spouštět postupně nebo paralelně v závislosti na konfiguraci testovacího plánu a požadavcích aplikace. Sampler můžete přidat do skupiny vláken, nastavit jeho parametry a podle potřeby ho nakonfigurovat. Vlastní vzorkovače můžou být výkonné nástroje v JMeteru, které umožňují simulovat složité scénáře a požadavky, které integrované vzorkovací nástroje nepodporují.

Vytvoření skriptu Apache JMeter s vlastním modulem plug-in

V této části vytvoříte ukázkový testovací skript JMeter pro zátěžový test aplikace se službou Event Hubs.

Vytvoření ukázkového testovacího skriptu JMeter:

  1. Na místním počítači vytvořte soubor LoadTest.jmx :

    touch LoadTest.jmx

  2. Otevřete LoadTest.jmx v textovém editoru a vložte do souboru následující fragment kódu. Tento skript simuluje zátěžový test 36 virtuálních počítačů, které současně odesílají události do centra událostí a dokončení trvá 10 minut:

    <?xml version="1.0" encoding="UTF-8"?>
<jmeterTestPlan version="1.2" properties="5.0" jmeter="5.5">
    <hashTree>
    <TestPlan guiclass="TestPlanGui" testclass="TestPlan" testname="Test Plan" enabled="true">
        <stringProp name="TestPlan.comments"></stringProp>
        <boolProp name="TestPlan.functional_mode">false</boolProp>
        <boolProp name="TestPlan.tearDown_on_shutdown">true</boolProp>
        <boolProp name="TestPlan.serialize_threadgroups">false</boolProp>
        <elementProp name="TestPlan.user_defined_variables" elementType="Arguments" guiclass="ArgumentsPanel" testclass="Arguments" testname="User Defined Variables" enabled="true">
        <collectionProp name="Arguments.arguments"/>
        </elementProp>
        <stringProp name="TestPlan.user_define_classpath"></stringProp>
    </TestPlan>
    <hashTree>
        <ThreadGroup guiclass="ThreadGroupGui" testclass="ThreadGroup" testname="Thread Group" enabled="true">
        <stringProp name="ThreadGroup.on_sample_error">continue</stringProp>
        <elementProp name="ThreadGroup.main_controller" elementType="LoopController" guiclass="LoopControlPanel" testclass="LoopController" testname="Loop Controller" enabled="true">
            <boolProp name="LoopController.continue_forever">false</boolProp>
            <intProp name="LoopController.loops">-1</intProp>
        </elementProp>
        <stringProp name="ThreadGroup.num_threads">36</stringProp>
        <stringProp name="ThreadGroup.ramp_time">20</stringProp>
        <boolProp name="ThreadGroup.scheduler">true</boolProp>
        <stringProp name="ThreadGroup.duration">600</stringProp>
        <stringProp name="ThreadGroup.delay"></stringProp>
        <boolProp name="ThreadGroup.same_user_on_next_iteration">false</boolProp>
        </ThreadGroup>
        <hashTree>
        <com.microsoft.eventhubplugin.EventHubPlugin guiclass="com.microsoft.eventhubplugin.EventHubPluginGui" testclass="com.microsoft.eventhubplugin.EventHubPlugin" testname="Azure Event Hubs Sampler" enabled="true">
            <stringProp name="eventHubConnectionVarName">EventHubConnectionString</stringProp>
            <stringProp name="eventHubName">telemetry-data-changed-eh</stringProp>
            <stringProp name="liquidTemplateFileName">StreamingDataTemplate.liquid</stringProp>
        </com.microsoft.eventhubplugin.EventHubPlugin>
        <hashTree/>
        </hashTree>
    </hashTree>
    </hashTree>
</jmeterTestPlan>

    Implementace com.microsoft.eventhubplugin.EventHubPluginGui a je k dispozici na webu Azure Samplescom.microsoft.eventhubplugin.EventHubPlugin.

  3. V souboru nastavte hodnotu eventHubConnectionVarName uzlu na název proměnné, která určuje službu Event Hubs připojovací řetězec hostitele. Pokud například chcete, aby EventHubConnectionStringproměnná prostředí, která ukládá připojovací řetězec event Hubs, byla , nastavte tuto proměnnou na EventHubConnectionString hodnotu a pak nastavte hodnotu proměnné prostředí.

    Důležité

    Před spuštěním skriptu zátěžového EventHubConnectionString testu se ujistěte, že je hodnota nastavená jako součást procesu vytváření zátěžového testu Azure.

  4. V souboru nastavte hodnotu eventHubName uzlu na název centra událostí, například telemetry-data-changed-eh.

  5. Nastavte hodnotu liquidTemplateFileName uzlu na soubor obsahující zprávu, která je odeslána do centra událostí. Vytvořte například soubor s názvem StreamingDataTemplate.liquid :

    {
    {% assign numberOfMachines = 36 %}
    {% assign machineId = dataGenerator.randomNaturalNumber | modulo: numberOfMachines %}
    "MachineId": "{{machineId | prepend: '0000000000000000000000000000000000000000' | slice: -27, 27 }}"
    "Temperature": {{dataGenerator.randomInt | modulo: 100 }},
    "Humidity": {{dataGenerator.randomInt | modulo: 100 }}
}

    V tomto příkladu je datová část zprávy centra událostí objekt JSON se třemi vlastnostmi, včetně MachineId, Temperaturea Humidity kde MachineId je náhodně vygenerované ID s délkou 27 a Humidity Temperature jsou náhodná celá čísla menší než 100. Tento soubor je syntaxe šablony liquid. Šablona Liquid je oblíbený jazyk šablon, který se používá v různých architekturách pro vývoj webů. Šablony Liquid umožňují vývojářům vytvářet dynamický obsah, který lze snadno aktualizovat a upravit. Umožňují vložit proměnné, podmínky, smyčky a další dynamické prvky do zpráv centra událostí. Syntaxe je jednoduchá a k dispozici je spousta online zdrojů, které vám pomůžou začít. Šablony Liquid celkově nabízejí výkonný a flexibilní způsob vytváření dynamických a přizpůsobitelných zpráv.

  6. Soubor uložte a zavřete.

    Důležité

    Do názvu vzorkovníku do skriptu JMeter nezahrnujte žádné osobní údaje. Názvy sampleru se zobrazí na řídicím panelu výsledků testů zátěžového testování Azure. Ukázka šablony liquid spolu se souborem skriptu JMeter je k dispozici ke stažení na webu Azure Samples.

Spuštění zátěžového testu pomocí nového modulu plug-in

Když zátěžové testování Azure spustí zátěžový test, nejprve nasadí skript JMeter spolu se všemi ostatními soubory do instancí testovacího modulu a pak spustí zátěžový test podle pokynů při přizpůsobení zátěžového testu pomocí modulů plug-in Apache JMeter a azure Load Testing. Před spuštěním testu přejděte na kartu parametru, definujte EventHubConnectionStringa pak zadejte připojovací řetězec do centra událostí.

Snímek obrazovky znázorňující parametry testu

Nastavení testování výkonu pro prostředí

V jakémkoli testování výkonu je důležité mít podobné prostředí jako produkční prostředí. V tomto příkladu se k testování výkonu používá následující prostředí, aby bylo možné lépe porozumět systémové kapacitě a výkonu systému.

Pro ukázkovou architekturu je možné pro testování výkonu použít následující služby:

Služba Konfigurace
Centrum událostí Premium s jednou jednotkou zpracování (PU).
Funkce Azure Linux s plánem Premium (EP1) – 210 ACU, 3,5 GB paměti a 1 vCPU ekvivalentní Standard_D1_v2
Oblast USA – východ

Volba správné úrovně služby pro všechny služby Azure, včetně služeb Event Hubs a Azure Functions, je složitý proces a závisí na mnoha faktorech. Další informace najdete v tématu Ceny služby Azure Event Hubs a ceny služby Azure Functions.

Návrh klíčových ukazatelů výkonu pro testování výkonu

Než budete moct navrhnout klíčové ukazatele výkonu (KPI) pro testování výkonu, potřebujete dvě věci: obchodní požadavky a architekturu systému. Obchodní požadavky vám řeknou, jaké klíčové ukazatele výkonu chcete měřit, jako je doba odezvy, propustnost nebo míra chyb. Systémová architektura vám říká, jak otestovat výkon jednotlivých komponent, jako jsou webové servery, databáze nebo rozhraní API. Pomůže vám také zvolit nejlepší strategii testování výkonu, jako je zátěžové testování, zátěžové testování nebo testování vytrvalosti.

V tomto příkladu jsou obchodní požadavky:

  • Systém by měl být schopný zpracovat 1 000 požadavků za sekundu.
  • Spolehlivost systému by měla být vyšší než 0,99.
  • Systém by měl být schopný zpracovat 1 000 souběžných zařízení, která hlásí své osobní údaje.
  • Určení maximální kapacity systému z hlediska počtu zařízení, která je možné podporovat. Může například systém s 3x aktuální kapacity podporovat 1 000 souběžných zařízení?

Podle těchto požadavků by klíčové ukazatele výkonu pro testování výkonu mohly být následující:

Ukazatel KPI Popis
RPS Žádost za sekundu pro centrum událostí
NÁKLAD Počet zatížení nebo požadavků odeslaných do centra událostí během testování výkonu
IR Počet spuštění funkcí nebo rychlost příjmu dat
RT Average time for Azure Function Execution Time
AMU Průměrné využití paměti pro Azure Functions
SR Míra úspěšnosti všech spuštění funkcí
ARS Průměrná doba odezvy podřízené služby (například SQL server nebo mikroslužba)
DF Počet selhání závislostí včetně interních chyb funkce Azure
MRPS Maximální počet RPS bez backlogu v centru událostí (systémová kapacita)

Měření klíčových ukazatelů výkonu

Pokud chcete měřit klíčové ukazatele výkonu, musíte mít strategii testování výkonu. Strategie definuje přístup k testování výkonu pro každou komponentu. V tomto příkladu se používá následující strategie testování výkonu:

  • Event Hubs: Přístup k testování výkonu centra událostí spočívá v odesílání mnoha zpráv do centra událostí a následné měření RPS a načítání. RPS je počet zpráv odesílaných do centra událostí za sekundu. LOAD je celkový počet zpráv odesílaných do centra událostí během testování výkonu. Služba Azure Load Testing může měřit RPS a LOAD.
  • Azure Functions: Přístup k testování výkonu pro Azure Functions je měření následujících metrik:
    • Ir je počet spuštění funkcí nebo rychlost příjmu dat.
    • RT je průměrná doba provádění funkce Azure Functions.
    • AMU je průměrné využití paměti pro Azure Functions.
    • Sr je míra úspěšnosti všech spuštění funkcí.
    • ARS je průměrná doba odezvy podřízené služby.
    • DF je počet selhání závislostí, včetně interních chyb funkce Azure.
    • Služba Azure Monitor může měřit AMU, ARS a DF, ale ne IR, RT nebo SR.

Abychom mohli měřit klíčové ukazatele výkonu pomocí služby Azure Monitor, musíme povolit Application Insights pro Azure Functions. Další informace najdete v tématu Povolení integrace Application Insights.

Po povolení služby Azure Monitor můžete k měření klíčových ukazatelů výkonu použít následující dotazy:

  • IR: FunctionAppLogs | where Category startswith "name-space-of-your-function" and Message startswith "Executed" | summarize count() by FunctionName, Level, bin(TimeGenerated, 1h) | order by FunctionName desc
  • RT: FunctionAppLogs| where Category startswith "name-space-of-your-function" and Message startswith "Executed "| parse Message with "Executed " Name " (" Result ", Id=" Id ", Duration=" Duration:long "ms)"| project TimeGenerated, Message, FunctionName, Result, FunctionInvocationId, Duration
  • SR: FunctionAppLogs| where Category startswith "name-space-of-your-function" and Message startswith "Executed" | summarize Success=countif(Level == "Information" ), Total=count() by FunctionName| extend Result=Success*100.0/Total| project FunctionName, Result| order by FunctionName desc

Ukázka řídicího panelu služby Azure Monitor

Tady je ukázka řídicího panelu služby Azure Monitor, který zobrazuje klíčové ukazatele výkonu pro Azure Functions na základě dotazů:

Snímek obrazovky s ukázkami řídicího panelu služby Azure Monitor

Závěr

V tomto článku jste se naučili navrhovat klíčové ukazatele výkonu a vyvíjet řídicí panel pro Zátěžový test Azure. Dozvěděli jste se také, jak pomocí vlastních modulů plug-in v JMeter provádět zátěžové testování ve službě Azure Functions integrované se službou Event Hubs. Stejný přístup můžete použít k provádění zátěžového testování v jiných službách Azure. Můžete také nastavit kanál kontinuální integrace a doručování (CI/CD) pro skripty zátěžového testování pomocí Azure DevOps.

Další informace najdete v tématu Azure Load Testing.

Přispěvatelé

Tento článek spravuje Microsoft. Původně byla napsána následujícími přispěvateli.

Hlavní autor:

Pokud chcete zobrazit neveřejné profily LinkedIn, přihlaste se na LinkedIn.

Další kroky