Azure Load Testing s vlastními pluginy pro Event Hubs a IoT Hub

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. Tento příklad používá službu Event Hubs, ale stejný přístup můžete použít u služby Azure IoT Hub změnou klienta služby Event Hubs na klienta služby IoT Hub. Tento článek předpokládá, že jste obeznámeni s JMeterem, jeho pluginy a vlastními pluginy, funkcemi a Event Hubs.

IoT Hub obsahuje více základních komponent, včetně oddílů, než Event Hubs. Proto se metoda zátěžového testování popsaná v tomto článku vztahuje také na Službu IoT Hub s minimálními změnami.

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ářů a každý scénář může mít 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.

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

Tok dat

Následující tok dat odpovídá předchozímu diagramu:

Simulované zařízení odesílá data do centra událostí prostřednictvím agenta zátěžového testování. Jakékoli chování zařízení je možné simulovat pomocí vlastních modulů plug-in JMeter. Agent zátěžového testování odesílá data do centra událostí po spuštění vlastního modulu plug-in pro libovolný typ simulovaného zařízení.
Centrum událostí aktivuje aplikaci funkcí Azure, která zpracovává data a odesílá je do jiných podřízených služeb, jako je Azure SQL Database a Azure Digital Twins.
Azure Monitor monitoruje aplikaci funkcí a službu Event Hubs.
Zátěžové testování shromažďuje data ze služby Azure Monitor a zobrazuje je na řídicím panelu.

Komponenty

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

Zátěžové testování: Pomocí zátěžového testování můžete spouštět skripty Apache JMeter a vlastní moduly plug-in pro simulaci chování uživatelů a zařízení. Zátěžové testování poskytuje webové rozhraní pro správu a spouštění zátěžových testů a sadu rozhraní API pro automatizaci procesu. Zátěžové testování je plně spravovaná služba, což znamená, že nemusíte spravovat servery ani infrastrukturu. V této architektuře nástroj Load Testing nahrává skripty JMeter a vlastní plug-iny, a je to výpočetní prostředí, ve kterém se tyto skripty spouštějí.
Event Hubs: Event Hubs je cloudová služba pro zpracování událostí, kterou můžete 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ě Advanced Message Queuing Protocol (AMQP), HTTPS, protokolu Kafka, Message Queuing Telemetry Transport (MQTT) a AMQP přes WebSocket. Tato architektura je založená na událostech, takže zátěžové testování naplní události pro zátěžový test úlohy.
IoT Hub: IoT Hub je spravovaná služba hostovaná v cloudu, která slouží jako centrum zpráv pro komunikaci mezi aplikací IoT a připojenými zařízeními. Miliony zařízení a jejich back-endová řešení můžete spolehlivě a bezpečně připojit. Téměř jakékoli zařízení je možné připojit k centru IoT. Tuto architekturu můžete přizpůsobit tak, aby používala Službu IoT Hub změnou klienta služby Event Hubs na klienta služby IoT Hub.
Azure Functions: Functions je bezserverová výpočetní služba, kterou můžete použít ke spouštění kódu, aniž byste museli spravovat servery nebo infrastrukturu. Podporuje více programovacích jazyků, včetně C#, F#, Java, JavaScriptu, PowerShellu, Pythonu a TypeScriptu. Tato architektura používá functions jako primární výpočetní úroveň. Data událostí ve službě Event Hubs spouští a škálují funkce aplikací.
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í. Můžete ho ale použít také k otestová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. Slouží k monitorování výkonu a stavu aplikací a základní infrastruktury. V této architektuře Azure Monitor monitoruje stav komponent infrastruktury Azure během zátěžového testu.

Podrobnosti scénáře

Zátěžové testování můžete použít k použití existujícího skriptu Apache JMeter a 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, aby testeři mohli identifikovat potenciální kritické body výkonu nebo jiné problémy, které by mohly nastat při velkém zatížení. Pomocí JMeter můžete měřit různé metriky 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, což může zahrnovat několik testovacích scénářů, které mají různá nastavení a konfigurace. Testery můžou také přizpůsobit JMeter pomocí modulů plug-in nebo psaním vlastního kódu. Moduly plug-in můžou uživatelům pomoct pracovat se službami, které používají jiné protokoly než HTTP, jako jsou AMQP a WebSocket.

JMeter poskytuje širokou škálu funkcí a funkcí pro zátěžové testování, ale integrované funkce nemusí zahrnovat konkrétní případy použití nebo požadavky. Díky vývoji 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 vyvinout vlastní modul plug-in pro simulaci konkrétního typu chování uživatele nebo vygenerovat realističtější testovací data. Můžete také vyvíjet vlastní pluginy pro integraci JMeter s jinými nástroji nebo systémy, jako jsou nástroje pro protokolování a reportování nebo CI/CD kanály (kontinuální integrace a průběžné 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. 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 zařízení hlásí teplotu a vlhkost v určitém časovém období. Příklad simuluje toto chování pomocí vlastního modulu plug-in JMeter. Aktuální implementace vlastního modulu plug-in generuje náhodná data pomocí poskytnuté šablony. Modul plug-in však může obsahovat jakékoli možné složité chování pro jakékoli zařízení. V tomto příkladu zařízení odesílá data do centra událostí v Azure. Centrum událostí aktivuje aplikaci funkcí Azure, která zpracovává data a odesílá je do jiných podřízených služeb, jako je SQL Database. Azure Functions je služba, kterou architektura testuje. 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í 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í
Generování realističtějších testovacích dat

Vlastní pluginy

V JMeter jsou vlastní moduly plug-in softwarovými komponentami, které můžete přidat, aby se rozšířily její výchozí funkce. Vlastní zásuvné moduly přidávají do JMeter nové funkce, vlastnosti nebo integrace. Vlastní moduly plug-in můžete vyvíjet pomocí programovacího jazyka Java a vývojové sady JMeter (PDK). PDK poskytuje sadu nástrojů a rozhraní API, které vám pomohou vytvářet nové pluginy, včetně prvků grafického uživatelského rozhraní, posluchačů a vzorkovníků.

Pokud chcete implementovat vlastní sampler pro Event Hubs v JMeteru, postupujte podle pokynů v pluginech Load Testing JMeter. Po implementaci vlastního sampleru ho můžete použít v testovacím plánu JMeter v zátěžovém testování stejně jako jakýkoli jiný sampler.

Testovací plán můžete implementovat pomocí skupiny vláken, která řídí počet vláken, jako jsou virtuální 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, dobu náběhu, počet opakování smyčky a dobu trvání. Skupiny vláken se můžou 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:

V textovém editoru vytvořte soubor LoadTest.jmx 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í. 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">
                <!-- Azure Event Hub connection configuration using Managed Identity (see repository for instructions) -->
                <boolProp name="useManagedIdentity">true</boolProp>
                <stringProp name="eventHubNamespace">telemetry-ehn.servicebus.windows.net</stringProp>
                <stringProp name="eventHubName">telemetry-data-changed-eh</stringProp>
                <stringProp name="liquidTemplateFileName">StreamingDataTemplate.liquid</stringProp>
            </com.microsoft.eventhubplugin.EventHubPlugin>
        </hashTree>
    </hashTree>
    </hashTree>
</jmeterTestPlan>

Implementace com.microsoft.eventhubplugin.EventHubPluginGui a com.microsoft.eventhubplugin.EventHubPlugin je k dispozici v ukázkách Azure.

V souboru nastavte hodnoty připojení služby Event Hubs pomocí přiřazené spravované identity spouštěčů testů. Tato identita musí mít oprávnění k zápisu pro instanci Event Hubs.
V souboru nastavte hodnotu eventHubName uzlu na název centra událostí, například telemetry-data-changed-eh.
Nastavte hodnotu liquidTemplateFileName uzlu na soubor, který obsahuje zprávu poslanou 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, který má tři vlastnosti, MachineId, Temperature a Humidity. MachineId je náhodně vygenerované ID, které má délku 27 znaků a TemperatureHumidity 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 poskytují výkonný a flexibilní způsob vytváření dynamických a přizpůsobitelných zpráv.
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ů zátěžového testu. Ukázka šablony liquid spolu se souborem skriptu JMeter je k dispozici ke stažení na ukázkách Azure.

Aktualizace vlastního pluginu z Event Hubs na IoT Hub

Vlastní modul plug-in používá službu Event Hubs jako primární cílový prostředek. Následující konfigurace je nastavení klienta sady SDK pro službu Event Hubs:

EventHubProducerClient producer = null;
EventHubClientBuilder producerBuilder = new EventHubClientBuilder();

producerBuilder.credential(getEventHubNamespace(), getEventHubName(), new DefaultAzureCredentialBuilder().build());
producer = producerBuilder.buildProducerClient();

EventDataBatch batch = producer.createBatch(new CreateBatchOptions());
batch.tryAdd(new EventData(msg));
producer.send(batch);

Následující příklad ukazuje, jak můžete použít stejné řešení, přidat závislosti IoT a změnit klienta sady SDK tak, aby používal IoT Hub:

IotHubServiceClientProtocol protocol = IotHubServiceClientProtocol.AMQPS;
ServiceClient client = new ServiceClient(getIoTHostName(), new DefaultAzureCredentialBuilder().build(), protocol);
client.open();

Message message = new Message(msg);
client.send(getDeviceName(), message);

client.close();

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

Když zátěžové testování spustí zátěžový test, nejprve nasadí skript JMeter spolu se všemi ostatními soubory do instancí testovacího modulu. Před spuštěním testu přejděte na kartu parametru a definujte a nastavte požadované parametry. Další informace naleznete v tématu Přizpůsobení zátěžového testu pomocí modulů plug-in Apache JMeter a zátěžového testování.

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

Pro testování výkonu je důležité, aby testovací prostředí bylo podobné produkčnímu prostředí. V tomto příkladu se k testování výkonu používá následující prostředí k lepšímu pochopení kapacity a výkonu systému.

Služba	Konfigurace
Centra událostí	Premium s jednou jednotkou zpracování
Azure Functions	Linux s plánem Premium (EP1) – 210 ACU, 3,5 GB paměti a 1 vCPU ekvivalent Standard_D1_v2
Kraj	USA – východ

Volba správné úrovně služby pro libovolnou službu 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 Event Hubs a ceny služby Functions.

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

Než budete moct navrhnout klíčové ukazatele výkonu pro testování výkonu, musíte definovat obchodní požadavky a architekturu systému. Obchodní požadavky vám řeknou, které klíčové ukazatele výkonu, jako je doba odezvy, propustnost nebo míra chyb, které chcete měřit. 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.

Tento příklad má následující obchodní požadavky:

Systém dokáže zpracovat 1 000 požadavků za sekundu.
Spolehlivost systému je vyšší než 0,99.
Systém dokáže zpracovat 1 000 souběžných zařízení, která hlásí telemetrická data.
Maximální kapacitu systému můžete určit z hlediska počtu zařízení, která může podporovat. Systém může například podporovat 1 000 souběžných zařízení se třikrát aktuální kapacitou.

Pokud chcete změřit, jestli systém splňuje tyto požadavky, můžete k testování výkonu použít následující klíčové ukazatele výkonu:

klíčový indikátor výkonnosti	Popis
RPS	Žádosti 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 volání funkcí nebo rychlost příjmu dat
RT	Průměrný čas běhu pro Azure Functions
AMU	Průměrné využití paměti pro Azure Functions
SR	Míra úspěšnosti všech vyvolání funkčních aplikací
ARS	Průměrná doba odezvy podřízené služby pro služby, jako je SQL Server nebo mikroslužba
DF	Počet selhání závislostí, včetně chyb interní funkční aplikace
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. Tento příklad používá následující strategii 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. Zátěžové testování může měřit RPS a LOAD.
Azure Functions: Přístup k testování výkonu pro Funkce spočívá v měření následujících metrik.
- IR
- RT
- AMU
- SR
- ARS
- DF

Azure Monitor může měřit AMU, ARS a DF, ale ne IR, RT nebo SR. Pokud chcete měřit klíčové ukazatele výkonu pomocí služby Azure Monitor, povolte 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

Následující obrázek ukazuje ukázku řídicího panelu služby Azure Monitor. Zobrazuje klíčové ukazatele výkonu pro Azure Functions na základě předchozích dotazů.

Přispěvatelé

Microsoft udržuje tento článek. Tento článek napsali následující přispěvatelé.

Hlavní autoři:

Mahdi Setayesh | Hlavní softwarový inženýr
Oscar Fimbres | Vedoucí softwarový inženýr

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

Další kroky

Váš názor

Byla tato stránka užitečná?

Poslední aktualizace v 2026-04-21