11 commentaires
Le sharding de map est généralement bien plus performant que sync.Map si tu as beaucoup d'écritures concurrentes.
C'est ce que je craignais, ça demande pas mal de refactoring sur la logique métier.
Tu peux essayer un sharded map avec 32 ou 64 shards pour réduire drastiquement la contention sur le lock global.
Mes clés sont des UUID v4, donc la distribution devrait être assez uniforme.
Dans ce cas, le sharding est ta meilleure option. sync.Map est optimisé pour des cas très spécifiques (clés stables, peu d'écritures).
Utilise go test -bench avec -benchmem pour valider que ton implémentation sharded est bien plus rapide.
Si tu peux, essaie d'utiliser des types atomiques au lieu de locks pour les compteurs simples.
Je vais implémenter le sharding. Merci à tous pour les conseils, ça m'évite de foncer dans le mur avec sync.Map.
Laisser une réponse
Vous devez être connecté pour poster un message !
Je suis confronté à des latences p99 qui explosent sur une application Go haute performance. Après analyse avec
go tool pprof, il semble que j'ai une grosse contention sur unsync.RWMutex.Le verrou est utilisé dans une map partagée. Quelle est la meilleure approche pour scaler ça ? Est-ce que le
sync.Mapest vraiment plus efficace en écriture ou devrais-je passer sur du sharding de map ?