Tema: performance
-
Profiling contínuo em produção: perfis de amostragem sempre ativos e o que eles respondem
O profiling contínuo coleta perfis de CPU e memória de forma sistemática ao longo do tempo e os armazena como séries com labels, permitindo perguntar qual função consumiu mais CPU na frota ontem ou o que mudou entre duas versões; profilers de amostragem tornam o custo baixo o bastante para mantê-lo ligado, e endpoints de runtime, como /debug/pprof/ do Go, ou agentes eBPF fornecem os perfis.
-
Resumir o tempo gasto em chamadas de sistema com strace -c, seu overhead e o perf trace como alternativa
O strace -c contabiliza tempo, chamadas e erros por chamada de sistema em vez de imprimir cada uma, mas o próprio manual do strace avisa que um processo rastreado roda mais devagar que um não rastreado; o perf trace, descrito como uma ferramenta inspirada no strace e baseada em perf_events em vez de ptrace, é a alternativa mais simples quando esse overhead importa.
-
Benchmark de uma alteração: warm-up, repetições, variância e o que reportar
Uma comparação de tempos só é um resultado se resistir ao ruído: fixe a carga de trabalho, descarte as execuções de warm-up, intercale muitas repetições de cada variante, escolha a estatística antes de ver os dados e reporte a dispersão e o ambiente junto de cada número. Uma diferença menor que a dispersão entre execuções não é uma descoberta.
-
Primeiro olhar sobre o desempenho no Solaris: prstat, vmstat, mpstat, iostat e zpool iostat
prstat -a/-Z, vmstat, mpstat, iostat -xnz e zpool iostat são cinco comandos somente de leitura que respondem à maioria das perguntas iniciais sobre desempenho no Solaris 11.4, com detalhes de zonas e de latência de disco que as ferramentas de nome parecido no Linux apresentam de forma diferente.
-
O método USE para encontrar gargalos de desempenho
Para cada recurso (CPU, memória, discos, rede, locks), verifique utilização, saturação e erros: o método USE é um checklist que localiza gargalos rapidamente, sem começar por suposições sobre a camada da aplicação.
-
Compressão de respostas: onde fazer e o que excluir
Comprima respostas de texto (HTML, JSON, Markdown) no proxy ou na aplicação, evite conteúdo já comprimido e streaming, mantenha os ETags coerentes entre codificações e defina Vary: Accept-Encoding.
-
Qual parte do contexto de um agente é saída de ferramentas em execuções reais, e reduzi-la altera o sucesso da tarefa?
Pergunta em aberto: a especificação do MCP diz que os clientes devem validar os resultados das ferramentas antes de passá-los ao modelo, mas deixa a quantidade a critério do cliente; em execuções de agentes registradas, que fração dos tokens é saída de ferramentas, e não instruções ou raciocínio, e truncar, resumir ou filtrar essa saída altera o sucesso da tarefa, o custo e a latência?
-
Imagens responsivas com srcset, sizes e picture
O srcset com descritores de largura, combinado com o atributo sizes, permite ao navegador escolher o menor arquivo de imagem que preenche o espaço disponível na viewport e na densidade de pixels atuais. Os descritores x servem imagens de tamanho fixo em várias densidades, e o picture com elementos source cobre direção de arte e fallback de formato. Mantenha sempre width e height para que o layout não se desloque durante o carregamento da imagem.
-
Amostragem de contadores de desempenho do Windows Server com Get-Counter e exportação para CSV
O Get-Counter coleta amostras de caminhos de contadores nomeados em um intervalo definido, de forma contínua ou por um número fixo de amostras; o Export-Counter (somente no Windows PowerShell 5.1) preserva todos os campos no formato nativo BLG, e o relog converte uma captura para CSV depois, mesmo sem o comando Export-Counter original.
-
Gerar, criticar, revisar: quando um ciclo de autoverificação compensa
Um ciclo em que o modelo critica e revisa a própria saída melhora os resultados quando a crítica dispõe de um sinal externo (testes, um validador, uma fonte) e de um critério fixo; sem isso, resultados publicados mostram que pode piorar as respostas, e cada rodada acrescenta pelo menos duas chamadas cuja entrada cresce com o rascunho.
-
VACUUM, autovacuum e bloat de tabelas
O MVCC do PostgreSQL deixa versões mortas de linhas após updates e deletes; o VACUUM as recupera, mantém as estatísticas e protege contra o wraparound de IDs de transação. O autovacuum deve permanecer ativo e ser ajustado para tabelas com muito movimento.
-
Carregamento de web fonts: font-display, preload, subconjuntos com unicode-range e fontes de fallback com métricas equivalentes
Mostre texto já na primeira renderização e carregue a fonte da marca sem saltos de layout: divida as fontes em subconjuntos com unicode-range para baixar só os sistemas de escrita usados, escolha font-display conforme o papel do texto (optional no corpo, swap nos títulos), faça preload dos arquivos da primeira renderização com crossorigin e declare uma fonte de fallback com size-adjust e ajustes de ascent/descent para que as linhas quebrem igual antes e depois da troca.
-
Builds de módulos ES com efeitos colaterais declarados reduzem mais o bundle do consumidor do que builds CommonJS
Hipótese: numa biblioteca com muitas funções independentes, o consumidor que importa só algumas obtém um bundle menor quando ela é distribuída como módulos ES com declaração sideEffects do que como CommonJS, pois o tree shaking depende da estrutura estática de import/export; propõe-se uma comparação baseada em fixtures.
-
Quando o asyncio ajuda e quando não ajuda
O asyncio executa muitas tarefas limitadas por I/O em uma única thread, suspendendo nos pontos de await; não acelera código limitado por CPU, e chamadas bloqueantes dentro de corrotinas travam o loop inteiro.
-
Web Vitals: o que LCP, INP e CLS medem
Os Core Web Vitals são três métricas de campo: Largest Contentful Paint (tempo de renderização do maior elemento visível, meta de 2,5 s), Interaction to Next Paint (maior latência de interação, meta de 200 ms) e Cumulative Layout Shift (deslocamento inesperado de conteúdo, meta de 0,1), cada uma avaliada no percentil 75 dos carregamentos de página.
-
Quando o roteamento no cliente ainda compensa, agora que os navegadores oferecem bfcache, prerendering e view transitions entre documentos?
Pergunta em aberto: os roteadores in-page foram adotados para evitar carregamentos completos de página, ao custo de servir o shell, tratar 404, restaurar scroll e foco e depender de um bundle que precisa chegar primeiro; o back/forward cache, a Speculation Rules API e as view transitions entre documentos já atendem às motivações originais em sites multipágina. Em quais sites e padrões de interação um roteador in-page ainda leva vantagem mensurável?
-
Como encontrar um vazamento de memória com snapshots do tracemalloc
Inicie o rastreamento cedo com PYTHONTRACEMALLOC ou tracemalloc.start(nframe), tire um snapshot após o aquecimento e outro após N iterações, filtre o ruído de imports e leia compare_to(..., 'lineno') para achar linhas cujo tamanho cresce proporcionalmente a N; troque para o agrupamento 'traceback' para ver quem as chama.
-
Diagnóstico de desempenho no Terminal do macOS: top, vm_stat, memory_pressure, fs_usage e powermetrics
O macOS traz ferramentas de herança BSD e específicas da Apple que cobrem boa parte do que top, vmstat, iostat e strace fazem no Linux, com nomes, unidades e exigências de privilégio diferentes: top -o cpu, vm_stat, memory_pressure, iostat, fs_usage, powermetrics e sample <pid>.
-
CPU e E/S por processo com pidstat e /proc/<pid>/io: como encontrar a causa do I/O wait
O pidstat informa CPU, memória e E/S de disco por tarefa, sem precisar filtrar um nome na saída do top; ler /proc/<pid>/io diretamente separa a E/S lógica (rchar/wchar, incluindo cache) da E/S física (read_bytes/write_bytes) que de fato chega ao dispositivo.
-
Como escolher entre threads, processos e asyncio para uma carga de trabalho em Python
Classifique primeiro o caminho crítico: espera por I/O combina com asyncio (muitas conexões, bibliotecas assíncronas) ou com um pool de threads (poucas chamadas bloqueantes); trabalho de CPU em Python puro exige processos ou um build free-threaded; código nativo que libera a GIL pode usar threads. Limite todos os pools, escolha explicitamente o método de início de processos e escreva o caminho de encerramento.
Legível por máquina: JSON