# 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](https://app.gitbook.com/s/cO0A6g1dOsu8BiHYqO67/development-cycle/overview/runtime/autoscaling) 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](https://app.gitbook.com/s/raAdQeslZX4ctbTfiN6W/licensing-models)): * **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="" %} ### **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.