Azure Load Testing met aangepaste invoegtoepassingen

Artikel
01/27/2024

Oplossingsideeën

In dit artikel wordt een oplossingsidee beschreven. Uw cloudarchitect kan deze richtlijnen gebruiken om de belangrijkste onderdelen te visualiseren voor een typische implementatie van deze architectuur. Gebruik dit artikel als uitgangspunt om een goed ontworpen oplossing te ontwerpen die overeenkomt met de specifieke vereisten van uw workload.

Deze oplossing biedt richtlijnen voor het gebruik van Azure Load Testing, een service waarmee u Apache JMeter-scripts en aangepaste invoegtoepassingen kunt uitvoeren om gebruikers- en apparaatgedrag te simuleren. In deze oplossing wordt ook uitgelegd hoe u KPI's (Key Performance Indicators) ontwerpt en een dashboard ontwikkelt voor het bewaken en analyseren van de resultaten van de belastingstest in een voorbeeldtoepassing met Azure Functions en Azure Event Hubs. In het artikel wordt ervan uitgegaan dat u bekend bent met JMeter, de invoegtoepassingen en aangepaste invoegtoepassingen, evenals Azure Functions en Event Hubs.

Architectuur

Voor het uitvoeren van belastingstests hebt u een testplan nodig. Dit is een set instructies die JMeter vertelt wat u moet doen tijdens de test. Het testplan kan meerdere testscenario's bevatten, elk met verschillende instellingen en configuraties. U hebt bijvoorbeeld één scenario dat één gebruiker simuleert die toegang heeft tot een webtoepassing en een ander scenario dat meerdere gebruikers simuleert die tegelijkertijd toegang hebben tot dezelfde toepassing.

Het testplan kan ook meerdere testcases bevatten, elk met verschillende instellingen en configuraties. In ons geval gaan we ervan uit dat er een apparaat is dat gedurende een bepaalde periode temperatuur en vochtigheid rapporteert. Het apparaat verzendt de gegevens naar een Event Hub in Azure. De Event Hub activeert een Azure-functie die verantwoordelijk is voor het verwerken van de gegevens en verzendt vervolgens gegevens naar andere downstreamservices, zoals Azure SQL Database. De Azure-functie is de service die we willen testen. Het testplan is ontworpen om het gedrag van het apparaat te simuleren en gegevens naar de Event Hub te verzenden.

Een Visio-bestand van deze architectuur downloaden.

Gegevensstroom

In dit voorbeeld is de gegevensstroom als volgt:

Een gesimuleerd apparaat verzendt gegevens naar een Event Hub via de Azure Load Testing-agent. Elk gedrag van het apparaat kan worden gesimuleerd met behulp van aangepaste JMeter-invoegtoepassingen. De Azure Load Test-agent is verantwoordelijk voor het verzenden van gegevens naar de Event Hub nadat de aangepaste invoegtoepassing is uitgevoerd voor alle typen gesimuleerde apparaten.
De Event Hub activeert een Azure-functie die verantwoordelijk is voor het verwerken van de gegevens en verzendt vervolgens gegevens naar andere downstreamservices, zoals Azure SQL Database en Azure Digital Twins.
De Azure Monitor-service wordt gebruikt om de Azure-functie en Event Hubs te bewaken.
De Azure Load Testing-service verzamelt de gegevens van de Azure Monitor-service en geeft deze vervolgens weer in een dashboard.

Onderdelen

In dit voorbeeld worden de volgende onderdelen gebruikt:

Azure Load Testing: Met Azure Load Testing kunt u Apache JMeter-scripts en aangepaste invoegtoepassingen uitvoeren om gedrag van gebruikers en apparaten te simuleren. Het biedt een webinterface voor het beheren en uitvoeren van belastingstests en een set API's die kunnen worden gebruikt om het proces te automatiseren. Azure Load Testing is een volledig beheerde service, wat betekent dat u zich geen zorgen hoeft te maken over het beheren van servers of infrastructuur. U kunt uw JMeter-scripts en aangepaste invoegtoepassingen uploaden en Azure Load Testing verwerkt de rest.
Azure Event Hubs: Azure Event Hubs is een cloudservice voor gebeurtenisverwerking die kan worden gebruikt voor het verzamelen, verwerken en analyseren van gebeurtenissen en streaminggegevens uit verschillende bronnen in realtime. Event Hubs ondersteunt meerdere protocollen, waaronder AMQP (Advanced Message Queuing Protocol), HTTPS, Kafka Protocol, MQTT (Message Queuing Telemetry Transport) en AMQP via WebSockets. Het kiezen van het juiste protocol is afhankelijk van verschillende factoren, waaronder het type gegevens waarmee u werkt, de specifieke vereisten van uw toepassing en de mogelijkheden en beperkingen van de protocollen zelf.
Azure Functions: Azure Functions is een serverloze rekenservice waarmee u code kunt uitvoeren zonder servers of infrastructuur te hoeven beheren. Het ondersteunt meerdere programmeertalen, waaronder C#, F#, Java, JavaScript, PowerShell, Python en TypeScript. Azure Functions kan worden gebruikt om gebeurtenissen en streaminggegevens van Event Hubs te verwerken, evenals andere bronnen, zoals Azure Storage en Azure Cosmos DB.
JMeter-GUI: JMeter-GUI is een opensource-hulpprogramma voor belastingstests dat voornamelijk wordt gebruikt om de prestaties van webtoepassingen te testen. Het is oorspronkelijk ontwikkeld voor het testen van webtoepassingen. Het kan echter ook worden gebruikt om andere soorten toepassingen te testen, zoals SOAP- en REST-webservices, FTP-servers en databases.
Azure Monitor: Azure Monitor biedt bewakings- en waarschuwingsmogelijkheden voor Azure-resources. Hiermee kunt u ook de prestaties en status van uw toepassingen en de onderliggende infrastructuur bewaken. Azure Monitor kan worden gebruikt om Event Hubs en Azure Functions te bewaken, evenals andere Azure-services, zoals Azure Storage en Azure Cosmos DB.

Scenariodetails

Met Azure Load Testing kunt u een bestaand Apache JMeter-script gebruiken om een belastingstest uit te voeren op cloudschaal op elke Azure-resource.

Met JMeter kunnen testers belastingstests, stresstests en functionele tests maken en uitvoeren. Het simuleert meerdere gebruikers tegelijk toegang tot een webtoepassing, waardoor testers mogelijke prestatieknelpunten of andere problemen kunnen identificeren die zich kunnen voordoen onder zware belasting. JMeter kan worden gebruikt om verschillende metrische prestatiegegevens te meten, zoals reactietijd, doorvoer en foutsnelheid.

JMeter maakt gebruik van een gui-gebaseerde interface waarmee gebruikers testplannen kunnen maken, waaronder meerdere testscenario's, elk met verschillende instellingen en configuraties. Testers kunnen JMeter ook aanpassen met behulp van invoegtoepassingen of door aangepaste code te schrijven, zodat ze de functionaliteit kunnen uitbreiden buiten wat er uit de doos komt. De invoegtoepassingen kunnen ons helpen om te werken met services die gebruikmaken van niet-HTTP-protocollen, zoals AMQP en Websocket.

Hoewel JMeter een breed scala aan functies en functies biedt voor belastingstests, zijn er mogelijk specifieke gebruiksscenario's of vereisten die niet worden gedekt door de ingebouwde functionaliteit. Door aangepaste invoegtoepassingen te ontwikkelen, kunnen testers nieuwe functionaliteit toevoegen of bestaande functies aanpassen aan hun behoeften

Een aangepaste invoegtoepassing kan bijvoorbeeld worden ontwikkeld om een specifiek type gebruikersgedrag te simuleren of om realistischere testgegevens te genereren. Daarnaast kunnen aangepaste invoegtoepassingen worden ontwikkeld om JMeter te integreren met andere hulpprogramma's of systemen, zoals hulpprogramma's voor logboekregistratie en rapportage of continue integratie en implementatiepijplijnen. De aangepaste invoegtoepassingen kunnen het testproces stroomlijnen en het eenvoudiger maken om belastingstests op te nemen in de algehele werkstroom voor softwareontwikkeling. Over het algemeen kunnen testers JMeter aanpassen aan hun specifieke behoeften en de nauwkeurigheid en effectiviteit van hun belastingtests verbeteren.

In dit voorbeeld wordt ervan uitgegaan dat er een apparaat is dat gedurende een bepaalde periode temperatuur en vochtigheid rapporteert. We kunnen dit eenvoudige gedrag simuleren met behulp van een aangepaste JMeter-invoegtoepassing. In de huidige implementatie van de hier opgegeven aangepaste invoegtoepassing genereren we een willekeurige gegevens met behulp van een opgegeven sjabloon. De invoegtoepassing kan echter elk mogelijk complex gedrag voor alle apparaten bevatten. In dit voorbeeld verzendt het apparaat de gegevens naar een Event Hub in Azure. De Event Hub activeert een Azure-functie die verantwoordelijk is voor het verwerken van de gegevens en verzendt vervolgens gegevens naar andere downstreamservices, zoals Azure SQL Database. De Azure-functie is de service die we willen testen. Het testplan is ontworpen om het gedrag van het apparaat te simuleren en gegevens naar de Event Hub te verzenden.

Potentiële gebruikscases

Het gebruik van Azure Load Testing met aangepaste invoegtoepassingen kan handig zijn in verschillende scenario's, zoals:

Test de prestaties van een toepassing die gebruikmaakt van niet-HTTP-protocollen, zoals AMQP en Websocket.
Test de prestaties van een toepassing die gebruikmaakt van een aangepast protocol.
Test de prestaties van een toepassing die gebruikmaakt van een niet-Microsoft SDK.
Simuleren van een specifiek type gebruikers- of apparaatgedrag of het genereren van realistischere testgegevens.

Aangepaste invoegtoepassingen

Aangepaste invoegtoepassingen in de context van JMeter zijn softwareonderdelen die kunnen worden toegevoegd aan JMeter om de functionaliteit uit te breiden buiten wat er uit de doos komt. Gebruikers of niet-Microsoft-ontwikkelaars kunnen aangepaste invoegtoepassingen ontwikkelen om nieuwe functies, functies of integraties toe te voegen aan JMeter. Aangepaste invoegtoepassingen kunnen worden ontwikkeld met java-programmeertaal en de JMeter Plugin Development Kit (PDK). De PDK biedt een set hulpprogramma's en API's waarmee u eenvoudiger nieuwe invoegtoepassingen kunt maken, waaronder GUI-elementen, listeners en samplers.

Aangepaste invoegtoepassingen kunnen een breed scala aan functionaliteit toevoegen aan JMeter. Ze kunnen JMeter ook integreren met andere systemen, zoals hulpprogramma's voor logboekregistratie en rapportage, of het gebruik van andere gegevensbronnen inschakelen voor testgegevens. Over het algemeen kunnen gebruikers met aangepaste invoegtoepassingen JMeter uitbreiden om aan hun specifieke behoeften te voldoen en de nauwkeurigheid en effectiviteit van hun belastingstests te verbeteren.

Als u een aangepaste sampler voor Event Hubs in JMeter wilt implementeren, volgt u de instructies in Azure Load Testing Plugins. Zodra uw aangepaste sampler is geïmplementeerd, kunt u deze gebruiken in uw JMeter-testplan in Azure Load Test, net als elke andere sampler.

Een testplan kan worden geïmplementeerd met behulp van een threadgroep waarmee het aantal threads (virtuele gebruikers en apparaten) wordt bepaald om een specifiek scenario uit te voeren. Elke threadgroep kan verschillende instellingen hebben voor het aantal threads, het aantal threads, het aantal loops en de duur. Threadgroepen kunnen opeenvolgend of parallel worden uitgevoerd, afhankelijk van de configuratie van het testplan en de toepassingsvereisten. U kunt de sampler toevoegen aan een threadgroep, de parameters instellen en zo nodig configureren. Aangepaste samplers kunnen krachtige hulpprogramma's in JMeter zijn, zodat u complexe scenario's en aanvragen kunt simuleren die de ingebouwde samplers niet ondersteunen.

Een Apache JMeter-script maken met aangepaste invoegtoepassing

In deze sectie maakt u een voorbeeld van een JMeter-testscript om een toepassing te testen met Event Hubs.

Een voorbeeld van een JMeter-testscript maken:

Maak een LoadTest.jmx-bestand op uw lokale computer:
```
touch LoadTest.jmx
```

Open LoadTest.jmx in een teksteditor en plak het volgende codefragment in het bestand. Met dit script wordt een belastingstest gesimuleerd van 36 virtuele machines die gelijktijdig gebeurtenissen naar een Event Hub verzenden. Het duurt tien minuten om het volgende te voltooien:

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

De implementatie van com.microsoft.eventhubplugin.EventHubPluginGui en com.microsoft.eventhubplugin.EventHubPlugin zijn beschikbaar in Azure Samples.

Stel in het bestand de waarde van het eventHubConnectionVarName knooppunt in op de naam van de variabele waarmee Event Hubs verbindingsreeks host wordt opgegeven. Als u bijvoorbeeld wilt dat de omgevingsvariabele waarin de verbindingsreeks van Event Hubs wordt EventHubConnectionStringopgeslagen, stelt u deze variabele EventHubConnectionString in op en stelt u vervolgens de waarde van de omgevingsvariabele in.

Belangrijk

Zorg ervoor dat de waarde is EventHubConnectionString ingesteld als onderdeel van het maken van een Azure-belastingtest voordat u het script voor de belastingtest uitvoert.
Stel in het bestand de waarde van het eventHubName knooppunt in op de naam van de Event Hub, zoals telemetry-data-changed-eh.
Stel de waarde van het liquidTemplateFileName knooppunt in op het bestand met het bericht dat naar de Event Hub wordt verzonden. Maak bijvoorbeeld een bestand met de naam 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 }}
}
```
In dit voorbeeld is de nettolading voor het Event Hub-bericht een JSON-object met drie eigenschappen, waaronder, en waarbij een willekeurig gegenereerde id met de lengte van 27 is en Temperature Humidity willekeurige gehele getallen kleiner dan 100 zijn.MachineId Humidity TemperatureMachineId Dit bestand is een vloeibare sjabloonsyntaxis. Liquid-sjabloon is een populaire sjabloontaal die wordt gebruikt in verschillende frameworks voor webontwikkeling. Met liquide sjablonen kunnen ontwikkelaars dynamische inhoud maken die eenvoudig kan worden bijgewerkt en gewijzigd. Hiermee kunt u variabelen, voorwaarden, lussen en andere dynamische elementen invoegen in uw Event Hub-berichten. De syntaxis is eenvoudig en er zijn tal van online bronnen beschikbaar om u te helpen aan de slag te gaan. Over het algemeen bieden Liquid-sjablonen een krachtige en flexibele manier om dynamische, aanpasbare berichten te maken.
Sla het bestand op en sluit het bestand.

Belangrijk

Neem geen persoonlijke gegevens op in de naam van de sampler in het JMeter-script. De namen van de voorbeeldprogramma's worden weergegeven in het dashboard met testresultaten van Azure Load Testing. Er is een voorbeeld van een liquide sjabloon samen met het JMeter-scriptbestand beschikbaar om te downloaden op Azure Samples

De belastingstest uitvoeren met behulp van een nieuwe invoegtoepassing

Wanneer Azure Load Testing uw belastingstest start, wordt eerst het JMeter-script geïmplementeerd, samen met alle andere bestanden op test-engineexemplaren. Vervolgens wordt de belastingtest gestart volgens de instructies bij Het aanpassen van een belastingstest met Apache JMeter-invoegtoepassingen en Azure Load Testing. Voordat u de test uitvoert, gaat u naar het parametertabblad, definieert EventHubConnectionStringu en geeft u de verbindingsreeks op voor de Event Hub.

Installatie van prestatietests voor omgeving

Bij prestatietests is het belangrijk om een vergelijkbare omgeving te hebben als in de productieomgeving. In dit voorbeeld wordt de volgende omgeving gebruikt voor prestatietests om meer inzicht te krijgen in de systeemcapaciteit en de prestaties van het systeem.

Volgens de voorbeeldarchitectuur kunnen de volgende services worden gebruikt voor prestatietests:

Service	Configuratie
Eventhub	Premium met één verwerkingseenheid (PU).
Azure-functie	Linux met Premium-abonnement (EP1) - 210 ACU, 3,5 GB geheugen en 1 vCPU-equivalent Standard_D1_v2
Regio	US - oost

Het kiezen van de juiste servicelaag voor alle Azure-services, waaronder Event Hubs en Azure Functions, is een complex proces en is afhankelijk van veel factoren. Zie prijzen voor Azure Event Hubs en Prijzen van Azure Functions voor meer informatie.

KPI's ontwerpen voor prestatietests

Voordat u KPI's (Key Performance Indicators) voor prestatietests kunt ontwerpen, hebt u twee dingen nodig: de bedrijfsvereisten en de systeemarchitectuur. De bedrijfsvereisten geven aan welke KPI's u wilt meten, zoals reactietijd, doorvoer of foutsnelheid. De systeemarchitectuur vertelt u hoe u de prestaties van elk onderdeel kunt testen, zoals webservers, databases of API's. Het helpt u ook bij het kiezen van de beste strategie voor het testen van prestaties, zoals belastingtests, stresstests of uithoudingsvermogenstests.

In dit voorbeeld zijn de bedrijfsvereisten:

Het systeem moet 1000 aanvragen per seconde kunnen verwerken.
De systeembetrouwbaarheid moet hoger zijn dan 0,99.
Het systeem moet 1000 gelijktijdige apparaten kunnen verwerken die hun persoonlijke gegevens rapporteren.
Het opgeven van de maximale capaciteit van het systeem in termen van het aantal apparaten dat kan worden ondersteund. Kan het systeem bijvoorbeeld met 3x van de huidige capaciteit 1000 gelijktijdige apparaten ondersteunen?

Volgens deze vereisten kunnen de KPI's voor prestatietests het volgende zijn:

KPI	Beschrijving
RPS	Aanvraag per seconde voor een Event Hub
LADEN	Aantal belastingen of aanvragen dat tijdens het testen van de prestaties naar de Event Hub is verzonden
IR	Aantal uitvoeringen van functies of opnamesnelheid
RT	Gemiddelde tijd voor uitvoeringstijd van Azure-functie
AMU	Gemiddeld geheugengebruik voor Azure Functions
SR	Slagingspercentage van alle functie-uitvoeringen
ARS	Gemiddelde reactietijd van downstreamservice (bijvoorbeeld SQL-server of een microservice)
DF	Aantal afhankelijkheidsfouten, inclusief interne Azure-functiefouten
MRPS	Maximum aantal RPS zonder achterstand in de Event Hub (systeemcapaciteit)

KPI's meten

Als u KPI's wilt meten, moet u een strategie voor prestatietests hebben. De strategie definieert de benadering voor prestatietests voor elk onderdeel. In dit voorbeeld wordt de volgende strategie voor prestatietests gebruikt:

Event Hubs: De benadering voor prestatietests voor de Event Hub is om veel berichten naar de Event Hub te verzenden en vervolgens de RPS en LOAD te meten. De RPS is het aantal berichten dat per seconde naar de Event Hub wordt verzonden. De LOAD is het totale aantal berichten dat tijdens de prestatietest naar de Event Hub wordt verzonden. De Azure Load Testing-service kan RPS en LOAD meten.
Azure Functions: De prestatietestbenadering voor Azure Functions is het meten van de volgende metrische gegevens:
- De IR is het aantal functie-uitvoeringen of opnamesnelheid.
- De RT is de gemiddelde tijd voor de uitvoeringstijd van De Azure-functie.
- De AMU is het gemiddelde geheugengebruik voor Azure Functions.
- De SR is het slagingspercentage van alle functie-uitvoeringen.
- De ARS is de gemiddelde reactietijd van de downstreamservice.
- De DF is het aantal afhankelijkheidsfouten, inclusief interne Azure-functiefouten.
- De Azure Monitor-service kan AMU, ARS en DF meten, maar niet IR, RT of SR.

Om KPI's te meten met behulp van de Azure Monitor-service, moeten we Application Insights inschakelen voor Azure Functions. Zie Application Insights-integratie inschakelen voor meer informatie.

Nadat u de Azure Monitor-service hebt ingeschakeld, kunt u de volgende query's gebruiken om KPI's te meten:

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

Voorbeeld van Azure Monitor-dashboard

Hier volgt een voorbeeld van een Azure Monitor-dashboard met de KPI's voor Azure Functions op basis van de query's:

Conclusie

In dit artikel hebt u geleerd hoe u KPI's ontwerpt en een dashboard ontwikkelt voor Azure Load Test. U hebt ook geleerd hoe u aangepaste invoegtoepassingen in JMeter kunt gebruiken om belastingstests uit te voeren op Azure Functions die zijn geïntegreerd met Event Hubs. U kunt dezelfde methode gebruiken om belastingstests uit te voeren op andere Azure-services. U kunt ook een CI/CD-pijplijn (continue integratie en levering) instellen voor uw scripts voor belastingstests met behulp van Azure DevOps.

Zie Azure Load Testing voor meer informatie.

Medewerkers

Dit artikel wordt onderhouden door Microsoft. De tekst is oorspronkelijk geschreven door de volgende Inzenders.

Hoofdauteur:

Mahdi Setayesh | Principal Software Engineer

Als u niet-openbare LinkedIn-profielen wilt zien, meldt u zich aan bij LinkedIn.

Delen via

Azure Load Testing met aangepaste invoegtoepassingen

Architectuur

Gegevensstroom

Onderdelen

Scenariodetails

Potentiële gebruikscases

Aangepaste invoegtoepassingen

Een Apache JMeter-script maken met aangepaste invoegtoepassing

De belastingstest uitvoeren met behulp van een nieuwe invoegtoepassing

Installatie van prestatietests voor omgeving

KPI's ontwerpen voor prestatietests

KPI's meten

Voorbeeld van Azure Monitor-dashboard

Conclusie

Medewerkers

Volgende stappen

Feedback

Aanvullende resources

Delen via

Azure Load Testing met aangepaste invoegtoepassingen

Architectuur

Gegevensstroom

Onderdelen

Scenariodetails

Potentiële gebruikscases

Aangepaste invoegtoepassingen

Een Apache JMeter-script maken met aangepaste invoegtoepassing

De belastingstest uitvoeren met behulp van een nieuwe invoegtoepassing

Installatie van prestatietests voor omgeving

KPI's ontwerpen voor prestatietests

KPI's meten

Voorbeeld van Azure Monitor-dashboard

Conclusie

Medewerkers

Volgende stappen

Verwante resources

Feedback

Aanvullende resources