Guia de otimização de desempenho para aplicações Go

Guia de otimização de desempenho para aplicações Go

• Coletânea de materiais técnicos para desenvolvimento de aplicações Go de alto desempenho
• Fornece padrões práticos, exemplos e insights de desempenho de baixo nível para engenheiros que desenvolvem APIs de alto desempenho, microsserviços e sistemas distribuídos
• Embora Go não ofereça tantas opções de ajuste de desempenho quanto C++ ou Rust, ele oferece várias oportunidades de otimização, como reutilização de memória, controle de alocações, rede eficiente e processamento concorrente
• Este guia foca em técnicas de melhoria de desempenho mensuráveis, cobrindo desde recursos centrais da linguagem até estratégias avançadas de rede

Conteúdo abordado até agora

Padrões comuns de desempenho em Go

• Primeiro artigo que organiza os principais padrões de desempenho que todo desenvolvedor Go deveria conhecer
• Principais tópicos:
  • Uso eficaz de sync.Pool
  • Evitar alocações de memória desnecessárias
  • Otimização de layout de structs e alinhamento de memória
  • Tratamento eficiente de erros
  • Abstração de custo zero por meio de interfaces
  • Reutilização de slices e técnicas de ordenação in-place
• Escrito com base em casos reais de trabalho, incluindo benchmarks e exemplos de código prontos para copiar

Conteúdo que será abordado em seguida

Rede de alto desempenho em Go

• Está prevista uma análise aprofundada sobre a construção de serviços de rede de alto desempenho com uso da biblioteca padrão e de bibliotecas externas
• Tópicos que serão abordados:
  • Uso eficiente de net/http e net.Conn
  • Tratamento de conexões simultâneas em grande escala
  • Ajuste de desempenho com epoll/kqueue, GOMAXPROCS etc.
  • Técnicas de teste de carga e diagnóstico de gargalos
  • Quando usar bibliotecas de rede de baixo nível como fasthttp e como equilibrar isso com a manutenibilidade

Público-alvo

• Engenheiros de backend que otimizam serviços Go em produção
• Desenvolvedores que lidam com sistemas sensíveis à latência
• Times que estão migrando para Go ou construindo caminhos de alto desempenho
• Desenvolvedores interessados no modelo de desempenho e nos trade-offs de Go

[GN⁺]

Comentários no Hacker News

• Ao ver o primeiro exemplo, de pool de objetos, fiquei surpreso que isso seja possível sem aviso

  • Essa API existia antes dos genéricos, por isso usa any
  • Em princípio, Golang tem um sistema de tipos forte, mas na prática há muitas APIs que escapam do sistema de tipos
  • Isso faz questionar se o sistema de tipos é realmente tão útil
  • Também chama atenção o fato de não existir uma API para redefinir valores para o valor padrão inicializado

• O guia de desempenho recomenda minimizar alocações para reduzir o tempo de GC

  • A fase de marcação do GC consome tempo, e é melhor evitar alocações de longa duração
  • Alocações de curta duração quase não afetam o tempo de GC
  • Em apps reais, é quase impossível evitar GC, e reduzir o tempo de marcação do GC é mais eficaz

• Além disso...

  • Guia de otimização de Go
  • Guia de Go da Uber
  • Ao alternar entre projetos em várias linguagens durante 6 meses, é difícil lembrar das coisas importantes

• Zero-copy é subestimado

  • As interfaces de Go são adequadas para escrever código zero-copy, mas é preciso cuidado
  • Muitas vezes percebe-se quanto tempo é gasto com alocação e movimentação de memória

• GOMEMLIMIT já ajudou várias vezes

  • É útil em produção containerizada e resolve problemas de falta de memória no CI
  • Ao migrar para nogo, os problemas do golangci-lint foram resolvidos

• Curiosidade sobre quais projetos realmente precisam de otimização

  • Ex.: alinhamento de campos de struct

• Ao ler a documentação de object pooling, bateu a curiosidade se há planos para tornar pacotes como sync genéricos

• Surpreendente como Golang é parecido com C em alinhamento de structs

• "A struct Data contém um array [1024]int, o que dá 4 KB"

  • Fica a dúvida se alguém ainda usa arquitetura de 32 bits como padrão

• Você pode se enganar usando sync.Pool

  • O pprof parece bom no benchmark porque não há alocações, mas o uso real de memória aumenta
  • É importante medir os ganhos no mundo real