Boas Práticas de Performance

Analise a performance com concorrência semelhante à de produção, não com requisições simples. Estas regras mantêm as APIs Node.js rápidas sob tráfego real.

Como Usar Esta Lista

• Estabeleça uma linha de base de p95/RPS com k6 antes de qualquer sprint de otimização.
• Combine testes de carga com clinic.js quando a latência regredir sem erros óbvios.
• Revise antes de enviar endpoints de lista, uploads de arquivos ou novas cadeias de middleware.
• Reexecute os limites em CI após atualizações de dependência.

A - Meça Primeiro

• Registre a latência p95, a taxa de erros e o RPS antes de alterar o código. Números superam a intuição em discussões de PR.
• Use concorrência sustentada (50+ VUs), não requisições únicas. Bloqueios só aparecem quando as requisições se sobrepõem.
• Exporte o atraso do loop de eventos p99 de monitorEventLoopDelay. O atraso do loop prevê problemas para o usuário precocemente.
• Defina limites de k6 em CI para cenários de fumaça. Falhe em merges quando o p95 regredir além do SLO.
• Faça benchmark do staging com volume de dados semelhante ao de produção. Bancos de dados vazios mentem sobre o custo de consulta e serialização.

B - Higiene da Thread Principal

• Sem trabalho síncrono intensivo em CPU no caminho da requisição. Mova hashing, geração de PDF e redimensionamento de imagem para workers.
• Limite o tamanho do corpo JSON no parser (limit: "1mb" ou mais restrito). Rejeite abusos antes que JSON.parse seja executado.
• Simplifique as formas de resposta nas camadas de banco de dados e mapeador. Nunca serialize entidades ORM completas para clientes.
• Evite APIs *Sync de fs e crypto em manipuladores HTTP. Use variantes de promise/async.
• Desabilite logging verboso e pino-pretty durante a análise de performance. I/O de log distorce os resultados do clinic e de carga.

C - Serialização e Memória

• Use JSON Schema + fast-json-stringify em caminhos de leitura intensivos. Fastify faz isso por padrão quando os schemas são definidos.
• Paginação em endpoints de lista. Arrays grandes multiplicam o custo de serialização e GC.
• Corrija vazamentos de heap antes de aumentar --max-old-space-size. Use snapshots em staging, não adivinhação.
• Defina o heap para ~60-70% do limite de memória do contêiner. Deixe margem para buffers nativos e TLS.
• Transmita downloads grandes em vez de armazenar em buffer na memória. Respostas fragmentadas estabilizam o RSS.

D - Ferramentas e Análise de Performance

• Execute clinic Doctor primeiro, Flame para CPU, Bubbleprof para async. Combine a ferramenta com o sintoma.
• Gere carga durante a captura do Flame (autocannon ou k6). Servidores ociosos produzem gráficos vazios.
• Analise builds de produção compilados quando possível. Source maps melhoram os nomes de símbolos.
• Documente o ponto de saturação (VUs onde o p99 dispara). Autoscaling e dimensionamento de pool dependem disso.
• Reanalise após grandes atualizações do Node. O comportamento do GC e da pilha HTTP muda entre as linhas LTS.

E - Arquitetura e Escala

• Paralelize I/O independente com Promise.all. Cadeias await seriais adicionam latência linearmente.
• Dimensionamento correto de pools de conexão de banco de dados e HTTP. Espera no pool aparece como latência do aplicativo, não CPU do banco de dados.
• Saiba quando o ajuste do Express não é suficiente. Veja Performance no Express vs ADR do Fastify.
• Escale réplicas para trabalho limitado por I/O; workers para trabalho limitado por CPU. Escala horizontal não corrige bloqueios na thread principal.
• Defina SLOs de performance juntamente com a disponibilidade. Vincule a orçamentos de erro em SLOs e Orçamentos de Erro.

FAQs

Relacionado

• Noções Básicas de Performance - exemplos introdutórios
• Testes de Carga - cenários k6
• Suite clinic.js - ferramentas de análise de performance
• Boas Práticas do Event Loop - padrões não bloqueantes

Versões da Stack: Esta página foi escrita para Node.js 24.18.0 (Active LTS), npm 10+, TypeScript 5.6+, Express 5, Fastify 5 e NestJS 11.