Azure Load Testing med anpassade plugin-program för Event Hubs och IoT Hub

Lösningsidéer

I den här artikeln beskrivs en lösningsidé. Molnarkitekten kan använda den här vägledningen för att visualisera huvudkomponenterna för en typisk implementering av den här arkitekturen. Använd den här artikeln som utgångspunkt för att utforma en välkonstruerad lösning som överensstämmer med arbetsbelastningens specifika krav.

Den här lösningen ger vägledning för hur du använder Azure Load Testing, en tjänst som låter dig köra Apache JMeter-skript och anpassade plugin-program för att simulera användar- och enhetsbeteenden. Den här lösningen förklarar också hur du utformar KPI:er (Key Performance Indicators) och utvecklar en instrumentpanel för övervakning och analys av resultatet av belastningstestet i ett exempelprogram med Azure Functions och Azure Event Hubs. Det här exemplet använder Event Hubs, men du kan använda samma metod för Azure IoT Hub genom att ändra Event Hubs-klienten till IoT Hub-klienten. Den här artikeln förutsätter att du känner till JMeter, dess plugin-program och anpassade plugin-program samt Functions och Event Hubs.

IoT Hub innehåller fler kärnkomponenter än Event Hubs, inklusive partitioner. Därför gäller metoden för belastningstestning som beskrivs i den här artikeln även för IoT Hub med minimala ändringar.

Arkitektur

För att utföra belastningstestning behöver du en testplan, som är en uppsättning instruktioner som talar om för JMeter vad du ska göra under testet. Testplanen kan innehålla flera testscenarier och varje scenario kan ha olika inställningar och konfigurationer. Du kan till exempel ha ett scenario som simulerar en enskild användare som kommer åt ett webbprogram och ett annat scenario som simulerar flera användare som har åtkomst till samma program samtidigt.

Ladda ned en Visio-fil med den här arkitekturen.

Dataflöde

Följande dataflöde motsvarar föregående diagram:

En simulerad enhet skickar data till en händelsehubb via en lasttestningsagent. Alla beteenden på enheten kan simuleras med hjälp av anpassade JMeter-plugin-program. Lasttestningsagenten skickar data till händelsehubben när den har kört det anpassade plugin-programmet för alla typer av simulerade enheter.
Händelsehubben utlöser en Azure-funktionsapp som bearbetar data och skickar dem till andra underordnade tjänster, till exempel Azure SQL Database och Azure Digital Twins.
Azure Monitor övervakar funktionsappen och Event Hubs.
Belastningstestning samlar in data från Azure Monitor och visar dem på en instrumentpanel.

Komponenter

I det här exemplet används följande komponenter:

Belastningstestning: Använd belastningstestning för att köra Apache JMeter-skript och anpassade plugin-program för att simulera användar- och enhetsbeteenden. Belastningstestning tillhandahåller ett webbaserat gränssnitt för att hantera och köra belastningstester och en uppsättning API:er för att automatisera processen. Belastningstestning är en fullständigt hanterad tjänst, vilket innebär att du inte behöver hantera servrar eller infrastruktur. I den här arkitekturen laddar belastningstester upp JMeter-skripten och anpassade plugin-program, och det är i beräkningsmiljön där skripten körs.
Event Hubs: Event Hubs är en molnbaserad händelsebearbetningstjänst som du kan använda för att samla in, bearbeta och analysera händelser och strömma data från olika källor i realtid. Event Hubs stöder flera protokoll, inklusive AMQP (Advanced Message Queuing Protocol), HTTPS, Kafka Protocol, Message Queuing Telemetry Transport (MQTT) och AMQP via WebSocket. Den här arkitekturen är händelsebaserad, så belastningstestning skickar händelser för att belasta testarbetslasten.
IoT Hub: IoT Hub är en molnbaserad hanterad tjänst som fungerar som en central meddelandehubb för kommunikation mellan ett IoT-program och dess anslutna enheter. Du kan ansluta miljontals enheter och deras serverdelslösningar på ett tillförlitligt och säkert sätt. Nästan vilken enhet som helst kan anslutas till en IoT-hubb. Du kan anpassa den här arkitekturen så att den använder IoT Hub genom att ändra Event Hubs-klienten till IoT Hub-klienten.
Azure Functions: Functions är en serverlös beräkningstjänst som du kan använda för att köra kod utan att behöva hantera servrar eller infrastruktur. Den stöder flera programmeringsspråk, inklusive C#, F#, Java, JavaScript, PowerShell, Python och TypeScript. Den här arkitekturen använder Functions som primär beräkningsnivå. Händelsedata i Event Hubs utlöser och skalar ut funktionsappar.
JMeter GUI: JMeter GUI är ett verktyg för belastningstestning med öppen källkod som främst används för att testa prestanda för webbprogram. Du kan dock också använda den för att testa andra typer av program, till exempel SOAP- och REST-webbtjänster, FTP-servrar och databaser.
Azure Monitor: Azure Monitor tillhandahåller övervaknings- och aviseringsfunktioner för Azure-resurser. Använd den för att övervaka prestanda och hälsa för dina program och den underliggande infrastrukturen. I den här arkitekturen övervakar Azure Monitor hälsotillståndet för Azure-infrastrukturkomponenter under belastningstestet.

Information om scenario

Du kan använda belastningstestning för att tillämpa ett befintligt Apache JMeter-skript och köra ett belastningstest i molnskala på valfri Azure-resurs.

Med JMeter kan testare skapa och köra belastningstester, stresstester och funktionella tester. Den simulerar flera användare som samtidigt har åtkomst till ett webbprogram så att testarna kan identifiera potentiella flaskhalsar i prestanda eller andra problem som kan uppstå under stora belastningar. Du kan använda JMeter för att mäta olika prestandamått, till exempel svarstid, dataflöde och felfrekvens.

JMeter använder ett GUI-baserat gränssnitt för att tillåta användare att skapa testplaner, som kan innehålla flera testscenarier som har olika inställningar och konfigurationer. Testare kan också anpassa JMeter med hjälp av plugin-program eller genom att skriva anpassad kod. Plugin-program kan hjälpa användare att arbeta med tjänster som använder icke-HTTP-protokoll, till exempel AMQP och WebSocket.

JMeter tillhandahåller en mängd olika funktioner för belastningstestning, men den inbyggda funktionen kanske inte omfattar specifika användningsfall eller krav. Genom att utveckla anpassade plugin-program kan testare lägga till nya funktioner eller anpassa befintliga funktioner för att bättre passa deras behov.

Du kan till exempel utveckla ett anpassat plugin-program för att simulera en viss typ av användarbeteende eller generera mer realistiska testdata. Du kan också utveckla anpassade plugin-program för att integrera JMeter med andra verktyg eller system, till exempel loggnings- och rapporteringsverktyg eller CI/CD-pipelines (kontinuerlig integrering och kontinuerlig distribution). De anpassade plugin-program kan hjälpa till att effektivisera testningsprocessen och göra det enklare att införliva belastningstestning i det övergripande arbetsflödet för programvaruutveckling. De gör det möjligt för testare att skräddarsy JMeter efter deras specifika behov och förbättra noggrannheten och effektiviteten i deras belastningstestningsarbete.

I det här exemplet rapporterar en enhet temperatur och luftfuktighet under en viss tidsperiod. Exemplet simulerar det här beteendet med hjälp av ett anpassat JMeter-plugin-program. Den aktuella implementeringen av det anpassade plugin-programmet genererar slumpmässiga data med hjälp av en angiven mall. Plugin-programmet kan dock innehålla alla möjliga komplexa beteenden för alla enheter. I det här exemplet skickar enheten data till en händelsehubb i Azure. Händelsehubben utlöser en Azure-funktionsapp som bearbetar data och skickar dem till andra underordnade tjänster, till exempel SQL Database. Azure Functions är den tjänst som arkitekturen testar. Testplanen är utformad för att simulera enhetens beteende och skicka data till händelsehubben.

Potentiella användningsfall

Användning av belastningstestning med anpassade plugin-program kan vara användbart i olika scenarier, till exempel:

Testa prestanda för ett program som använder icke-HTTP-protokoll, till exempel AMQP och WebSocket.
Testa prestanda för ett program som använder ett anpassat protokoll.
Testa prestanda för ett program som använder en SDK som inte är microsoft.
Simulera en viss typ av användar- eller enhetsbeteende.
Genererar mer realistiska testdata.

Anpassade plugins

I JMeter är anpassade plugin-program programvarukomponenter som du kan lägga till för att utöka dess standardfunktioner. Anpassade plugin-program lägger till nya funktioner, funktioner eller integreringar i JMeter. Du kan utveckla anpassade plugin-program med hjälp av Programmeringsspråket Java och PDK (JMeter Plugin Development Kit). PDK innehåller en uppsättning verktyg och API:er som hjälper dig att skapa nya plugin-program, inklusive GUI-element, lyssnare och provtagare.

Om du vill implementera en anpassad sampler för Event Hubs i JMeter följer du anvisningarna i plugin-programmet Load Testing JMeter (Belastningstestning av JMeter). När du har implementerat din anpassade sampler kan du använda den i din JMeter-testplan vid belastningstestning precis som andra samplers.

Du kan implementera en testplan med hjälp av en trådgrupp som styr antalet trådar, till exempel virtuella användare och enheter, för att köra ett specifikt scenario. Varje trådgrupp kan ha olika inställningar för antalet trådar, upprampningsperiod, antal loopar och varaktighet. Trådgrupper kan köras sekventiellt eller parallellt, beroende på konfigurationen av testplanen och programkraven. Du kan lägga till exempeltagaren i en trådgrupp, ange dess parametrar och konfigurera den efter behov. Anpassade samplar kan vara kraftfulla verktyg i JMeter som låter dig simulera komplexa scenarier och begäranden som de inbyggda samplarna inte stöder.

Skapa ett Apache JMeter-skript med ett anpassat plugin-program

I det här avsnittet skapar du ett JMeter-exempeltestskript för att läsa in ett program med Event Hubs.

Så här skapar du ett JMeter-exempeltestskript:

Skapa en LoadTest.jmx-fil i en textredigerare och klistra in följande kodfragment i filen. Det här skriptet simulerar ett belastningstest på 36 virtuella datorer som samtidigt skickar händelser till en händelsehubb. Det tar 10 minuter att slutföra.

<?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>

Implementeringen av com.microsoft.eventhubplugin.EventHubPluginGui och com.microsoft.eventhubplugin.EventHubPlugin är tillgängliga i Azure-exempel.

I filen anger du event hubs-anslutningsvärdena med hjälp av den tilldelade hanterade identiteten för testlöparna. Den identiteten måste ha skrivåtkomst till Event Hubs-instansen.
I filen anger du värdet eventHubName för noden till händelsehubbens namn, till exempel telemetry-data-changed-eh.
Ange värdet för liquidTemplateFileName noden till den fil som innehåller meddelandet som skickas till händelsehubben. Skapa till exempel en fil med namnet 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 }}
}
```
I det här exemplet är nyttolasten för händelsehubben ett JSON-objekt som har tre egenskaper, MachineId, Temperatureoch Humidity. MachineId är ett slumpmässigt genererat ID som är 27 tecken långt och TemperatureHumidity är slumpmässiga heltal som är mindre än 100. Den här filen är en flytande mallsyntax. Flytande mall är ett populärt mallspråk som används i olika webbutvecklingsramverk. Med flytande mallar kan utvecklare skapa dynamiskt innehåll som enkelt kan uppdateras och ändras. De gör att du kan infoga variabler, villkor, loopar och andra dynamiska element i dina event hub-meddelanden. Syntaxen är enkel och det finns gott om onlineresurser som hjälper dig att komma igång. Flytande mallar är ett kraftfullt och flexibelt sätt att skapa dynamiska, anpassningsbara meddelanden.
Spara och stäng filen.

Viktigt!

Ta inte med några personuppgifter i testobjektnamnet i JMeter-skriptet. Provtagningsnamnen visas i instrumentpanelen för testresultat av belastningstestet. Ett exempel på en flytande mall tillsammans med JMeter-skriptfilen finns att ladda ned i Azure-exempel.

Uppdatera det anpassade plugin-programmet från Event Hubs till IoT Hub

Det anpassade plugin-programmet använder Event Hubs som primär målresurs. Följande konfiguration är SDK-klientkonfigurationen för 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);

I följande exempel visas hur du kan återanvända samma lösning, lägga till IoT-beroenden och ändra SDK-klienten så att den använder 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();

Kör belastningstestet med hjälp av det nya plugin-programmet

När belastningstestet startar distribuerar det först JMeter-skriptet tillsammans med alla andra filer till testmotorns instanser. Innan du kör testet går du till fliken parameter för att definiera och ange eventuella obligatoriska parametrar. Mer information finns i Anpassa ett belastningstest med Apache JMeter-plugin-program och Belastningstestning.

Konfigurera prestandatestning för miljön

För prestandatestning är det viktigt att testmiljön liknar produktionsmiljön. I det här exemplet används följande miljö för prestandatestning för att bättre förstå systemets kapacitet och prestanda.

Tjänst	Konfiguration
Event Hubs	Premium med en beräkningsenhet
Azure-funktioner	Linux med Premium-plan (EP1) – 210 ACU, 3,5 GB minne och 1 vCPU-motsvarande Standard_D1_v2
Region	Östra USA

Att välja rätt tjänstnivå för alla Azure-tjänster, inklusive Event Hubs och Azure Functions, är en komplex process och beror på många faktorer. Mer information finns i Priser för Event Hubs och Functions-priser.

Utforma KPI:er för prestandatestning

Innan du kan utforma KPI:er för prestandatestning måste du definiera affärskraven och systemarkitekturen. Affärskraven anger vilka KPI:er, till exempel svarstid, dataflöde eller felfrekvens, som du vill mäta. Systemarkitekturen visar hur du testar prestanda för varje komponent, till exempel webbservrar, databaser eller API:er. Det hjälper dig också att välja den bästa strategin för prestandatestning, till exempel belastningstestning, stresstestning eller uthållighetstestning.

Det här exemplet har följande affärskrav:

Systemet kan hantera 1 000 begäranden per sekund.
Systemets tillförlitlighet är högre än 0,99.
Systemet kan hantera 1 000 samtidiga enheter som rapporterar telemetridata.
Du kan ange systemets maximala kapacitet när det gäller antalet enheter som det kan stödja. Systemet kan till exempel ha stöd för 1 000 samtidiga enheter med tre gånger den aktuella kapaciteten.

För att mäta om systemet uppfyller dessa krav kan du använda följande KPI:er för prestandatestning:

KPI	beskrivning
RPS	Begäranden per sekund för en eventhub
LADDA	Antal belastningar eller begäranden som skickas till händelsehubben under prestandatestning
Infrarött	Antal funktionsanrop eller inmatningshastighet
RT	Genomsnittlig tid för Azure Functions-körningstid
AMU	Genomsnittlig minnesanvändning för Azure Functions
SR	Framgångsfrekvens för alla funktionappsanrop
ARS	Genomsnittlig svarstid för underordnade tjänster för tjänster som SQL Server eller en mikrotjänst
DF	Antal beroendefel, inklusive interna funktionsappfel
MRPS	Maximalt antal RPS utan eftersläpning i händelsehubben (systemkapacitet)

Mäta KPI:er

För att mäta KPI:er måste du ha en strategi för prestandatestning. Strategin definierar prestandatestningsmetoden för varje komponent. I det här exemplet används följande strategi för prestandatestning.

Event Hubs: Metoden för prestandatestning för händelsehubben är att skicka många meddelanden till händelsehubben och sedan mäta RPS och LOAD. RPS är antalet meddelanden som skickas till händelsehubben per sekund. LOAD är det totala antalet meddelanden som skickas till händelsehubben under prestandatestningen. Belastningstestning kan mäta RPS och LOAD.
Azure Functions: Metoden för prestandatestning för Functions är att mäta följande mått.
- Infrarött
- RT
- AMU
- SR
- ARS
- DF

Azure Monitor kan mäta AMU, ARS och DF, men inte IR, RT eller SR. Om du vill mäta KPI:er med hjälp av Azure Monitor aktiverar du Application Insights för Azure Functions. Mer information finns i Aktivera Application Insights-integrering.

När du har aktiverat Azure Monitor kan du använda följande frågor för att mäta KPI:er:

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

Exempel på Azure Monitor-instrumentpanel

Följande bild visar ett exempel på Azure Monitor-instrumentpanelen. Den visar KPI:er för Azure Functions baserat på tidigare frågor.

Deltagare

Microsoft ansvarar för denna artikel. Följande deltagare skrev den här artikeln.

Huvudförfattare:

Mahdi Setayesh | Huvudprogramtekniker
Oscar Fimbres | Senior programvarutekniker

Om du vill se linkedin-profiler som inte är offentliga loggar du in på LinkedIn.

Nästa steg

Feedback

Var den här sidan till hjälp?

Uppdaterades senast 2026-04-21