Primeiro Problema: O Log Padrão Não Registra Tempo
O formato padrão do log de acesso não registra o tempo de resposta. Isso engana, pois rota barata em volume alto pode parecer o vilão, enquanto rota cara em volume baixo desaparece. Para contabilizar o tempo de CPU de forma precisa, o formato do log precisa ser alterado.
Separando Robôs de Gente
O user-agent é uma declaração, não uma evidência. O comportamento é a evidência mais simples: pessoas que abrem uma página carregam o CSS e o JS junto. O coletor não carrega esses arquivos. Isso explica por que o cache não ajudou: a média de 2,18 acessos por endereço em uma semana é alta, e o coletor carrega a geração inteira e não reaproveita nada.
Negando o Robots.txt
O robots.txt é um pedido educado, mas quem respeita já respeitava. Negar regras de acesso custa, pois quando a regra decide barrar, o handshake TLS já aconteceu. A regra escrita na aplicação, depois de abrir conexão com o banco, devolve quase nada. Ela precisa estar antes.
Quatro Mudanças para Melhorar a Conta de CPU
- Versão barata das rotas caras para quem não é gente, com a mesma informação e sem as consultas que montam a visão completa.
- Cache com chave por combinação de parâmetros e TTL generoso.
- Canonical apontando para a versão sem filtro.
- Limite por faixa e por sistema autônomo na borda.
Conclusão
Duas semanas depois das mudanças, a fatia do primeiro balde caiu para perto de 20% do tempo de processamento, e o p95 das rotas de relatório caiu quase pela metade. As duas instâncias continuam não aprovadas. Este guia fornece insights valiosos para otimizar a conta de CPU de aplicações web.