Guide d’optimisation des performances des applications Go

Guide d’optimisation des performances des applications Go

• Recueil de ressources techniques pour développer des applications Go hautes performances
• Fournit des patterns pratiques, des cas concrets et des analyses de bas niveau sur les performances aux ingénieurs qui développent des API, des microservices et des systèmes distribués à hautes performances
• Go n’offre pas autant d’options de réglage des performances que C++ ou Rust, mais propose de nombreuses possibilités d’optimisation, comme la réutilisation de la mémoire, le contrôle des allocations, un networking efficace et la gestion de la concurrence
• Ce guide met l’accent sur des techniques d’amélioration mesurables des performances, des fonctionnalités clés du langage jusqu’aux stratégies avancées de networking

Contenu couvert à ce jour

Patterns de performance Go courants

• Premier article qui récapitule les patterns de performance essentiels que tout développeur Go devrait connaître
• Principaux sujets :
  • utilisation efficace de sync.Pool
  • prévention des allocations mémoire inutiles
  • optimisation de la disposition des structures et de l’alignement mémoire
  • gestion efficace des erreurs
  • abstraction à coût nul via les interfaces
  • techniques de réutilisation des slices et de tri sur place
• Basé sur des cas réels, avec benchmarks et exemples de code réutilisables

Contenu à venir

Networking haute performance en Go

• Une analyse approfondie est prévue sur la construction de services réseau hautes performances à l’aide de la bibliothèque standard et de bibliothèques tierces
• Sujets abordés :
  • utilisation efficace de net/http et net.Conn
  • gestion de connexions simultanées à grande échelle
  • réglage des performances avec epoll/kqueue, GOMAXPROCS, etc.
  • techniques de test de charge et de diagnostic des goulots d’étranglement
  • quand utiliser des bibliothèques réseau de bas niveau comme fasthttp, et comment équilibrer cela avec la maintenabilité

Public visé

• Ingénieurs backend qui optimisent des services Go en production
• Développeurs travaillant sur des systèmes sensibles à la latence
• Équipes en cours de migration vers Go ou de construction de chemins critiques à haute performance
• Développeurs intéressés par le modèle de performance de Go et ses compromis

[GN⁺]

Avis sur Hacker News

• En voyant le premier exemple sur le pool d’objets, surprise de constater que c’est possible sans avertissement

  • Cette API existait avant les génériques, donc elle utilise any
  • En principe, Golang a un système de types fort, mais en pratique il existe beaucoup d’API qui le contournent
  • Cela amène à se demander si le système de types est réellement si utile
  • Il est aussi notable qu’il n’existe pas d’API pour réinitialiser une valeur à sa valeur par défaut initialisée

• Le guide de performance recommande de minimiser les allocations afin de réduire le temps passé par le GC

  • La phase de marquage du GC consomme du temps, et il vaut mieux éviter les allocations à longue durée de vie
  • Les allocations de courte durée de vie n’ont presque aucun impact sur le temps du GC
  • Dans une application réelle, il est presque impossible d’éviter complètement le GC, et il est plus efficace de réduire le temps de marquage du GC

• En complément...

  • Guide d’optimisation Go
  • Guide Go d’Uber
  • Pendant six mois à passer d’un projet dans un langage à l’autre, il est difficile de se souvenir des points importants

• Le zéro copie est sous-estimé

  • Les interfaces de Go sont adaptées à l’écriture de code zéro copie, mais il faut faire attention
  • On se rend souvent compte que beaucoup de temps est consacré aux allocations et aux déplacements en mémoire

• GOMEMLIMIT a aidé à plusieurs reprises

  • Utile en production conteneurisée, et a résolu des problèmes de mémoire insuffisante en CI
  • Le passage à nogo a permis de résoudre les problèmes avec golangci-lint

• Curiosité à propos des projets qui ont besoin d’optimisation

  • Exemple : l’alignement des champs de structures

• En lisant la documentation sur le pooling d’objets, on se demande s’il est prévu de rendre génériques des packages comme sync

• Surprise de voir que Golang ressemble à C sur l’alignement des structures

• « La structure Data contient un tableau [1024]int, ce qui fait 4 Ko »

  • On se demande s’il y a encore des gens qui utilisent par défaut une architecture 32 bits

• On peut se mentir à soi-même avec sync.Pool

  • pprof donne une bonne impression dans les benchmarks puisqu’il n’y a pas d’allocations, mais l’utilisation mémoire réelle augmente
  • Il est important de mesurer les bénéfices dans des conditions réelles