O sistema está lento e estou perdendo cliente

Sistema lento se diagnostica por camada, de fora para dentro: rede e front-end, aplicação, banco de dados e, por último, infraestrutura. Essa ordem não é preferência técnica, é economia. As camadas de fora concentram os ganhos mais baratos, e a de dentro, a infraestrutura, é a mais cara e a que menos resolve quando o problema real está em outro lugar. Trocar de servidor antes de medir é o equivalente a comprar um carro maior porque o pneu está murcho.

Meça antes de mexer, e meça de novo depois

Sem número antes, não existe melhoria depois, existe impressão. Registre três coisas:

• Tempo até a página ficar utilizável, medido no navegador, nas três telas mais usadas.
• Tempo de resposta do servidor para as chamadas dessas telas, separado do tempo de carregamento visual.
• Quando acontece. Sempre? Só em horário de pico? Só com um cliente específico? Só a partir de certo volume de dados?

O padrão de ocorrência já elimina metade das hipóteses. Lentidão constante aponta para código ou consulta. Lentidão que aparece no pico aponta para concorrência ou recurso limitado. Lentidão que piora com o tempo aponta para o banco crescendo sem índice.

Anote também o que os usuários dizem. "Demora para salvar" e "demora para abrir a lista" são problemas diferentes em camadas diferentes.

Depois, para cada correção aplicada, três regras evitam otimização baseada em sensação:

1. Uma mudança por vez. Se você criou índice, ativou cache e trocou o servidor no mesmo dia, não sabe o que funcionou.
2. Mesma medição, mesmas condições. Mesma tela, mesmo volume de dados, mesmo horário, mesma rede.
3. Registro simples em tabela: tela, tempo antes, mudança aplicada, tempo depois, data.

Esse registro tem um efeito prático além do técnico: transforma "parece que melhorou" em um número que dá para mostrar a quem aprovou o investimento.

Camada 1: rede e front-end

É onde estão os ganhos mais fáceis e onde quase ninguém olha primeiro. Suspeitos:

• Imagens sem otimização. Fotos de produto enviadas direto da câmera, com vários megabytes, exibidas em miniatura de 200 pixels.
• Excesso de arquivos. Dezenas de scripts e folhas de estilo carregados um a um, muitos deles sem uso naquela página.
• Bibliotecas pesadas para funções simples, como uma biblioteca inteira de gráficos para desenhar uma barra de progresso.
• Ausência de cache no navegador, forçando o usuário a baixar tudo de novo a cada visita.
• Fontes e rastreadores externos que bloqueiam a renderização enquanto respondem.

Sinal claro dessa camada: o servidor responde rápido nas ferramentas de rede do navegador, mas a tela demora a ficar utilizável.

Camada 2: aplicação

Aqui a lentidão é de lógica, não de infraestrutura. Os padrões mais frequentes:

• Consulta dentro de laço. A tela busca 100 pedidos e, para cada um, faz uma nova consulta buscando o cliente. Vira 101 idas ao banco onde bastaria uma.
• Processamento síncrono. Gerar PDF, enviar e-mail, chamar uma API de terceiros ou processar planilha durante o clique do usuário. Se o serviço externo demora, seu sistema demora junto.
• Carregar tudo na memória para filtrar depois em código, quando o banco filtraria muito melhor.
• Falta de paginação em listas que já passaram de alguns milhares de registros.
• Chamadas em série a serviços externos que poderiam acontecer em paralelo.

Sinal claro: uma ação específica demora muito, enquanto o resto do sistema responde bem.

Camada 3: banco de dados

É o gargalo mais comum em sistemas que funcionavam bem e foram piorando.

• Falta de índice nas colunas usadas em filtro, junção e ordenação. Sem índice, o banco varre a tabela inteira a cada consulta.
• Consulta varrendo tabela grande por causa de busca por texto parcial ou função aplicada sobre a coluna.
• Junções demais em uma consulta só, geralmente em telas de relatório.
• Tabela de log ou histórico crescendo sem limpeza nem arquivamento.
• Relatório pesado rodando na mesma base que atende os usuários, competindo por recurso.

Sinal claro: a lentidão piora conforme a base cresce, e as telas afetadas são listagens, buscas e relatórios.

Camada 4: infraestrutura

Só depois das três anteriores. Suspeitos legítimos existem:

• Memória insuficiente, com o servidor usando disco como memória.
• Disco lento ou cheio, que degrada tudo, especialmente o banco.
• Plano compartilhado com recursos limitados e vizinhos barulhentos.
• Distância geográfica entre servidor e usuários, relevante quando a base está fora do país.
• Banco e aplicação disputando o mesmo recurso em uma máquina única.

Sinal claro: o servidor apresenta uso alto e constante de memória, processador ou disco, mesmo com pouca gente usando.

Sintoma, camada provável e como confirmar

O que resolve rápido e barato, e o que é reforma

A linha divisória é simples: se a mudança não altera o comportamento do sistema, é ajuste. Se altera a estrutura dos dados ou a arquitetura, é reforma, e reforma precisa de planejamento, testes e janela de implantação.

Por que trocar de servidor raramente resolve

Servidor maior compra tempo, não corrige causa. Uma consulta que varre uma tabela inteira continua varrendo, apenas com mais recurso para desperdiçar. Num cenário típico, o ganho aparece por algumas semanas e a lentidão volta quando a base cresce mais um pouco, agora com uma conta mensal maior.

Faz sentido migrar quando a medição mostra recurso saturado de forma consistente, quando o plano atual impõe limite rígido de conexões ou processos, ou quando o banco divide máquina com a aplicação e ambos sofrem. Fora disso, migrar é adiar o diagnóstico.

Um último ponto, que a medição também entrega: o momento de parar. Nem todo sistema precisa responder em 200 milissegundos. Ele precisa responder rápido o suficiente para o cliente não desistir no meio, e esse limite quem define é o seu cliente, não a régua técnica.