Test di carico di Azure con plug-in personalizzati

Articolo
02/05/2025

Idee per soluzioni

In questo articolo viene descritta un'idea di soluzione. Il cloud architect può usare queste linee guida per visualizzare i componenti principali di un'implementazione tipica di questa architettura. Usare questo articolo come punto di partenza per il design di una soluzione ben progettata che sia in linea con i requisiti specifici del carico di lavoro.

Questa soluzione fornisce indicazioni su come usare test di carico di Azure, un servizio che consente di eseguire script Apache JMeter e plug-in personalizzati per simulare i comportamenti degli utenti e dei dispositivi. Questa soluzione illustra anche come progettare indicatori di prestazioni chiave (KPI) e sviluppare un dashboard per il monitoraggio e l'analisi dei risultati del test di carico in un'applicazione di esempio con Funzioni di Azure e Hub eventi di Azure. L'articolo presuppone che si abbia una certa familiarità con JMeter, i plug-in e i plug-in personalizzati, nonché Funzioni di Azure e Hub eventi.

Architettura

Per eseguire test di carico, è necessario un piano di test, ovvero un set di istruzioni che indica a JMeter cosa eseguire durante il test. Il piano di test può includere più scenari di test, ognuno con impostazioni e configurazioni diverse. Ad esempio, si potrebbe avere uno scenario che simula un singolo utente che accede a un'applicazione Web e un altro scenario che simula più utenti contemporaneamente all'accesso alla stessa applicazione.

Il piano di test può includere anche più test case, ognuno con impostazioni e configurazioni diverse. In questo caso si presuppone che sia presente un dispositivo che segnala temperatura e umidità durante un determinato periodo di tempo. Il dispositivo invia i dati a un hub eventi in Azure. L'hub eventi attiva una funzione di Azure responsabile dell'elaborazione dei dati e quindi dell'invio di dati ad altri servizi downstream, ad esempio database SQL di Azure. La funzione di Azure è il servizio che si vuole testare. Il piano di test è progettato per simulare il comportamento del dispositivo e inviare dati all'hub eventi.

Scaricare un file di Visio di questa architettura.

Flusso di dati

In questo esempio il flusso di dati è il seguente:

Un dispositivo simulato invia dati a un hub eventi tramite l'agente test di carico di Azure. Qualsiasi comportamento del dispositivo può essere simulato usando plug-in personalizzati JMeter. L'agente test di carico di Azure è responsabile dell'invio di dati all'hub eventi dopo l'esecuzione del plug-in personalizzato per qualsiasi tipo di dispositivi simulati.
L'hub eventi attiva una funzione di Azure responsabile dell'elaborazione dei dati e quindi dell'invio di dati ad altri servizi downstream, ad esempio database SQL di Azure e Gemelli digitali di Azure.
Il servizio Monitoraggio di Azure viene usato per monitorare le funzioni di Azure e Hub eventi.
Il servizio Test di carico di Azure raccoglie i dati dal servizio Monitoraggio di Azure e quindi lo visualizza in un dashboard.

Componenti

In questo esempio vengono usati i componenti seguenti:

Test di carico di Azure: Test di carico di Azure consente di eseguire script Apache JMeter e plug-in personalizzati per simulare i comportamenti degli utenti e dei dispositivi. Fornisce un'interfaccia basata sul Web per la gestione e l'esecuzione di test di carico e un set di API che possono essere usate per automatizzare il processo. Test di carico di Azure è un servizio completamente gestito, il che significa che non è necessario preoccuparsi della gestione dei server o dell'infrastruttura. In questa architettura, è la posizione in cui si caricano gli script JMeter e i plug-in personalizzati ed è il calcolo in cui vengono eseguiti tali script.
Hub eventi di Azure: Hub eventi di Azure è un servizio di elaborazione eventi basato sul cloud che può essere usato per raccogliere, elaborare e analizzare eventi e trasmettere dati da varie origini in tempo reale. Hub eventi supporta più protocolli, tra cui AMQP (Advanced Message Queuing Protocol), HTTPS, Kafka Protocol, MQTT (Message Queuing Telemetry Transport) e AMQP su WebSocket. Questa architettura è basata su eventi, quindi Azure Load Testing sta popolando eventi per eseguire test di carico sul carico di lavoro.
Funzioni di Azure: Funzioni di Azure è un servizio di calcolo serverless che consente di eseguire codice senza dover gestire server o infrastruttura. Supporta più linguaggi di programmazione, tra cui C#, F#, Java, JavaScript, PowerShell, Python e TypeScript. Questa architettura usa Funzioni di Azure come livello di calcolo primario. Le Funzioni di Azure vengono attivate e ridimensionate in base ai dati degli eventi negli Hub Eventi di Azure.
GUI di JMeter: JMeter GUI è uno strumento di test del carico open source usato principalmente per testare le prestazioni delle applicazioni Web. È stato originariamente sviluppato per testare le applicazioni Web. Tuttavia, può essere usato anche per testare altri tipi di applicazioni, ad esempio servizi Web SOAP e REST, server FTP e database.
Monitoraggio di Azure: Monitoraggio di Azure offre funzionalità di monitoraggio e avviso per le risorse di Azure. Consente di monitorare anche le prestazioni e l'integrità delle applicazioni e dell'infrastruttura sottostante. In questa architettura, Azure Monitor viene usato per monitorare l'integrità dei componenti dell'infrastruttura di Azure durante il periodo del test di carico.

Dettagli dello scenario

Test di carico di Azure consente di eseguire uno script Apache JMeter esistente e di usarlo per eseguire un test di carico su scala cloud su qualsiasi risorsa di Azure.

JMeter consente ai tester di creare ed eseguire test di carico, test di stress e test funzionali. Simula più utenti contemporaneamente all'accesso a un'applicazione Web, consentendo ai tester di identificare potenziali colli di bottiglia delle prestazioni o altri problemi che potrebbero verificarsi in carichi elevati. JMeter può essere usato per misurare varie metriche delle prestazioni, ad esempio il tempo di risposta, la velocità effettiva e la frequenza degli errori.

JMeter usa un'interfaccia basata su GUI per consentire agli utenti di creare piani di test, che possono includere più scenari di test, ognuno con impostazioni e configurazioni diverse. I tester possono anche personalizzare JMeter usando plug-in o scrivendo codice personalizzato, consentendo loro di estendere la sua funzionalità oltre a ciò che viene fuori dalla scatola. I plug-in possono essere utili per lavorare con i servizi che usano protocolli non HTTP, ad esempio AMQP e WebSocket.

Sebbene JMeter offra un'ampia gamma di funzionalità e funzioni per i test di carico, potrebbero esserci casi d'uso o requisiti specifici che non sono coperti dalle funzionalità predefinite. Sviluppando plug-in personalizzati, i tester possono aggiungere nuove funzionalità o personalizzare le funzionalità esistenti per soddisfare meglio le proprie esigenze

Ad esempio, è possibile sviluppare un plug-in personalizzato per simulare un tipo specifico di comportamento dell'utente o generare dati di test più realistici. Inoltre, è possibile sviluppare plug-in personalizzati per integrare JMeter con altri strumenti o sistemi, ad esempio strumenti di registrazione e creazione di report o pipeline di integrazione e distribuzione continue. I plug-in personalizzati possono semplificare il processo di test e semplificare l'incorporamento dei test di carico nel flusso di lavoro di sviluppo software complessivo. In generale, consentono ai tester di personalizzare JMeter in base alle proprie esigenze specifiche e migliorare l'accuratezza e l'efficacia delle attività di test di carico.

In questo esempio si presuppone che sia presente un dispositivo che segnala temperatura e umidità in un determinato periodo di tempo. È possibile simulare questo comportamento semplice usando un plug-in JMeter personalizzato. Nell'implementazione corrente del plug-in personalizzato fornito qui, vengono generati dati casuali usando un modello fornito. Tuttavia, il plug-in può contenere qualsiasi possibile comportamento complesso per qualsiasi dispositivo. In questo esempio il dispositivo invia i dati a un hub eventi in Azure. L'hub eventi attiva una funzione di Azure responsabile dell'elaborazione dei dati e quindi dell'invio di dati ad altri servizi downstream, ad esempio database SQL di Azure. La funzione di Azure è il servizio che si vuole testare. Il piano di test è progettato per simulare il comportamento del dispositivo e inviare dati all'hub eventi.

Potenziali casi d'uso

L'uso di Test di carico di Azure con plug-in personalizzati può essere utile in vari scenari, ad esempio:

Test delle prestazioni di un'applicazione che usa protocolli non HTTP, ad esempio AMQP e WebSocket.
Test delle prestazioni di un'applicazione che usa un protocollo personalizzato.
Test delle prestazioni di un'applicazione che usa un SDK non Microsoft.
Simulazione di un tipo specifico di comportamento dell'utente o del dispositivo o generazione di dati di test più realistici.

Plug-in personalizzati

I plug-in personalizzati nel contesto di JMeter sono componenti software che possono essere aggiunti a JMeter per estendere la sua funzionalità oltre ciò che viene fuori dalla scatola. Gli utenti o gli sviluppatori non Microsoft possono sviluppare plug-in personalizzati per aggiungere nuove funzionalità, funzioni o integrazioni a JMeter. I plug-in personalizzati possono essere sviluppati usando il linguaggio di programmazione Java e il JMeter Plugin Development Kit (PDK). Il PDK fornisce un set di strumenti e API che consentono di creare nuovi plug-in, inclusi elementi gui, listener e campionatori.

I plug-in personalizzati possono aggiungere un'ampia gamma di funzionalità a JMeter. Possono anche integrare JMeter con altri sistemi, ad esempio strumenti di registrazione e creazione di report, o abilitare l'uso di altre origini dati per i dati di test. Complessivamente, i plug-in personalizzati consentono agli utenti di estendere JMeter per soddisfare le proprie esigenze specifiche e migliorare l'accuratezza e l'efficacia delle attività di test di carico.

Per implementare un campionatore personalizzato per Hub eventi in JMeter, seguire le istruzioni fornite in Plug-in di test di carico di Azure. Dopo l'implementazione del campionatore personalizzato, è possibile usarlo nel piano di test di JMeter nel test di carico di Azure esattamente come qualsiasi altro campionatore.

È possibile implementare un piano di test usando un gruppo di thread che controlla il numero di thread (utenti virtuali e dispositivi) per eseguire uno scenario specifico. Ogni gruppo di thread può avere impostazioni diverse per il numero di thread, il periodo di ramp-up, il numero di cicli e la durata. I gruppi di thread possono essere eseguiti in sequenza o in parallelo, a seconda della configurazione del piano di test e dei requisiti dell'applicazione. È possibile aggiungere l'sampler a un gruppo di thread, impostarne i parametri e configurarlo in base alle esigenze. Gli esempi personalizzati possono essere strumenti potenti in JMeter, consentendo di simulare scenari complessi e richieste non supportate dai campionatori predefiniti.

Creare uno script Apache JMeter con plug-in personalizzato

In questa sezione viene creato uno script di test JMeter di esempio per il test di carico di un'applicazione con Hub eventi.

Per creare uno script di test JMeter di esempio:

Creare un file LoadTest.jmx in un editor di testo e incollare il frammento di codice seguente nel file. Questo script simula un test di carico di 36 macchine virtuali che inviano simultaneamente eventi a un hub eventi e richiede 10 minuti per il completamento:

<?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" estclass="com.microsoft.eventhubplugin.EventHubPlugin" testname="Azure Event Hubs Sampler" enabled="true">
                <!-- Azure Event Hub connection configuration using Managed Identity (see repository for instructions) -->
                <stringProp name="eventHubName">telemetry-data-changed-eh</stringProp>
                <stringProp name="liquidTemplateFileName">StreamingDataTemplate.liquid</stringProp>
            </com.microsoft.eventhubplugin.EventHubPlugin>
        </hashTree>
    </hashTree>
    </hashTree>
</jmeterTestPlan>

L'implementazione di com.microsoft.eventhubplugin.EventHubPluginGui e com.microsoft.eventhubplugin.EventHubPlugin sono disponibili in Esempi di Azure.

Nel file, impostare i valori di connessione dell'Event Hub utilizzando l'identità gestita assegnata dei test runner. Tale identità richiede l'accesso in scrittura all'istanza dell'hub eventi.
Nel file impostare il valore del nodo sul nome dell'hub eventHubName eventi, ad esempio telemetry-data-changed-eh.
Impostare il valore del liquidTemplateFileName nodo sul file contenente il messaggio inviato all'hub eventi. Ad esempio, creare un file denominato StreamingDataTemplate.liquid come:
```
{
    {% 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 questo esempio, il payload per il messaggio dell'hub eventi è un oggetto JSON con tre proprietà, tra cui MachineId, Temperaturee Humidity dove MachineId è un ID generato in modo casuale con la lunghezza di 27 e Temperature sono Humidity numeri interi casuali minori di 100. Questo file è una sintassi di modello liquido. Il modello Liquid è un linguaggio di creazione modelli diffuso usato in vari framework di sviluppo Web. I modelli liquid consentono agli sviluppatori di creare contenuto dinamico che può essere facilmente aggiornato e modificato. Consentono di inserire variabili, condizioni, cicli e altri elementi dinamici nei messaggi dell'hub eventi. La sintassi è semplice e sono disponibili molte risorse online per iniziare. In generale, i modelli Liquid offrono un modo potente e flessibile per creare messaggi dinamici e personalizzabili.
Salva e chiudi il file.

Importante

Non includere dati personali nel nome del campionatore nello script JMeter. I nomi del campionatore vengono visualizzati nel dashboard dei risultati dei test di test di carico di Azure. Un esempio di modello liquido insieme al file di script JMeter è disponibile per il download in Esempi di Azure

Eseguire il test di carico usando un nuovo plug-in

Quando Test di carico di Azure avvia il test di carico, prima distribuisce lo script JMeter insieme a tutti gli altri file nelle istanze del motore di test e quindi avvia il test di carico come indicato in Personalizzare un test di carico con plug-in Apache JMeter e Test di carico di Azure. Prima di eseguire il test, passare alla scheda dei parametri per definire e impostare i parametri necessari.

Configurazione dei test delle prestazioni per l'ambiente

In qualsiasi test delle prestazioni, è importante avere un ambiente simile all'ambiente di produzione. In questo esempio, l'ambiente seguente viene usato per i test delle prestazioni per comprendere meglio la capacità del sistema e le prestazioni del sistema.

Per l'architettura di esempio, è possibile usare i servizi seguenti per i test delle prestazioni:

Service	Impostazione
Eventhub	Premium con un'unità di elaborazione (PU).
Funzione di Azure	Linux con piano Premium (EP1) - 210 ACU, 3,5 GB di memoria e 1 vCPU equivalente Standard_D1_v2
Area geografica	Stati Uniti orientali

La scelta del livello di servizio appropriato per tutti i servizi di Azure, inclusi Hub eventi e Funzioni di Azure, è un processo complesso e dipende da molti fattori. Per altre informazioni, vedere prezzi Hub eventi di Azure e prezzi Funzioni di Azure.

Progettazione di indicatori KPI per i test delle prestazioni

Prima di poter progettare indicatori di prestazioni chiave (KPI) per i test delle prestazioni, sono necessari due aspetti: i requisiti aziendali e l'architettura del sistema. I requisiti aziendali indicano gli indicatori KPI da misurare, ad esempio il tempo di risposta, la velocità effettiva o la frequenza degli errori. L'architettura di sistema indica come testare le prestazioni di ogni componente, ad esempio server Web, database o API. Consente inoltre di scegliere la migliore strategia di test delle prestazioni, ad esempio test di carico, test di stress o test di resistenza.

In questo esempio i requisiti aziendali sono:

Il sistema deve essere in grado di gestire 1.000 richieste al secondo.
L'affidabilità del sistema deve essere superiore a 0,99.
Il sistema deve essere in grado di gestire 1.000 dispositivi simultanei che segnalano le informazioni sui dati personali.
Specificare la capacità massima del sistema in termini di numero di dispositivi che possono essere supportati. Ad esempio, il sistema con 3x della capacità corrente supporta 1.000 dispositivi simultanei?

In base a questi requisiti, gli indicatori KPI per i test delle prestazioni possono essere:

KPI	Descrizione
RPS	Richiesta al secondo per un hub eventi
LOAD	Numero di carichi o richieste inviate all'hub eventi durante il test delle prestazioni
IR	Numero di esecuzioni di funzioni o frequenza di inserimento
RT	Tempo medio per il tempo di esecuzione delle funzioni di Azure
AMU	Utilizzo medio della memoria per Funzioni di Azure
SR	Frequenza di riuscita di tutte le esecuzioni di funzioni
ARS	Tempo medio di risposta del servizio Downstream (ad esempio, SQL Server o un microservizio)
DF	Numero di errori di dipendenza, inclusi gli errori interni delle funzioni di Azure
MRPS	Numero massimo di rps senza backlog nell'hub eventi (capacità di sistema)

Come misurare gli indicatori KPI

Per misurare gli indicatori KPI, è necessario avere una strategia di test delle prestazioni. La strategia definisce l'approccio ai test delle prestazioni per ogni componente. In questo esempio viene usata la strategia di test delle prestazioni seguente:

Hub eventi: l'approccio ai test delle prestazioni per l'hub eventi consiste nell'inviare molti messaggi all'hub eventi e quindi misurare rps e carico. RpS è il numero di messaggi inviati all'hub eventi al secondo. Load è il numero totale di messaggi inviati all'hub eventi durante il test delle prestazioni. Il servizio Test di carico di Azure può misurare RPS e LOAD.
Funzioni di Azure: l'approccio ai test delle prestazioni per Funzioni di Azure consiste nel misurare le metriche seguenti:
- Il runtime di integrazione è il numero di esecuzioni di funzioni o frequenza di inserimento.
- Rt è il tempo medio per il tempo di esecuzione delle funzioni di Azure.
- L'AMU è l'utilizzo medio della memoria per Funzioni di Azure.
- Sr è la frequenza di riuscita di tutte le esecuzioni di funzioni.
- L'ARS è il tempo medio di risposta del servizio downstream.
- DF è il numero di errori di dipendenza, inclusi gli errori interni delle funzioni di Azure.
Il servizio Monitoraggio di Azure può misurare AMU, ARS e DF, ma non IR, RT o SR.

Per misurare gli indicatori KPI usando il servizio Monitoraggio di Azure, è necessario abilitare Application Insights per Funzioni di Azure. Per altre informazioni, vedere Abilitare l'integrazione di Application Insights.

Dopo aver abilitato il servizio Monitoraggio di Azure, è possibile usare le query seguenti per misurare gli indicatori KPI:

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

Esempio di dashboard di Monitoraggio di Azure

Ecco un esempio di dashboard di Monitoraggio di Azure che mostra gli indicatori KPI per Funzioni di Azure in base alle query:

Conclusione

In questo articolo si è appreso come progettare indicatori KPI e sviluppare un dashboard per test di carico di Azure. Si è anche appreso come usare plug-in personalizzati in JMeter per eseguire test di carico su Funzioni di Azure integrato con Hub eventi. È possibile usare lo stesso approccio per eseguire test di carico in altri servizi di Azure. È anche possibile configurare una pipeline di integrazione e recapito continuo (CI/CD) per gli script di test di carico usando Azure DevOps.

Per altre informazioni, vedere Test di carico di Azure.

Collaboratori

Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.

Autore principale:

Mahdi Setayesh | Principal Software Engineer

Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.

Condividi tramite

Test di carico di Azure con plug-in personalizzati

Architettura

Flusso di dati

Componenti

Dettagli dello scenario

Potenziali casi d'uso

Plug-in personalizzati

Creare uno script Apache JMeter con plug-in personalizzato

Eseguire il test di carico usando un nuovo plug-in

Configurazione dei test delle prestazioni per l'ambiente

Progettazione di indicatori KPI per i test delle prestazioni

Come misurare gli indicatori KPI

Esempio di dashboard di Monitoraggio di Azure

Conclusione

Collaboratori

Passaggi successivi

Commenti e suggerimenti

Risorse aggiuntive

Condividi tramite

Test di carico di Azure con plug-in personalizzati

Architettura

Flusso di dati

Componenti

Dettagli dello scenario

Potenziali casi d'uso

Plug-in personalizzati

Creare uno script Apache JMeter con plug-in personalizzato

Eseguire il test di carico usando un nuovo plug-in

Configurazione dei test delle prestazioni per l'ambiente

Progettazione di indicatori KPI per i test delle prestazioni

Come misurare gli indicatori KPI

Esempio di dashboard di Monitoraggio di Azure

Conclusione

Collaboratori

Passaggi successivi

Risorse correlate

Commenti e suggerimenti

Risorse aggiuntive