Teste de carga do Azure com plug-ins personalizados

  • Artigo

Ideias de soluções

Este artigo é uma ideia de solução. Se você quiser que expandamos o conteúdo com mais informações, como possíveis casos de uso, serviços alternativos, considerações de implementação ou orientação de preços, informe-nos fornecendo feedback do GitHub.

Esta solução fornece orientação sobre como usar o Teste de Carga do Azure, um serviço que permite executar scripts Apache JMeter e plug-ins personalizados para simular comportamentos de usuários e dispositivos. Esta solução também explica como projetar indicadores-chave de desempenho (KPIs) e desenvolver um painel para monitorar e analisar os resultados do teste de carga em um aplicativo de exemplo com o Azure Functions e os Hubs de Eventos do Azure. O artigo pressupõe que você tenha alguma familiaridade com o JMeter, seus plug-ins e plug-ins personalizados, bem como Azure Functions e Hubs de Eventos.

Arquitetura

Para executar o teste de carga, você precisa de um plano de teste, que é um conjunto de instruções que informa ao JMeter o que fazer durante o teste. O plano de teste pode incluir vários cenários de teste, cada um com definições e configurações diferentes. Por exemplo, você pode ter um cenário que simula um único usuário acessando um aplicativo Web e outro cenário que simula vários usuários acessando simultaneamente o mesmo aplicativo.

O plano de teste também pode incluir vários casos de teste, cada um com definições e configurações diferentes. No nosso caso, assumimos que há um dispositivo que está relatando temperatura e umidade durante um determinado período de tempo. O dispositivo está enviando os dados para um hub de eventos no Azure. O hub de eventos dispara uma Função do Azure que é responsável por processar os dados e, em seguida, enviar dados para outros serviços downstream, como o Banco de Dados SQL do Azure. A Função do Azure é o serviço que queremos testar. O plano de teste é projetado para simular o comportamento do dispositivo e enviar dados para o hub de eventos.

Diagram of a sample architecture for load testing.

Transfira um ficheiro do Visio desta arquitetura.

Fluxo de dados

Neste exemplo, o fluxo de dados é o seguinte:

  1. Um dispositivo simulado envia dados para um hub de eventos por meio do agente de Teste de Carga do Azure. Qualquer comportamento do dispositivo pode ser simulado usando plugins personalizados JMeter. O agente de Teste de Carga do Azure é responsável por enviar dados para o hub de eventos depois de executar o plug-in personalizado para qualquer tipo de dispositivo simulado.
  2. O hub de eventos dispara uma Função do Azure que é responsável por processar os dados e, em seguida, enviar dados para outros serviços downstream, como o Banco de Dados SQL do Azure e os Gêmeos Digitais do Azure.
  3. O serviço Azure Monitor é usado para monitorar a Função do Azure e os Hubs de Eventos.
  4. O serviço de Teste de Carga do Azure coleta os dados do serviço Azure Monitor e os exibe em um painel.

Componentes

Neste exemplo, os seguintes componentes são usados:

  • Teste de Carga do Azure: o Teste de Carga do Azure permite executar scripts Apache JMeter e plug-ins personalizados para simular comportamentos de usuários e dispositivos. Ele fornece uma interface baseada na Web para gerenciar e executar testes de carga e um conjunto de APIs que podem ser usadas para automatizar o processo. O Teste de Carga do Azure é um serviço totalmente gerenciado, o que significa que você não precisa se preocupar com o gerenciamento de servidores ou infraestrutura. Você pode carregar seus scripts JMeter e plug-ins personalizados, e o Teste de Carga do Azure lida com o resto.
  • Hubs de Eventos do Azure: os Hubs de Eventos do Azure são um serviço de processamento de eventos baseado em nuvem que pode ser usado para coletar, processar e analisar eventos e dados de streaming de várias fontes em tempo real. Os Hubs de Eventos suportam vários protocolos, incluindo AMQP (Advanced Message Queuing Protocol), HTTPS, Kafka Protocol, MQTT (Message Queuing Telemetry Transport) e AMQP sobre WebSockets. A escolha do protocolo certo depende de vários fatores, incluindo o tipo de dados com os quais você está trabalhando, os requisitos específicos do seu aplicativo e os recursos e limitações dos próprios protocolos.
  • Azure Functions: o Azure Functions é um serviço de computação sem servidor que permite executar código sem ter de gerir servidores ou infraestruturas. Ele suporta várias linguagens de programação, incluindo C#, F#, Java, JavaScript, PowerShell, Python e TypeScript. O Azure Functions pode ser usado para processar eventos e transmitir dados de Hubs de Eventos, bem como de outras fontes, como o Armazenamento do Azure e o Azure Cosmos DB.
  • JMeter GUI: JMeter GUI é uma ferramenta de teste de carga de código aberto que é usada principalmente para testar o desempenho de aplicativos Web. Foi originalmente desenvolvido para testar aplicações web. No entanto, ele também pode ser usado para testar outros tipos de aplicativos, como serviços Web SOAP e REST, servidores FTP e bancos de dados.
  • Azure Monitor: o Azure Monitor fornece recursos de monitoramento e alerta para recursos do Azure. Ele permite que você monitore o desempenho e a integridade de seus aplicativos e da infraestrutura subjacente também. O Azure Monitor pode ser usado para monitorar Hubs de Eventos e Azure Functions, bem como outros serviços do Azure, como o Armazenamento do Azure e o Azure Cosmos DB.

Detalhes do cenário

O Teste de Carga do Azure permite que você pegue um script Apache JMeter existente e use-o para executar um teste de carga em escala de nuvem em qualquer recurso do Azure.

O JMeter permite que os testadores criem e executem testes de carga, testes de esforço e testes funcionais. Ele simula vários usuários acessando simultaneamente um aplicativo Web, permitindo que os testadores identifiquem possíveis gargalos de desempenho ou outros problemas que possam surgir sob cargas pesadas. O JMeter pode ser usado para medir várias métricas de desempenho, como tempo de resposta, taxa de transferência e taxa de erro.

O JMeter usa uma interface baseada em GUI para permitir que os usuários criem planos de teste, que podem incluir vários cenários de teste, cada um com definições e configurações diferentes. Os testadores também podem personalizar o JMeter usando plugins ou escrevendo código personalizado, permitindo que eles estendam sua funcionalidade além do que sai da caixa. Os plugins podem nos ajudar a trabalhar com serviços que usam protocolos não-HTTP, como AMQP e Websocket.

Embora o JMeter forneça uma ampla gama de recursos e funções para testes de carga, pode haver casos de uso ou requisitos específicos que não são cobertos pela funcionalidade interna. Ao desenvolver plug-ins personalizados, os testadores podem adicionar novas funcionalidades ou personalizar recursos existentes para melhor atender às suas necessidades

Por exemplo, um plugin personalizado pode ser desenvolvido para simular um tipo específico de comportamento do usuário ou para gerar dados de teste mais realistas. Além disso, plugins personalizados podem ser desenvolvidos para integrar o JMeter com outras ferramentas ou sistemas, como ferramentas de registro e relatórios ou pipelines de integração e implantação contínua. Os plug-ins personalizados podem ajudar a simplificar o processo de teste e facilitar a incorporação de testes de carga no fluxo de trabalho geral de desenvolvimento de software. No geral, eles permitem que os testadores adaptem o JMeter às suas necessidades específicas e melhorem a precisão e a eficácia de seus esforços de teste de carga.

Neste exemplo, assumimos que há um dispositivo que está relatando temperatura e umidade durante um determinado período de tempo. Podemos simular esse comportamento simples usando um plug-in JMeter personalizado. Na implementação atual do plugin personalizado fornecido aqui, geramos dados aleatórios usando um modelo fornecido. No entanto, o plugin pode conter qualquer comportamento complexo possível para qualquer dispositivo. Neste exemplo, o dispositivo está enviando os dados para um hub de eventos no Azure. O hub de eventos dispara uma Função do Azure que é responsável por processar os dados e, em seguida, enviar dados para outros serviços downstream, como o Banco de Dados SQL do Azure. A Função do Azure é o serviço que queremos testar. O plano de teste é projetado para simular o comportamento do dispositivo e enviar dados para o hub de eventos.

Potenciais casos de utilização

Usar o Teste de Carga do Azure com plug-ins personalizados pode ser útil em vários cenários, como:

  • Testando o desempenho de um aplicativo que usa protocolos não-HTTP, como AMQP e Websocket.
  • Testando o desempenho de um aplicativo que usa um protocolo personalizado.
  • Testando o desempenho de um aplicativo que usa um SDK que não seja da Microsoft.
  • Simular um tipo específico de comportamento de usuário ou dispositivo ou gerar dados de teste mais realistas.

Plugins personalizados

Plugins personalizados no contexto do JMeter são componentes de software que podem ser adicionados ao JMeter para estender sua funcionalidade além do que sai da caixa. Usuários ou desenvolvedores que não são da Microsoft podem desenvolver plug-ins personalizados para adicionar novos recursos, funções ou integrações ao JMeter. Plugins personalizados podem ser desenvolvidos usando a linguagem de programação Java e o JMeter Plugin Development Kit (PDK). O PDK fornece um conjunto de ferramentas e APIs que facilitam a criação de novos plugins, incluindo elementos GUI, ouvintes e samplers.

Plugins personalizados podem adicionar uma ampla gama de funcionalidades ao JMeter. Eles também podem integrar o JMeter com outros sistemas, como ferramentas de registro e relatórios, ou permitir o uso de outras fontes de dados para dados de teste. No geral, os plugins personalizados permitem que os usuários estendam o JMeter para atender às suas necessidades específicas e melhorar a precisão e a eficácia de seus esforços de teste de carga.

Para implementar um sampler personalizado para Hubs de Eventos no JMeter, siga as instruções fornecidas em Plug-ins de Teste de Carga do Azure. Depois que seu amostrador personalizado for implementado, você poderá usá-lo em seu plano de teste JMeter no Teste de Carga do Azure como qualquer outro amostrador.

Um plano de teste pode ser implementado usando um grupo de threads que controla o número de threads (usuários e dispositivos virtuais) para executar um cenário específico. Cada grupo de threads pode ter configurações diferentes para o número de threads, período de ramp-up, contagem de loops e duração. Os grupos de threads podem ser executados sequencialmente ou em paralelo, dependendo da configuração do plano de teste e dos requisitos do aplicativo. Você pode adicionar o amostrador a um grupo de threads, definir seus parâmetros e configurá-lo conforme necessário. Os amostradores personalizados podem ser ferramentas poderosas no JMeter, permitindo simular cenários complexos e solicitações que os amostradores integrados não suportam.

Crie um script Apache JMeter com plug-in personalizado

Nesta seção, você cria um script de teste JMeter de exemplo para carregar um aplicativo de teste com Hubs de Eventos.

Para criar um script de teste JMeter de exemplo:

  1. Crie um arquivo LoadTest.jmx em sua máquina local:

    touch LoadTest.jmx

  2. Abra LoadTest.jmx em um editor de texto e cole o seguinte trecho de código no arquivo. Esse script simula um teste de carga de 36 máquinas virtuais que enviam eventos simultaneamente para um hub de eventos e leva 10 minutos para ser concluído:

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

    A implementação de e com.microsoft.eventhubplugin.EventHubPlugin estão disponíveis em Exemplos do com.microsoft.eventhubplugin.EventHubPluginGui Azure.

  3. No arquivo, defina o valor do nó como o nome da variável que especifica o eventHubConnectionVarName host da cadeia de conexão dos Hubs de Eventos. Por exemplo, se você quiser que a variável de ambiente que armazena a cadeia de conexão dos Hubs de Eventos seja EventHubConnectionString, defina essa variável como EventHubConnectionString e, em seguida, defina o valor da variável ambiental.

    Importante

    Verifique se o valor de foi definido como parte do processo de criação do teste de carga do Azure antes de executar o script de teste de EventHubConnectionString carga.

  4. No arquivo, defina o eventHubName valor do nó como o nome do hub de eventos, como telemetry-data-changed-eh.

  5. Defina o liquidTemplateFileName valor do nó para o arquivo que contém a mensagem que é enviada para o hub de eventos. Por exemplo, crie um arquivo chamado StreamingDataTemplate.liquid como:

    {
    {% 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 }}
}

    Neste exemplo, a carga útil para a mensagem do hub de eventos é um objeto JSON com três propriedades, incluindo MachineId, e onde MachineId é uma ID gerada aleatoriamente com o comprimento de 27 e HumidityTemperatureHumidity são inteiros aleatórios menores que Temperature100. Este arquivo é uma sintaxe de modelo líquido. Modelo líquido é uma linguagem de modelagem popular que é usada em vários frameworks de desenvolvimento web. Os modelos líquidos permitem que os desenvolvedores criem conteúdo dinâmico que pode ser facilmente atualizado e modificado. Eles permitem inserir variáveis, condições, loops e outros elementos dinâmicos em suas mensagens do hub de eventos. A sintaxe é simples e há muitos recursos online disponíveis para ajudá-lo a começar. No geral, os modelos Liquid oferecem uma maneira poderosa e flexível de criar mensagens dinâmicas e personalizáveis.

  6. Guarde e feche o ficheiro.

    Importante

    Não inclua nenhum dado pessoal no nome do amostrador no script JMeter. Os nomes dos amostradores aparecem no painel de resultados de teste do Teste de Carga do Azure. Um exemplo de um modelo líquido junto com o arquivo de script JMeter está disponível para download em Exemplos do Azure

Execute o teste de carga usando o novo plugin

Quando o Teste de Carga do Azure inicia seu teste de carga, ele primeiro implanta o script JMeter junto com todos os outros arquivos em instâncias do mecanismo de teste e, em seguida, inicia o teste de carga conforme instruído em Personalizar um teste de carga com plug-ins do Apache JMeter e Teste de Carga do Azure. Antes de executar o teste, vá para a guia de parâmetro, defina EventHubConnectionStringe forneça a cadeia de conexão para o hub de eventos.

Screenshot that shows the parameters of the test.

Configuração de teste de desempenho para ambiente

Em qualquer teste de desempenho, é importante ter um ambiente semelhante ao ambiente de produção. Neste exemplo, o ambiente a seguir é usado para testes de desempenho, a fim de entender melhor a capacidade do sistema e o desempenho do sistema.

De acordo com a arquitetura de exemplo, os seguintes serviços podem ser usados para testes de desempenho:

Service Configuração
Eventhub Premium com uma Unidade de Processamento (PU).
Função do Azure Linux com Plano Premium (EP1) - 210 ACU, 3,5 GB de memória e 1 vCPU equivalente Standard_D1_v2
País/Região E.U.A. Leste

Escolher a camada de serviço certa para qualquer serviço do Azure, incluindo Hubs de Eventos e Azure Functions, é um processo complexo e depende de muitos fatores. Para obter mais informações, consulte Preços dos Hubs de Eventos do Azure e Preços do Azure Functions.

Projetando KPIs para testes de desempenho

Antes de projetar indicadores-chave de desempenho (KPIs) para testes de desempenho, você precisa de duas coisas: os requisitos de negócios e a arquitetura do sistema. Os requisitos de negócios informam quais KPIs você deseja medir, como tempo de resposta, taxa de transferência ou taxa de erro. A arquitetura do sistema informa como testar o desempenho de cada componente, como servidores Web, bancos de dados ou APIs. Ele também ajuda você a escolher a melhor estratégia de teste de desempenho, como teste de carga, teste de esforço ou teste de resistência.

Neste exemplo, os requisitos de negócios são:

  • O sistema deve ser capaz de lidar com 1.000 solicitações por segundo.
  • A fiabilidade do sistema deve ser superior a 0,99.
  • O sistema deve ser capaz de lidar com 1.000 dispositivos simultâneos que relatam suas informações de dados pessoais.
  • Especificando a capacidade máxima do sistema em termos do número de dispositivos que podem ser suportados. Por exemplo, o sistema com 3x da capacidade atual suporta 1.000 dispositivos simultâneos?

De acordo com esses requisitos, os KPIs para testes de desempenho podem ser:

KPI Description
RPS Solicitação por segundo para um hub de eventos
CARREGAR Número de cargas ou solicitações enviadas ao hub de eventos durante o teste de desempenho
IR Número de execuções de função ou taxa de ingestão
RT Tempo médio para o Tempo de Execução da Função do Azure
AMU Uso médio de memória para o Azure Functions
SR Taxa de sucesso de todas as execuções de função
ARS Tempo médio de resposta do serviço downstream (por exemplo, servidor SQL ou um microsserviço)
DF Contagem de falhas de dependência, incluindo erros internos de função do Azure
MRPS RPS máximo sem lista de pendências no hub de eventos (capacidade do sistema)

Como medir KPIs

Para medir KPIs, você precisa ter uma estratégia de teste de desempenho. A estratégia define a abordagem de teste de desempenho para cada componente. Neste exemplo, a seguinte estratégia de teste de desempenho é usada:

  • Hubs de Eventos: A abordagem de teste de desempenho para o hub de eventos é enviar muitas mensagens para o hub de eventos e, em seguida, medir o RPS e LOAD. O RPS é o número de mensagens enviadas para o hub de eventos por segundo. O LOAD é o número total de mensagens enviadas para o hub de eventos durante o teste de desempenho. O serviço de Teste de Carga do Azure pode medir RPS e LOAD.
  • Azure Functions: A abordagem de teste de desempenho para o Azure Functions é medir as seguintes métricas:
    • O RI é o número de execuções de funções ou taxa de ingestão.
    • O RT é o tempo médio para o Tempo de Execução da Função do Azure.
    • A AMU é o uso médio de memória para o Azure Functions.
    • O SR é a taxa de sucesso de todas as execuções de funções.
    • O ARS é o tempo médio de resposta do serviço a jusante.
    • O DF é a contagem de falhas de dependência, incluindo erros internos de função do Azure.
    • O serviço Azure Monitor pode medir AMU, ARS e DF, mas não IR, RT ou SR.

Para medir KPIs usando o serviço Azure Monitor, precisamos habilitar o Application Insights para Azure Functions. Para obter mais informações, consulte Habilitar a integração do Application Insights.

Depois de habilitar o serviço Azure Monitor, você pode usar as seguintes consultas para medir KPIs:

  • RI: 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

Exemplo do painel do Azure Monitor

Aqui está um exemplo do painel do Azure Monitor que mostra os KPIs do Azure Functions com base nas consultas:

Screenshot samples of the Azure Monitor dashboard.

Conclusão

Neste artigo, você aprendeu como projetar KPIs e desenvolver um painel para o Teste de Carga do Azure. Você também aprendeu como usar plug-ins personalizados no JMeter para executar testes de carga no Azure Functions integrado com Hubs de Eventos. Você pode usar a mesma abordagem para executar testes de carga em outros serviços do Azure. Você também pode configurar um pipeline de integração e entrega contínua (CI/CD) para seus scripts de teste de carga usando o Azure DevOps.

Para obter mais informações, consulte Teste de carga do Azure.

Contribuidores

Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.

Autor principal:

Para ver perfis não públicos do LinkedIn, inicie sessão no LinkedIn.

Próximos passos