Melhores Práticas de Desempenho

Árvore de decisão de otimização e quando parar de ajustar.

Aplique estas regras em revisões de design, postmortems de incidentes e PRs de otimização para que a equipe meça primeiro, altere uma variável por vez e pare quando os SLOs forem atendidos.

Como Usar Esta Lista

• Exija perfil ou evidência de benchmark antes de mesclar reescritas de caminhos críticos.
• Percorra os níveis A a D em ordem durante incidentes - não pule para os botões de GC.
• Codifique os itens do Nível A em modelos de serviço (admin pprof, timeouts, CI de benchmark).
• Emparelhe cada alteração de ajuste com valores de rollback e painéis de SLI.

A - Meça antes de alterar o código

• Reproduza com cargas de trabalho e concorrência de tamanho de produção. Entradas sintéticas minúsculas escondem custos reais de alocação e bloqueio.
• Capture perfis de CPU e heap sob carga, não em pods ociosos. Perfis vazios desperdiçam tempo de investigação.
• Anexe a saída de go test -bench / benchstat para alterações de biblioteca. Alegações de micro exigem prova de micro.
• Registre a versão do Go, GOMAXPROCS e as configurações do gerador de carga nos PRs. Números sem contexto não são reproduzíveis.
• Compare uma alteração por vez. Refatorações mistas tornam a atribuição impossível.

B - Corrija o gargalo certo

• Leia o tempo plano de CPU em seu módulo antes de editar wrappers da stdlib. O tempo cumulativo em net/http é frequentemente o seu manipulador.
• Emparelhe perfis de CPU com alloc_space do heap quando GC ou latência de cauda importam. A agitação de alocação impulsiona a frequência de pausas.
• Use o trace de execução quando a CPU estiver baixa, mas a latência estiver alta. Scheduler, syscall e esperas STW aparecem na linha do tempo.
• Corrija IO, pooling e contenção antes de otimizar loops de hash. Rede e bloqueios dominam muitos serviços.
• Execute a análise de escape (-gcflags=-m) quando benchmem mostrar alocações surpresa. Fatos do compilador superam suposições.

C - Escreva caminhos críticos cientes de alocação

• Pré-dimensionar slices e mapas quando o comprimento for limitado. make([]T, 0, n) e dicas de mapa reduzem cópias de crescimento.
• Construa strings com strings.Builder em loops. Evite concatenação += em middleware crítico.
• Prefira semântica de valor para structs pequenas quando as APIs permitirem. Ponteiros desnecessários aumentam o trabalho de varredura do GC.
• Introduza sync.Pool apenas após vitórias de alocação medidas. Pools adicionam complexidade e risco de estado obsoleto.
• Transmita respostas em vez de armazenar em buffer []byte gigantes. Picos de memória se tornam eventos de GC sob carga.

D - Compilador, PGO e GC (últimos recursos)

• Atualize default.pgo nos trens de lançamento para binários estáveis vinculados à CPU. Perfis desatualizados enganam o compilador.
• Defina GOMEMLIMIT perto dos limites de memória do pod antes que incidentes OOM se repitam. Limite suave aciona o GC mais cedo, não capacidade mágica.
• Ajuste GOGC em canários com p99 e barreiras de proteção de CPU. Documente as variáveis de ambiente de rollback no runbook.
• Re-benchmark após atualizações da toolchain do Go. GC Green Tea e regras de inlining evoluem entre os lançamentos.
• Pare de ajustar quando os SLOs estiverem verdes e mudanças adicionais prejudicarem a clareza. Registre a decisão de parar no PR.

E - Higiene de serviço e operações

• Exponha pprof apenas em portas de admin autenticadas ou localhost. /debug/pprof público é um risco de segurança e DoS.
• Defina timeouts de cliente HTTP e reutilize Transport por upstream. http.DefaultClient não tem timeout.
• Alinhe GOMAXPROCS com a cota de CPU do contêiner. A latência da fila executável aparece nos traces quando desalinhada.
• Rastreie regressões de desempenho em testes de carga de staging. Capture regressões de alocação antes dos deploys de produção.
• Trate unsafe e //go:noinline como exceções revisadas. Exija ADR ou evidência de benchmark.

Quando Você Terminar

Os níveis A a C devem ser satisfeitos antes que experimentos do Nível D sejam enviados para produção.

Se a latência p99, a taxa de erro e as métricas de custo atenderem aos SLOs acordados, adie a otimização adicional até a próxima regressão medida.

A clareza vence a revisão padrão, a menos que evidências mostrem uma exceção de caminho crítico.

FAQs

Relacionados

• Desempenho em Go: Meça, Perfilar, Depois Otimize - visão geral da seção
• Noções Básicas de Desempenho - exemplos iniciais executáveis
• Perfilagem de CPU e Heap com pprof - coleta de evidências
• Regras de Desempenho: Quando Otimizar - folha de consulta de política
• Ajuste de GC para Serviços Sensíveis à Latência - experimentos controlados de GC

Links Relacionados Externos

• Effective Go - Guia oficial para escrever Go claro e idiomático.
• Go Blog (Oficial) - Anúncios oficiais, mergulhos profundos e notas de lançamento.
• pkg.go.dev - Documentação oficial de pacotes e site de descoberta.
• Concurrency in Go - Katherine Cox-Buday.
• Learning Go (2nd Edition) - Jon Bodner.

Versões de Stack: Esta página foi escrita para Go 1.26.x (Green Tea GC padrão, go fix modernizers - verifique o patch na compilação), chi (última versão - verifique na compilação), gin (última versão - verifique na compilação), echo (última versão - verifique na compilação), google.golang.org/grpc (última versão - verifique na compilação), sigs.k8s.io/controller-runtime (última versão - verifique na compilação), kubebuilder (última versão - verifique na compilação), tinygo (última versão - verifique os alvos de placa na compilação), wazero (última versão - verifique na compilação) e golangci-lint (última versão - verifique o conjunto de linters na compilação).