API Spring Boot lenta: como investigar antes de trocar servidor

Quando uma API Spring Boot fica lenta, a primeira reacao costuma ser trocar servidor, aumentar memoria ou culpar o banco. As vezes isso resolve por alguns dias. Em outros casos, apenas esconde a causa real: query sem indice, N+1 em ORM, chamada externa lenta, payload grande, lock no banco, pool de conexoes saturado, log excessivo ou endpoint fazendo mais trabalho do que deveria.

Performance nao deve ser investigada por palpite. Uma API lenta precisa ser observada em camadas: requisicao, aplicacao, banco, integracoes, infraestrutura e experiencia do usuario. O objetivo deste guia e organizar uma investigacao pratica para pequenas empresas e equipes Java antes de gastar com servidor ou iniciar uma refatoracao sem evidencias.

1. Defina o que significa lenta

Antes de procurar causa, defina o sintoma. "Esta lento" pode significar coisas diferentes:

• a pagina demora para carregar porque a API responde devagar;
• um endpoint especifico demora em horarios de pico;
• o primeiro acesso depois de um tempo parado e lento;
• o tempo varia muito entre requisicoes parecidas;
• o backend responde rapido, mas o frontend processa muito dado;
• a lentidao aparece apenas para alguns usuarios, regioes ou redes.

Sem delimitar o sintoma, a equipe mede tudo e nao conclui nada. Comece registrando endpoint, horario, usuario afetado, tamanho da resposta, status HTTP, tempo total e frequencia.

A pagina de evidencias tecnicas ajuda a listar o que coletar antes de mexer no codigo.

2. Meça tempo por camada

O tempo percebido pelo usuario e a soma de varias partes. Separar essas partes evita conclusoes erradas.

• Navegador: DNS, TLS, rede, download, renderizacao e JavaScript.
• Nginx/proxy: tempo para encaminhar e receber resposta do backend.
• Spring Boot: controller, service, validacoes, serializacao e regras de negocio.
• Banco: conexao, query, lock, indice, volume e transacao.
• Integracoes: APIs externas, SMTP, storage, gateways ou filas.

Se possivel, registre um identificador de requisicao e acompanhe o mesmo request em logs do proxy, backend e banco. A partir dai, a pergunta muda de "esta lento" para "qual camada consumiu mais tempo?".

O artigo Observabilidade minima para APIs Spring Boot aprofunda essa base de logs e sinais.

3. Olhe primeiro para endpoints mais afetados

Nem toda lentidao merece a mesma prioridade. Liste os endpoints por impacto:

• quantidade de chamadas;
• tempo medio e percentis altos;
• erro 500 ou timeout associado;
• impacto em venda, atendimento ou operacao;
• dependencia de outros sistemas;
• horario em que piora.

Um endpoint raro e lento pode ser menos urgente que um endpoint chamado a cada carregamento da tela principal. O priorizador tecnico pode ajudar a ordenar esse tipo de decisao.

4. Verifique o banco antes de culpar o Java

Em sistemas corporativos, uma parte grande da lentidao aparece no banco. Isso nao significa que o banco seja ruim; significa que a aplicacao pode estar fazendo consultas demais, consultando sem indice ou trazendo mais dados do que precisa.

Pontos para verificar:

• query sem indice em coluna usada para filtro ou ordenacao;
• consulta que retorna milhares de linhas sem paginacao;
• relacionamentos carregados automaticamente sem necessidade;
• N+1 em JPA/Hibernate;
• transacao longa segurando lock;
• relatorio pesado rodando no mesmo banco operacional;
• pool de conexoes insuficiente ou saturado.

Uma boa investigacao compara o tempo do endpoint com o tempo das queries. Se o endpoint demora oito segundos e uma query consome sete, aumentar CPU da aplicacao talvez nao seja o melhor primeiro passo.

5. Procure N+1 e carregamento exagerado

N+1 acontece quando a aplicacao faz uma consulta principal e depois dispara varias consultas adicionais para buscar dados relacionados. Em desenvolvimento, com poucos dados, isso pode parecer normal. Em producao, com volume real, vira lentidao.

Sinais comuns:

• muitas queries parecidas no log;
• tempo cresce conforme aumenta a quantidade de registros;
• endpoint de listagem fica muito mais lento que detalhe individual;
• DTO retorna campos que a tela nao usa;
• relacionamentos JPA sao carregados por conveniencia, nao por necessidade.

A correcao pode envolver DTOs mais objetivos, queries especificas, fetch controlado, paginacao ou separacao entre listagem e detalhe. O checklist de API REST ajuda a revisar contratos, payload e comportamento de endpoints.

6. Avalie payload e serializacao

Uma API pode consultar rapido e ainda assim responder devagar se o payload for grande demais. JSON enorme, campos desnecessarios, listas sem paginação e relacionamentos aninhados aumentam tempo de rede, memoria, serializacao e processamento no frontend.

Verifique:

• tamanho da resposta em KB ou MB;
• quantidade de itens retornados;
• campos nao usados pela tela;
• objetos aninhados demais;
• compressao HTTP;
• paginacao, filtro e ordenacao.

Em APIs pequenas, reduzir payload pode ser mais eficiente do que mexer na infraestrutura. O contrato da API deve entregar o que o consumidor precisa, nao o que a entidade interna carrega.

7. Investigue chamadas externas e timeouts

Se o endpoint chama outro servico, gateway, storage, API de terceiro ou SMTP, a lentidao pode estar fora do processo Java. Mesmo assim, a aplicacao precisa lidar com isso de forma previsivel.

Cuidados importantes:

• definir timeout de conexao e leitura;
• registrar tempo de cada chamada externa;
• evitar chamada externa dentro de loop;
• separar tarefa lenta em processamento assíncrono quando fizer sentido;
• mostrar resposta clara ao usuario quando uma dependencia falha;
• nao deixar threads presas indefinidamente.

Timeout inexistente transforma lentidao externa em esgotamento interno. A API fica esperando, o pool de threads enche e outros endpoints podem ser afetados.

8. Confira pool, memoria e threads com cuidado

Infraestrutura importa, mas deve ser lida junto com o comportamento da aplicacao. CPU alta, memoria pressionada ou pool saturado sao sintomas; a causa ainda precisa ser descoberta.

Observe:

• uso de CPU durante o endpoint lento;
• memoria e pausas de garbage collection;
• pool de conexoes com banco;
• threads ocupadas aguardando I/O;
• limites de container;
• recursos da VPS compartilhados com outros servicos;
• logs de restart ou health check falhando.

Se a VPS roda frontend, backend, banco e outros sistemas, tambem vale verificar concorrencia por recurso. A pagina de Java e Spring Boot e o hub de APIs REST e integracoes ajudam a navegar pelos temas relacionados.

9. Crie um teste reproduzivel

Depois de levantar suspeitas, crie um teste reproduzivel. Pode ser simples:

1. Escolha um endpoint e um conjunto de parametros.
2. Execute algumas chamadas em ambiente controlado.
3. Registre tempo total, status e tamanho da resposta.
4. Compare com logs da aplicacao e do banco.
5. Aplique uma mudanca pequena.
6. Repita a medicao.

Sem repetir a medicao, a equipe pode confundir variacao normal com melhoria real. Performance precisa de antes e depois.

10. Erros comuns ao corrigir API lenta

Alguns atalhos custam caro:

• aumentar servidor sem medir gargalo;
• adicionar cache antes de corrigir query errada;
• otimizar endpoint pouco usado enquanto a tela principal segue lenta;
• remover validacao importante para ganhar alguns milissegundos;
• usar logs demais em producao e piorar a lentidao;
• criar indice sem entender impacto em escrita;
• ignorar timeout de chamadas externas;
• comparar ambiente local pequeno com producao cheia de dados.

Cache, indice e infraestrutura sao ferramentas boas, mas precisam de contexto. A pergunta correta e: qual evidencia mostra que essa mudanca atua na causa dominante?

11. Checklist de investigacao

1. Defina endpoint, horario, usuario e impacto.
2. Meça tempo total e tamanho da resposta.
3. Compare navegador, proxy, backend e banco.
4. Identifique queries lentas e volume retornado.
5. Procure N+1, payload grande e falta de paginacao.
6. Verifique chamadas externas e timeouts.
7. Observe pool de conexoes, threads, CPU e memoria.
8. Crie teste reproduzivel.
9. Aplique uma mudanca pequena por vez.
10. Registre evidencia de antes e depois.

Se a lentidao afeta cliente, venda ou operacao, trate como diagnostico tecnico, nao como ajuste estetico. A pagina de diagnostico tecnico pode ser o proximo passo quando a empresa precisa transformar sintomas em plano de correcao.

Uma API Spring Boot lenta raramente precisa de chute. Ela precisa de sinais. Com logs, metricas, queries, payload e infraestrutura observados em conjunto, a equipe deixa de brigar com sintomas e passa a corrigir a causa certa.