11 commentaires
Si ton cache est en lecture seule majoritaire, sync.RWMutex est préférable, mais si tu as beaucoup d'écritures, le sharding de ton cache est la seule solution viable. Voici un pattern classique pour découper ça :
type ShardedCache struct { shards []*Shard }
Attention aussi au nombre de goroutines. Si tu as 10k goroutines qui se battent pour un seul lock, le scheduler Go va passer son temps à faire du context switching.
Et si tu peux, essaie d'utiliser des canaux pour gérer le flux au lieu des locks si la logique le permet.
C'est plus propre en effet. Tiens-nous au courant du delta de performance.
Laisser une réponse
Vous devez être connecté pour poster un message !
Salut à tous, j'ai une problématique assez spécifique sur un microservice écrit en Go. On observe des pics de latence P99 assez violents corrélés avec des phases de forte contention sur les mutex. J'ai utilisé
go tool pprofet le graphe de blocage montre que nos goroutines passent un temps fou à attendre sur unsync.Mutexglobal dans notre couche de cache.Avez-vous des retours sur l'utilisation de
sync.Mapou du sharding de mutex pour limiter ce phénomène ? Ne pas verrouiller trop large semble être la règle, mais je cherche une approche plus fine pour diagnostiquer ce bottleneck sans impacter le débit.