Dela via

Azure Load Testing med anpassade plugin-program

  • Artikel

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. Artikeln förutsätter att du känner till JMeter, dess plugin-program och anpassade plugin-program samt Azure Functions och Event Hubs.

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, var och en med 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.

Testplanen kan också innehålla flera testfall, var och en med olika inställningar och konfigurationer. I vårt fall antar vi att det finns en enhet som rapporterar temperatur och luftfuktighet under en viss tidsperiod. Enheten skickar data till en händelsehubb i Azure. Händelsehubben utlöser en Azure-funktion som ansvarar för att bearbeta data och sedan skicka data till andra underordnade tjänster, till exempel Azure SQL Database. Azure-funktionen är den tjänst som vi vill testa. Testplanen är utformad för att simulera enhetens beteende och skicka data till händelsehubben.

Diagram över en exempelarkitektur för belastningstestning.

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

Dataflöde

I det här exemplet är dataflödet följande:

  1. En simulerad enhet skickar data till en händelsehubb via Azure Load Testing-agenten. Alla beteenden på enheten kan simuleras med hjälp av anpassade JMeter-plugin-program. Azure Load Test-agenten ansvarar för att skicka data till händelsehubben efter att ha kört det anpassade plugin-programmet för alla typer av simulerade enheter.
  2. Händelsehubben utlöser en Azure-funktion som ansvarar för att bearbeta data och sedan skicka data till andra underordnade tjänster, till exempel Azure SQL Database och Azure Digital Twins.
  3. Azure Monitor-tjänsten används för att övervaka Azure Function och Event Hubs.
  4. Azure Load Testing-tjänsten samlar in data från Azure Monitor-tjänsten och visar dem sedan på en instrumentpanel.

Komponenter

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

  • Azure Load Testing: Med Azure Load Testing kan du köra Apache JMeter-skript och anpassade plugin-program för att simulera användar- och enhetsbeteenden. Det tillhandahåller ett webbaserat gränssnitt för att hantera och köra belastningstester och en uppsättning API:er som kan användas för att automatisera processen. Azure Load Testing är en fullständigt hanterad tjänst, vilket innebär att du inte behöver bekymra dig om att hantera servrar eller infrastruktur. Du kan ladda upp dina JMeter-skript och anpassade plugin-program, och Azure Load Testing hanterar resten.
  • Azure Event Hubs: Azure Event Hubs är en molnbaserad händelsebearbetningstjänst som kan användas 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, MQTT (Message Queuing Telemetry Transport) och AMQP över WebSockets. Att välja rätt protokoll beror på flera faktorer, inklusive vilken typ av data du arbetar med, de specifika kraven för ditt program och funktionerna och begränsningarna i själva protokollen.
  • Azure Functions: Azure Functions är en serverlös beräkningstjänst som gör att du kan 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. Azure Functions kan användas för att bearbeta händelser och strömma data från Event Hubs, samt andra källor som Azure Storage och Azure Cosmos DB.
  • 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. Den utvecklades ursprungligen för testning av webbprogram. Men det kan också användas 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. Det gör att du kan övervaka prestanda och hälsa för dina program och den underliggande infrastrukturen också. Azure Monitor kan användas för att övervaka Event Hubs och Azure Functions, samt andra Azure-tjänster som Azure Storage och Azure Cosmos DB.

Information om scenario

Med Azure Load Testing kan du ta ett befintligt Apache JMeter-skript och använda det för att 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, vilket gör det möjligt för testare att identifiera potentiella flaskhalsar i prestanda eller andra problem som kan uppstå under stora belastningar. JMeter kan användas 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, var och en med olika inställningar och konfigurationer. Testare kan också anpassa JMeter med hjälp av plugin-program eller genom att skriva anpassad kod, så att de kan utöka sina funktioner utöver vad som kommer ut ur rutan. Plugin-program kan hjälpa oss 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 det kan finnas specifika användningsfall eller krav som inte omfattas av de inbyggda funktionerna. 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

Ett anpassat plugin-program kan till exempel utvecklas för att simulera en viss typ av användarbeteende eller för att generera mer realistiska testdata. Dessutom kan anpassade plugin-program utvecklas för att integrera JMeter med andra verktyg eller system, till exempel loggnings- och rapporteringsverktyg eller pipelines för kontinuerlig integrering och 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. På det hela taget gör de 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 antar vi att det finns en enhet som rapporterar temperatur och luftfuktighet under en viss tidsperiod. Vi kan simulera det här enkla beteendet med hjälp av ett anpassat JMeter-plugin-program. I den aktuella implementeringen av det anpassade plugin-programmet som tillhandahålls här genererar vi slumpmässiga data med hjälp av en angivet 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-funktion som ansvarar för att bearbeta data och sedan skicka data till andra underordnade tjänster, till exempel Azure SQL Database. Azure-funktionen är den tjänst som vi vill testa. Testplanen är utformad för att simulera enhetens beteende och skicka data till händelsehubben.

Potentiella användningsfall

Användning av Azure Load Testing 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 eller generera mer realistiska testdata.

Anpassade plugin-program

Anpassade plugin-program i JMeter-kontexten är programvarukomponenter som kan läggas till i JMeter för att utöka dess funktioner utöver vad som kommer ut ur rutan. Användare eller icke-Microsoft-utvecklare kan utveckla anpassade plugin-program för att lägga till nya funktioner, funktioner eller integreringar i JMeter. Anpassade plugin-program kan utvecklas med java-programmeringsspråket och JMeter Plugin Development Kit (PDK). PDK innehåller en uppsättning verktyg och API:er som gör det enklare att skapa nya plugin-program, inklusive GUI-element, lyssnare och provtagare.

Anpassade plugin-program kan lägga till en mängd olika funktioner i JMeter. De kan också integrera JMeter med andra system, till exempel loggnings- och rapporteringsverktyg, eller aktivera användning av andra datakällor för testdata. Med anpassade plugin-program kan användarna utöka JMeter för att uppfylla sina specifika behov och förbättra noggrannheten och effektiviteten i belastningstestningsarbetet.

Om du vill implementera en anpassad sampler för Event Hubs i JMeter följer du anvisningarna i Plugin-programmet för Azure Load Testing. När din anpassade provtagare har implementerats kan du använda den i din JMeter-testplan i Azure Load Test precis som alla andra provtagare.

En testplan kan implementeras med hjälp av en trådgrupp som styr antalet trådar (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 antingen 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 exempel kan vara kraftfulla verktyg i JMeter, så att du kan simulera komplexa scenarier och begäranden som de inbyggda proverna inte stöder.

Skapa ett Apache JMeter-skript med 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:

  1. Skapa en LoadTest.jmx-fil på den lokala datorn:

    touch LoadTest.jmx

  2. Öppna LoadTest.jmx 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 och 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">
            <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>

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

  3. I filen anger du värdet eventHubConnectionVarName för noden till variabelnamnet som anger Event Hubs anslutningssträng värd. Om du till exempel vill att miljövariabeln som lagrar anslutningssträng för Event Hubs ska vara EventHubConnectionStringanger du den här variabeln till EventHubConnectionString och anger sedan värdet för miljövariabeln.

    Viktigt!

    Kontrollera att värdet EventHubConnectionString för har angetts som en del av processen för att skapa Azure-belastningstest innan du kör belastningstestskriptet.

  4. I filen anger du värdet eventHubName för noden till händelsehubbens namn, till exempel telemetry-data-changed-eh.

  5. Ange värdet för liquidTemplateFileName noden till filen 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 med tre egenskaper, inklusive MachineId, Temperatureoch Humidity där MachineId är ett slumpmässigt genererat ID med längden 27 och Temperature är Humidity slumpmässiga heltal som är mindre än 100. Den här filen är en flytande mallsyntax. Liquid-mallen ä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. Sammantaget erbjuder Liquid-mallar ett kraftfullt och flexibelt sätt att skapa dynamiska, anpassningsbara meddelanden.

  6. Spara och stäng filen.

    Viktigt!

    Ta inte med några personuppgifter i exempelnamnet i JMeter-skriptet. Exempelnamnen visas på instrumentpanelen för Testresultat för Azure Load Testing. Ett exempel på en flytande mall tillsammans med JMeter-skriptfilen finns att ladda ned i Azure Samples

Kör belastningstestet med hjälp av ett nytt plugin-program

När Azure Load Testing startar belastningstestet distribuerar det först JMeter-skriptet tillsammans med alla andra filer till testmotorinstanser och startar sedan belastningstestet enligt anvisningarna i Anpassa ett belastningstest med Apache JMeter-plugin-program och Azure Load Testing. Innan du kör testet går du till fliken parameter, definierar EventHubConnectionStringoch anger sedan anslutningssträng till händelsehubben.

Skärmbild som visar testparametrarna.

Konfiguration av prestandatestning för miljön

I alla prestandatester är det viktigt att ha en liknande miljö som 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 systemets prestanda.

Enligt exempelarkitekturen kan följande tjänster användas för prestandatestning:

Tjänst Konfiguration
Eventhub Premium med en bearbetningsenhet (PU).
Azure-funktion Linux med Premium-plan (EP1) – 210 ACU, 3,5 GB minne och 1 vCPU-motsvarighet Standard_D1_v2
Region USA, östra

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 Azure Event Hubs och Priser för Azure Functions.

Utforma KPI:er för prestandatestning

Innan du kan utforma KPI:er (Key Performance Indicators) för prestandatestning behöver du två saker: affärskraven och systemarkitekturen. Affärskraven anger vilka KPI:er du vill mäta, till exempel svarstid, dataflöde eller felfrekvens. 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.

I det här exemplet är affärskraven:

  • Systemet bör kunna hantera 1 000 begäranden per sekund.
  • Systemets tillförlitlighet bör vara högre än 0,99.
  • Systemet bör kunna hantera 1 000 samtidiga enheter som rapporterar sina personuppgifter.
  • Ange systemets maximala kapacitet när det gäller antalet enheter som kan stödjas. Kan till exempel systemet med 3x av den aktuella kapaciteten stödja 1 000 samtidiga enheter?

Enligt dessa krav kan KPI:er för prestandatestning vara:

KPI beskrivning
RPS Begäran per sekund för en händelsehubb
LAST Antal belastningar eller begäranden som skickas till händelsehubben under prestandatestning
IR Antal funktionskörningar eller inmatningshastighet
RT Genomsnittlig tid för Körningstid för Azure-funktion
AMU Genomsnittlig minnesanvändning för Azure Functions
SR Lyckad frekvens för alla funktionskörningar
ARS Genomsnittlig svarstid för nedströmstjänsten (till exempel SQL-server eller en mikrotjänst)
DF Antal beroendefel inklusive interna Azure-funktionsfel
MRPS MaximalT antal RPS utan kvarvarande uppgifter i händelsehubben (systemkapacitet)

Så här mäter du 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. Azure Load Testing-tjänsten kan mäta RPS och LOAD.
  • Azure Functions: Prestandatestningsmetoden för Azure Functions är att mäta följande mått:
    • IR är antalet funktionskörningar eller inmatningshastighet.
    • RT är den genomsnittliga tiden för Körningstid för Azure-funktion.
    • AMU är den genomsnittliga minnesanvändningen för Azure Functions.
    • SR är framgångsgraden för alla funktionskörningar.
    • ARS är den genomsnittliga nedströmstjänstens svarstid.
    • DF är antalet beroendefel, inklusive interna Azure-funktionsfel.
    • Azure Monitor-tjänsten kan mäta AMU, ARS och DF, men inte IR, RT eller SR.

För att kunna mäta KPI:er med hjälp av Azure Monitor-tjänsten måste vi aktivera Application Insights för Azure Functions. Mer information finns i Aktivera Application Insights-integrering.

När du har aktiverat Azure Monitor-tjänsten 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

Här är ett exempel på Azure Monitor-instrumentpanelen som visar KPI:er för Azure Functions baserat på frågorna:

Skärmbild av exempel på Azure Monitor-instrumentpanelen.

Slutsats

I den här artikeln har du lärt dig hur du utformar KPI:er och utvecklar en instrumentpanel för Azure Load Test. Du har också lärt dig hur du använder anpassade plugin-program i JMeter för att utföra belastningstestning på Azure Functions som är integrerat med Event Hubs. Du kan använda samma metod för att utföra belastningstestning på andra Azure-tjänster. Du kan också konfigurera en CI/CD-pipeline (kontinuerlig integrering och leverans) för dina belastningstestskript med hjälp av Azure DevOps.

Mer information finns i Azure Load Testing.

Deltagare

Den här artikeln underhålls av Microsoft. Det har ursprungligen skrivits av följande medarbetare.

Huvudförfattare:

Om du vill se icke-offentliga LinkedIn-profiler loggar du in på LinkedIn.

Nästa steg