Sistema lento: como diagnosticar antes de escalar

O sistema ficou lento. A tela de pedidos demora para abrir, o relatório do fim do mês trava, o usuário clica duas vezes porque achou que não foi. A primeira sugestão que aparece quase sempre é a mesma: aumentar o servidor.

Às vezes funciona por um tempo. Na maioria das vezes, a lentidão volta, porque o problema nunca foi falta de máquina. Performance é um problema de diagnóstico antes de ser um problema de infraestrutura. Este texto propõe um método, e não uma lista de dicas: medir do jeito certo, achar a operação que domina o tempo e só então escolher a correção.

Servidor maior raramente é a resposta

Aumentar CPU e memória resolve um tipo específico de problema: quando o sistema está, de fato, limitado por recurso e o trabalho que ele faz é necessário. Isso é menos comum do que parece.

O padrão mais frequente é outro. Uma consulta que varre a tabela inteira porque falta um índice. Uma tela que faz centenas de chamadas ao banco para montar uma lista. Um relatório pesado que roda dentro da requisição do usuário. Nesses casos, dobrar o servidor reduz um pouco a espera, mas o custo continua crescendo junto com os dados. Em alguns meses, o problema volta maior e mais caro.

Há também um efeito colateral: servidor maior esconde o sintoma e adia o diagnóstico. Quando a lentidão volta, a base de dados cresceu, o código acumulou mais camadas e achar a causa fica mais difícil. Se a conta de infraestrutura já vem subindo por esse motivo, o texto sobre como reduzir custos de nuvem trata do outro lado do problema.

Medir antes de mexer: percentis, não médias

"Está lento" não é um diagnóstico. O primeiro passo é transformar a percepção em números, e o número certo não é a média.

A média engana. Se a maioria das requisições responde rápido e uma parte leva muito tempo, a média pode parecer aceitável enquanto um grupo de usuários sofre todo dia. Quem abre o chamado é justamente esse grupo.

Percentis contam a verdade. O p50 é o tempo que metade das requisições não ultrapassa. O p95 e o p99 mostram a experiência dos casos mais lentos. Um sistema saudável tem p95 e p99 próximos do p50; quando eles se afastam muito, existe algo específico e identificável causando a cauda.

O que medir, no mínimo:

• Tempo de resposta por rota ou tela, em percentis, e não do sistema como um todo.
• Volume de chamadas por rota, para saber o que é lento e frequente, e não só lento.
• Tempo gasto no banco dentro de cada requisição, separado do tempo gasto no código.
• Uso de recursos do servidor e do banco: CPU, memória, disco e conexões.

Se o sistema não tem nada disso, a primeira correção é instrumentar. Logs estruturados com tempo por requisição, métricas e tracing mostram exatamente onde o tempo vai; o caminho para montar isso está em observabilidade: logs, métricas e traces.

Encontre a operação dominante

Com os números na mão, ordene as operações por tempo total consumido, que é o tempo médio multiplicado pelo volume. Uma consulta rápida executada milhões de vezes pode pesar mais do que um relatório lento que roda uma vez por dia. O esforço vai para o topo dessa lista, não para o que parece mais feio no código.

O banco de dados é o suspeito número um

Na maioria dos sistemas de gestão, a maior parte do tempo de resposta está no banco. Os culpados habituais:

Falta de índice. A consulta filtra por cliente e data, e o banco precisa ler a tabela inteira para achar as linhas. Enquanto a tabela é pequena, ninguém percebe. Quando ela cresce, a lentidão aparece de repente. O plano de execução da consulta, que todo banco relacional mostra, revela esse problema em poucos minutos.

Índice errado ou demais. Índices aceleram leitura e encarecem escrita. Uma tabela com índices para cada combinação possível pode deixar a gravação lenta. O índice certo é o que atende as consultas mais frequentes.

Consultas que trazem demais. Selecionar todas as colunas quando a tela usa três, ou buscar todos os registros para filtrar na aplicação.

Falta de paginação. Uma lista que carrega todos os pedidos da história da empresa para mostrar os vinte primeiros. Funciona no primeiro ano, trava no quinto.

Bloqueios e transações longas. Uma rotina que abre uma transação, faz um processamento demorado e só depois grava segura linhas que outras telas precisam. Os usuários percebem como lentidão intermitente, difícil de reproduzir.

Estatísticas desatualizadas e manutenção esquecida. O otimizador do banco decide o plano de execução a partir de estatísticas. Sem manutenção periódica, ele passa a escolher caminhos ruins.

A boa notícia é que esses problemas costumam ter correção localizada, com efeito grande e sem mudança de arquitetura.

Consultas N+1 e excesso de chamadas

O problema N+1 merece destaque porque é comum em sistemas construídos com ORMs e quase invisível no código.

Funciona assim: a tela lista cinquenta pedidos. O código faz uma consulta para trazer os pedidos e depois, para cada pedido, uma consulta para buscar o cliente, outra para os itens, outra para o vendedor. Uma tela vira dezenas ou centenas de idas ao banco. Cada uma é rápida; a soma não é.

Os sinais são claros quando existe instrumentação: o número de consultas por requisição cresce junto com o tamanho da lista. A correção é carregar os dados relacionados de uma vez, com junções ou consultas em lote, recurso que todo ORM oferece.

O mesmo padrão aparece entre sistemas. Uma tela que chama uma API externa para cada item da lista, ou um serviço interno que consulta outro serviço em laço. Em arquiteturas distribuídas, cada chamada ainda carrega latência de rede, e o efeito é multiplicado; é um dos custos discutidos em monolito ou microsserviços.

Trabalho pesado que deveria ir para uma fila

Nem todo trabalho precisa acontecer enquanto o usuário espera. Gerar um relatório extenso, importar uma planilha grande, enviar centenas de e-mails, emitir notas em lote, recalcular preços: tudo isso pode ser feito em segundo plano.

O desenho é simples de explicar. O usuário pede, o sistema registra o pedido numa fila e responde imediatamente. Um processo separado executa o trabalho e avisa quando terminar. Os benefícios:

• A tela responde na hora, e o usuário não fica preso.
• O trabalho pesado não disputa recursos com as requisições interativas.
• Falhas podem ser reprocessadas automaticamente, sem o usuário repetir a operação.
• Picos são absorvidos: a fila cresce, os trabalhadores processam no ritmo possível.

O cuidado é com a idempotência: se uma tarefa for executada duas vezes por causa de uma falha, o resultado precisa ser o mesmo. E com a experiência do usuário: ele precisa saber em que pé está o que pediu.

Cache: quando ajuda e quando só esconde o problema

Cache é guardar o resultado de uma operação cara para não repeti-la. Bem aplicado, é poderoso. Mal aplicado, cria uma nova classe de problemas.

Ajuda quando o dado é lido muitas vezes e muda pouco: tabelas de configuração, catálogo de produtos, permissões do usuário, resultados de relatórios consolidados. Também ajuda para respostas de serviços externos lentos, respeitando a validade da informação.

Atrapalha quando é usado para esconder uma consulta ruim. O cache expira, a consulta lenta volta a rodar e, se muitos usuários pedirem ao mesmo tempo, todos disparam a consulta pesada juntos. Além disso, cache traz a pergunta mais difícil da computação: quando invalidar. Um saldo de estoque em cache desatualizado vira venda do que não existe.

A regra prática: primeiro torne a operação razoavelmente rápida sem cache. Depois, use cache para ganhar folga, com critério claro de invalidação.

Quando escalar a infraestrutura é a decisão certa

Depois do diagnóstico, escalar pode ser exatamente a resposta. Os sinais de que é o caso:

• O perfil de uso mostra que o trabalho feito é necessário e já está razoavelmente eficiente.
• O recurso saturado é claro: CPU do banco constantemente no limite, memória insuficiente para manter os dados mais usados, disco sem folga de leitura.
• O crescimento de uso é real e previsível, e não um laço de código que multiplica chamadas.

Mesmo aí há escolhas. Escala vertical, uma máquina maior, é simples e muitas vezes suficiente para o banco. Escala horizontal, mais instâncias da aplicação atrás de um balanceador, exige que a aplicação não guarde estado na memória do processo. Réplicas de leitura tiram relatórios e consultas pesadas do banco principal. Cada uma resolve um gargalo diferente, e o diagnóstico diz qual.

Riscos e erros comuns

• Otimizar pelo palpite, mexendo no código que parece lento em vez do que os números mostram.
• Medir só em desenvolvimento, com poucos dados, quando o problema aparece com o volume de produção.
• Corrigir tudo de uma vez, sem saber qual mudança teve efeito.
• Não medir de novo depois e declarar vitória pela sensação.
• Tratar a lentidão como evento isolado, quando ela é sintoma de acúmulo; o tema está em dívida técnica para gestores.

Como medir o sucesso

Defina objetivos por operação, em percentis: a tela de pedidos deve responder abaixo de certo tempo no p95, a importação deve terminar dentro de uma janela aceitável. Acompanhe a evolução depois de cada correção, o número de consultas por requisição nas telas críticas e o consumo de recursos. E acompanhe o que o usuário sente: chamados de lentidão e cliques repetidos.

Antes de trocar o servidor, um diagnóstico

Na Pervian Tech, lentidão é tratada como trabalho de arquitetura de software: instrumentar, medir em percentis, achar a operação dominante e atacar a causa, seja índice, N+1, fila ou, quando for o caso, escala consciente da infraestrutura. Cada sistema tem os seus gargalos, então o plano é sob medida.

O investimento é definido sob consulta, depois de um diagnóstico inicial gratuito que mostra onde o seu sistema realmente perde tempo. Se a solução proposta até agora foi só aumentar o servidor, fale com a gente antes.