# Como executar um teste de carga na Digibee ## **Visão geral** Este documento orienta testes de carga em pipelines na Digibee Integration Platform, avaliando desempenho, tempo de resposta e estabilidade para garantir uma entrada segura em produção. Aqui você encontrará a estratégia recomendada, as configurações ideais para a carga planejada e boas práticas. Também estão disponíveis materiais de apoio: * Modelo de Planilha de Plano de Testes para organizar e documentar o teste de carga. * Checklist com os principais passos do plano, disponível para consulta sempre que necessário. ## **Contexto** As orientações aqui registradas são baseadas em um caso real: o teste de um pipeline API REST síncrono que precisava suportar 4.000 usuários simultâneos (*threads*) com tempo de resposta máximo de 4.000 ms. Essa carga ocorreria apenas no quinto dia útil do mês; nos demais dias, o pico seria de 10 *threads*. ## **Considerações importantes** ### **Desativação do autoscaling** Durante o teste, o [autoscaling](/documentation/developer-guide/pt-br/development-cycle/overview/runtime/autoscaling.md) deve ser desativado, já que o *cold start* afeta as métricas mas não representa o uso real, pois ocorre apenas na primeira requisição. Após o teste, configure o número mínimo de réplicas para garantir bom desempenho nas primeiras requisições e em cargas abaixo da média. ### **Warm up em novas réplicas** Cada teste incremental tem como objetivo identificar limites e ajustar o dimensionamento horizontal (réplicas) ou vertical (tamanho do pipeline). Ao aumentar réplicas, desconsidere a primeira execução, pois ela ativa o processo de *warm up* nas novas réplicas, o que distorce a análise de desempenho. ### **Custos do teste de carga** O custo depende do modelo de licenciamento utilizado ([Modelos de licenciamento](/documentation/licensing/pt-br/licensing-models/licensing-main-concepts.md)): * **Baseado em pipeline (Licenças):** Produção e Teste consomem o mesmo pacote. * **Baseado em subscription (RTUs):** Produção e Teste consomem pacotes diferentes. * **Baseado em consumo (Créditos):** Baseado no uso real; testes de carga podem **consumir créditos rapidamente** devido ao grande volume de requisições. ### **Envolvimento do time da Digibee** O teste de carga deve contar com o acompanhamento do time da Digibee a partir da **Fase 2**, garantindo suporte durante a execução e realização de ajustes necessários. Mais informações estão no tópico [Fase 2: Preparação do ambiente de teste](#fase-2-preparacao-do-ambiente-de-teste). ## **Fase 1: Planejamento dos testes** Um plano de testes é essencial para avaliar o ambiente, executar os cenários, analisar resultados e concluir o teste com sucesso. {% hint style="info" %} Recomendamos que faça o download da [Planilha de Plano de Testes](#template-de-planilha-de-plano-de-testes), que servirá como apoio para elaboração e documentação do teste de carga. {% endhint %} ### **Parâmetros de carga** O primeiro passo do plano é o registro das condições gerais para o teste contendo os seguintes tópicos: * O que será testado * Parâmetros relevantes para a execução do teste (requisições simultâneas, tamanho da mensagem, exemplo da mensagem a ser testada, tempo de resposta esperado) * Observações (ferramenta utilizada para execução dos testes, informações sobre o pico de transações e sobre a média fora do pico) Veja um exemplo:
### **Ensaio de testes** O Plano de Testes deve incluir cenários com crescimento gradual de carga, começando com recursos mínimos e aumentando a cada execução até atingir o objetivo final. Esse processo é chamado de “ensaio”, pois seus resultados ajudam a definir os parâmetros do teste final. A seguir, há um exemplo do planejamento em uma página da Planilha de Testes:
## **Fase 2: Preparação do ambiente de teste** Com o plano definido, é hora de preparar o ambiente em conjunto com a Digibee. Nesta etapa, é fundamental alinhar responsabilidades entre **time do cliente**, **time interno da Digibee** e **time de Produto**, garantindo que todos os ajustes necessários sejam realizados antes do início dos testes. ### **Time do cliente** Responsável por viabilizar a execução do teste e fornecer os recursos externos necessários. * Definir a ferramenta que será utilizada para execução do teste (ex.: JMeter). * Designar responsáveis pela execução e análise dos resultados junto com a equipe da Digibee. * Disponibilizar recursos para simulação de *steps* de acesso externo, mesmo que com respostas simuladas, como: * Endpoints para requisições * Bancos de dados * Servidor de arquivos * Brokers de mensageria * Entre outros * Participar da pré-análise do pipeline para identificar pontos que exigem escala. ### **Time interno da Digibee** Atua como intermediário entre o cliente e o time de Produto, coordenando ações e garantindo a prontidão do ambiente para o teste de carga. Para isso, é necessário contatar uma das duas equipes: 1. **Professional Services**: Suporte técnico especializado, **se previamente contratado**. 2. **Customer Success**: Acompanha o processo, garantindo alinhamento com o cliente. Principais atividades: * Verificar conclusão dos requisitos de infraestrutura. * Confirmar recursos de acesso externos ou validar alternativas (ex.: Mock). * Realizar pré-análise dos pipelines e testes funcionais. * Avaliar a capacidade do ambiente. ### **Time de Produto da Digibee** Responsável por avaliar e calibrar o ambiente de teste, garantindo que os recursos estejam adequados antes da execução. Principais atividades: * Analisar parâmetros de carga e plano de testes, identificando ajustes necessários. * Revisar e calibrar componentes da Plataforma, como AWS EC2, GCE, Gateway (Kong), Trigger, RabbitMQ, Object Store e Digibee Store. * Definir acompanhamento do teste: equipe presente, janela de execução, relatórios e indicadores, acessos e demais informações relevantes. {% hint style="warning" %} É fundamental que o time da Digibee e o cliente realizem juntos uma pré-análise do pipeline para identificar componentes que precisam de escala. {% endhint %} As configurações iniciais podem ser registradas na página “geral” da Planilha de Testes:
{% hint style="info" %} Algumas das informações apresentadas acima referem-se a ajustes realizados durante os testes, conforme descrito na [Fase 3: Execução](#fase-3-execucao). {% endhint %} ## **Fase 3: Execução** Com as fases anteriores concluídas, os testes planejados devem ser executados de forma sequencial. ### **Atualização dos dados gerais do ambiente** Durante os testes, podem surgir necessidades de ajuste na configuração do ambiente. Sempre que isso ocorrer, é uma boa prática atualizar a página “geral” para que as análises finais reflitam o cenário real, conforme ilustrado na imagem abaixo:
### **Pontos de atenção** Durante os testes, é comum observar comportamentos relevantes que devem ser registrados para avaliação ou considerações futuras. Para esse controle, recomenda-se criar uma página específica na planilha:
### **Teste final** Após a execução do ensaio de testes e ajustes necessários, a equipe e o cliente selecionam os testes mais relevantes para repetição, geralmente os que apresentaram os melhores resultados em termos de parâmetros iniciais, como taxa de sucesso e tempo de resposta. No exemplo, estão destacados os cinco melhores resultados do cenário inicial, considerando a taxa de acerto (sucessos) e o tempo de resposta.
## **Fase 4: Avaliação do resultado final e plano de ação** ### **Análise final dos testes** Com base no teste final, são feitas análises para avaliar os resultados, considerando métricas como **RPS (requisições por segundo)**, **tempo de resposta** e **taxa de acerto**, em correlação com o tamanho da implantação do pipeline (**tamanho × réplicas × threads**).
### **Conclusão dos testes** A etapa é concluída com um relatório que inclui necessidade, contexto, resultados, resumo dos testes, observações sobre taxa de sucesso, configuração da plataforma, ajustes realizados (ensaio e testes finais), pontos de atenção e observações gerais. O relatório pode ser inserido em Markdown na página “conclusão” da Planilha de Plano de Testes:
## **Considerações finais** A estratégia apresentada neste documento garante a execução de um teste de carga **estruturado, controlado e evolutivo**, capaz de indicar não apenas necessidades de escalabilidade dos pipelines envolvidos, mas também possíveis ajustes de capacidade na plataforma. Esse processo é essencial para validar cenários com grandes volumes de transações, nos quais **tempo de resposta** e **estabilidade** são fatores críticos para garantir uma entrada em produção segura, sem riscos. ## **Materiais de apoio** ### **Template de Planilha de Plano de Testes** Para acompanhar os testes, recomenda-se utilizar uma planilha estruturada, conforme o modelo abaixo: {% file src="/files/g3FpUJTHutGs2FMtxg3a" %} ### **Checklist para o teste de carga** Use o checklist a seguir como guia para elaborar um plano de testes de acordo com as orientações deste documento:
Checklist: Orientações para a realização do teste de carga **Fase 1 – Planejamento do teste** 1.0 – Detalhar com o cliente os parâmetros que serão testados: * [x] Quantidade de requisições simultâneas. * [x] Tamanho das mensagens (todos os tamanhos possíveis). * [x] Tempo de resposta esperado. * [x] Necessidades de negócio. * [x] Limites das infraestruturas envolvidas (ex.: *Rate Limit*). * [x] Configuração do ambiente. * [x] Rotas (com peças intermediárias). * [x] Critérios de sucesso e expectativas. 1.1 – Estruturar o plano de testes (Ensaio de testes): * [x] Criar uma planilha com os parâmetros a serem testados, incluindo: * [x] Fluxo a ser testado. * [x] Tamanho da mensagem. * [x] Quantidade de mensagens. * [x] Capacidade dos pipelines (tamanho e réplicas). * [x] Tempos de processamento. * [x] Variar os parâmetros gradativamente, aumentando a carga em relação ao teste anterior. * [x] Alterar somente um parâmetro de cada vez e medir, com evidências documentadas. Por exemplo: - *1 mensagem de 150 KB, Small, 1 réplica* - *2 mensagens de 150 KB, Small, 1 réplica* - *1 mensagem de 150K, Medium, 1 réplica* * [x] Registrar tempos e comportamento de cada uma das variações. Repetir até identificar os limites daquela configuração. **Fase 2 – Preparação do ambiente de teste** * [x] Obter exemplos das mensagens que serão utilizadas. * [x] Registrar parâmetros dos componentes a serem monitorados (gateway, triggers, conexões, entre outros). * [x] Definir ferramentas, relatórios e indicadores de acompanhamento (em conjunto com o time de Produto). * [x] Compartilhar com o time de Produto os parâmetros de teste definidos. * [x] Solicitar ao cliente os recursos necessários para simular steps de acesso externo (mesmo que simulados), como: * [x] Endpoints para requisições * [x] Bancos de dados * [x] Servidor de arquivos * [x] Broker de mensageria * [x] Checklist de preparação – validar se todos os itens estão prontos conforme o planejado: * [x] Requisitos solicitados ao time de infraestrutura concluídos. * [x] Recursos externos solicitados ao cliente disponíveis. * [x] Caso indisponíveis, avaliar alternativas (ex.: mock). * [x] Pré-análise do pipeline para identificar componentes que demandam escala. * [x] Capacidade do ambiente validada. **Fase 3 – Execução** * [x] Iniciar somente após todas as validações da Fase 2. * [x] Seguir o plano de testes definido na Fase 1, executando de forma sequencial. **Fase 4 – Avaliação do resultado final e plano de ação** * [x] Gerar relatório de resultados a partir da Planilha de Plano de Testes. * [x] Avaliar se os requisitos foram atendidos. * [x] Definir se será necessário um novo ciclo de testes. * [x] Caso positivo, solicitar ajustes de infraestrutura e repetir a Fase 3.
--- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.digibee.com/documentation/resources/pt-br/best-practices/load-test.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.