Test di carico di Azure con plug-in personalizzati per Hub eventi e hub IoT

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. Questo esempio usa Hub eventi, ma è possibile applicare lo stesso approccio all'hub IoT di Azure modificando il client di Hub eventi nel client dell'hub IoT. Questo articolo presuppone che tu abbia una certa familiarità con JMeter, i suoi plug-in, i plug-in personalizzati, le Funzioni e gli Event Hubs.

L'hub IoT contiene più componenti di base rispetto a Hub eventi, incluse le partizioni. Di conseguenza, l'approccio ai test di carico descritto in questo articolo si applica anche all'hub IoT con modifiche minime.

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 e ogni scenario può avere 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 l'accesso simultaneo di più utenti alla stessa applicazione.

Scaricare un file di Visio di questa architettura.

Flusso di dati

Il flusso di dati seguente corrisponde al diagramma precedente:

1. Un dispositivo simulato invia dati a un hub eventi tramite un agente test di carico. Qualsiasi comportamento del dispositivo può essere simulato usando plug-in personalizzati JMeter. L'agente test di carico invia i dati all'hub eventi dopo l'esecuzione del plug-in personalizzato per qualsiasi tipo di dispositivo simulato.

2. L'hub eventi attiva un'app per le funzioni di Azure che elabora i dati e li invia ad altri servizi downstream, ad esempio il database SQL di Azure e Gemelli digitali di Azure.

3. Azure Monitor monitora l'applicazione per le funzioni e gli Event Hubs.

4. Il test di carico raccoglie i dati dal monitoraggio di Azure e li visualizza in una dashboard.

Componenti

In questo esempio vengono usati i componenti seguenti:

• Test di Carico: usare il Test di Carico per eseguire script Apache JMeter e plug-in personalizzati per simulare i comportamenti degli utenti e dei dispositivi. Test di carico offre un'interfaccia basata sul Web per gestire ed eseguire test di carico e un set di API per automatizzare il processo. Il test di carico è un servizio completamente gestito, il che significa che non è necessario gestire server o infrastruttura. In questa architettura, il Test di Carico carica gli script JMeter e i plug-in personalizzati ed è l'unità di elaborazione in cui vengono eseguiti tali script.

• Hub eventi: Hub eventi è un servizio di elaborazione eventi basato sul cloud che è possibile usare per raccogliere, elaborare e analizzare eventi e trasmettere dati da varie origini in tempo reale. Hub eventi supporta più protocolli, tra cui Advanced Message Queuing Protocol (AMQP), HTTPS, protocollo Kafka, Message Queuing Telemetry Transport (MQTT) e AMQP su WebSocket. Questa architettura è basata su eventi, quindi il test di carico genera eventi per mettere alla prova il carico di lavoro.

• hub IoT: l'hub IoT è un servizio gestito ospitato nel cloud che funge da hub messaggi centrale per la comunicazione tra un'applicazione IoT e i dispositivi collegati. È possibile connettere milioni di dispositivi e le relative soluzioni back-end in modo affidabile e sicuro. Quasi tutti i dispositivi possono essere connessi a un hub IoT. È possibile adattare questa architettura per usare IoT Hub modificando il client di Event Hubs al client di IoT Hub.

• Funzioni di Azure: Funzioni è un servizio di calcolo serverless che è possibile usare per 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 come livello di calcolo primario. I dati degli eventi in Event Hubs attivano e scalano le app delle funzioni.

• GUI di JMeter: JMeter GUI è uno strumento di test del carico open source usato principalmente per testare le prestazioni delle applicazioni Web. Tuttavia, è anche possibile usarlo 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. Usarlo per monitorare le prestazioni e l'integrità delle applicazioni e dell'infrastruttura sottostante. In questa architettura Monitoraggio di Azure monitora l'integrità dei componenti dell'infrastruttura di Azure durante il test di carico.

Dettagli dello scenario

È possibile usare Test di carico per applicare uno script Apache JMeter esistente ed eseguire un test di carico su larga 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 che accedono contemporaneamente a un'applicazione Web in modo che i tester possano identificare potenziali colli di bottiglia delle prestazioni o altri problemi che possono verificarsi in condizioni di carico elevato. È possibile usare JMeter 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 con impostazioni e configurazioni diverse. I tester possono anche personalizzare JMeter usando plug-in o scrivendo codice personalizzato. I plug-in possono aiutare gli utenti a usare servizi che usano protocolli non HTTP, ad esempio AMQP e WebSocket.

JMeter offre un'ampia gamma di funzionalità e funzioni per i test di carico, ma la funzionalità predefinita potrebbe non coprire casi d'uso specifici o requisiti. 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. È anche 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 continua e distribuzione continua (CI/CD). 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. 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 un dispositivo segnala temperatura e umidità in un periodo di tempo specifico. L'esempio simula questo comportamento usando un plug-in JMeter personalizzato. L'implementazione corrente del plug-in personalizzato genera 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 un'app per le funzioni di Azure che elabora i dati e li invia ad altri servizi downstream, ad esempio il database SQL. Funzioni di Azure è il servizio che testa l'architettura. 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 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.
• Generazione di dati di test più realistici.

Plug-in personalizzati

In JMeter, i plug-in personalizzati sono componenti software che è possibile aggiungere per espandere la relativa funzionalità predefinita. I plug-in personalizzati aggiungono nuove funzionalità, funzioni o integrazioni a JMeter. È possibile sviluppare plug-in personalizzati usando il linguaggio di programmazione Java e il kit di sviluppo plug-in JMeter (PDK). Il PDK fornisce un set di strumenti e API che consentono di creare nuovi plug-in, inclusi elementi gui, listener e campionatori.

Per implementare un campionatore personalizzato per Hub eventi in JMeter, seguire le istruzioni in plug-in JMeter per test di carico. Dopo aver implementato il campionatore personalizzato, è possibile usarlo nel piano di test di JMeter in Test di carico esattamente come qualsiasi altro campionatore.

È possibile implementare un piano di test usando un gruppo di thread che controlla il numero di thread, ad esempio 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. I campionatori personalizzati possono essere strumenti potenti in JMeter che consentono di simulare scenari complessi e richieste che i campionatori predefiniti non supportano.

Creare uno script Apache JMeter con un 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:

1. 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 contemporaneamente eventi a un hub eventi. Il completamento richiede 10 minuti.

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

   L'implementazione di com.microsoft.eventhubplugin.EventHubPluginGui e com.microsoft.eventhubplugin.EventHubPlugin è disponibile negli esempi di Azure .

2. Nel file impostare i valori di connessione di Event Hubs usando l'identità gestita assegnata degli esecutori di test. Quell'identità deve avere accesso in scrittura all'istanza di Event Hubs.

3. Nel file, imposta il valore del nodo eventHubName sul nome dell'evento hub, come telemetry-data-changed-eh.

4. Impostare il valore del nodo liquidTemplateFileName 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à, MachineId, Temperaturee Humidity. MachineId è un ID generato in modo casuale con lunghezza di 27 caratteri e Temperature e Humidity sono numeri interi casuali minori di 100. Questo file è una sintassi del template Liquid. 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. I modelli liquid offrono un modo potente e flessibile per creare messaggi dinamici e personalizzabili.

5. Salva e chiudi il file.

   Importante

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

Aggiornare il plug-in personalizzato da Hub eventi all'hub IoT

Il plug-in personalizzato usa Hub eventi come risorsa di destinazione primaria. La configurazione seguente è la configurazione del client SDK per Hub eventi:

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);

L'esempio seguente illustra come riutilizzare la stessa soluzione, aggiungere le dipendenze IoT e modificare il client SDK per usare l'hub IoT:

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();

Eseguire il test di carico usando il nuovo plug-in

Quando Load Testing avvia il test di carico, distribuisce prima di tutto lo script JMeter insieme a tutti gli altri file nelle istanze dei motori di esecuzione del test. Prima di eseguire il test, passare alla scheda dei parametri per definire e impostare i parametri necessari. Per altre informazioni, vedere Personalizzare un test di carico con plug-in Apache JMeter e Test di carico.

Configurare i test delle prestazioni per l'ambiente

Per i test delle prestazioni, è importante che l'ambiente di test sia simile all'ambiente di produzione. Questo esempio usa l'ambiente seguente per i test delle prestazioni per comprendere meglio la capacità e le prestazioni del sistema.

La scelta del livello di servizio appropriato per qualsiasi servizio di Azure, inclusi Hub eventi e Funzioni di Azure, è un processo complesso e dipende da molti fattori. Per ulteriori informazioni, vedere Event Hubs pricing e Functions pricing.

Progettare indicatori KPI per i test delle prestazioni

Prima di poter progettare indicatori KPI per i test delle prestazioni, è necessario definire i requisiti aziendali e l'architettura del sistema. I requisiti aziendali indicano gli indicatori KPI, ad esempio il tempo di risposta, la velocità effettiva o la frequenza degli errori, da misurare. 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.

Questo esempio presenta i requisiti aziendali seguenti:

• Il sistema può gestire 1.000 richieste al secondo.
• L'affidabilità del sistema è superiore a 0,99.
• Il sistema può gestire 1.000 dispositivi simultanei che segnalano le informazioni personali.
• È possibile specificare la capacità massima del sistema in termini di numero di dispositivi che può supportare. Ad esempio, il sistema può supportare 1.000 dispositivi simultanei con tre volte la capacità corrente.

Per misurare se il sistema soddisfa questi requisiti, è possibile usare gli indicatori KPI seguenti per i test delle prestazioni:

Misura 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 test di carico può misurare RPS e LOAD.

• Funzioni di Azure: L'approccio ai test delle prestazioni per Funzioni consiste nel misurare le metriche seguenti.

  • IR
  • RT
  • AMU
  • SR
  • ARS
  • DF

Azure Monitor può misurare AMU, ARS e DF, ma non IR, RT oppure SR. Per misurare gli indicatori chiave di prestazione utilizzando Azure Monitor, abilita Application Insights per Azure Functions. Per altre informazioni, vedere Abilitare l'integrazione di Application Insights.

Dopo aver abilitato 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

L'immagine seguente mostra un esempio del dashboard di Monitoraggio di Azure. Mostra gli indicatori KPI per Funzioni di Azure in base alle query precedenti.

Conclusione

In questo articolo si è appreso come progettare indicatori KPI e sviluppare un dashboard per test di carico. 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 CI/CD per gli script di test di carico usando Azure DevOps.

Per altre informazioni, vedere test di carico.

Collaboratori

Microsoft gestisce questo articolo. I collaboratori seguenti hanno scritto questo articolo.

Autori principali:

• Mahdi Setayesh | Principal Software Engineer
• Oscar Fimbres | Senior Software Engineer

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

Passaggi successivi

• test di carico
• Codice di esempio per un plug-in JMeter personalizzato
• Come sviluppare un nuovo plug-in personalizzato
• Personalizzare un test di carico con plug-in Apache JMeter e test di carico
• Informazioni su Azure Application Insights
• Test di carico delle applicazioni del servizio app Azure
• Avvio rapido: Creare ed eseguire un test di carico con Load Testing
• Test di carico di un sito Web usando uno script JMeter in Test di carico
• Guida introduttiva: Automatizzare un test di carico esistente con CI/CD
• Esercitazione: eseguire un test di carico per identificare eventuali lacune nelle prestazioni di un'app Web