Une seule session mgo.Session est-elle suffisante pour une utilisation simultanée dans une application Web Go ?

Considérations sur la concurrence dans MongoDB avec gopkg.in/mgo.v2

Lors de l'intégration de MongoDB dans une application Web Go à l'aide de gopkg.in/mgo .v2, il est essentiel de prendre en compte les meilleures pratiques de concurrence pour des performances et une utilisation optimales des ressources. Cet article répond à la question suivante :

Un seul mgo.Session peut-il être utilisé simultanément dans une application Web, comme dans un http.Handler, ou Session.Copy et Session.Close doivent-ils être utilisés pour créer plutôt un pool de sessions ?

Explication :

Le mgo.Session, contrairement aux hypothèses initiales, est en effet sûr pour une utilisation simultanée. Comme indiqué dans la documentation officielle, "Toutes les méthodes de session sont sécurisées en matière de concurrence et peuvent être appelées à partir de plusieurs goroutines."

Cependant, cela n'implique pas que l'utilisation d'un seul mgo.Session dans un paramètre simultané est avantageuse. Les sessions gèrent automatiquement un pool de connexions, mais l'utilisation d'une seule session limite la capacité d'exploiter plusieurs connexions simultanément et potentiellement de les distribuer sur les nœuds du serveur si disponibles.

Créer de nouvelles sessions pour chaque demande, les copier si nécessaire et les fermer. les correctement (en utilisant Session.Close avec defer) permet une utilisation optimale des ressources. En gérant plusieurs connexions, le système peut potentiellement utiliser simultanément davantage de connexions et de nœuds de serveur, ce qui entraîne des temps de réponse plus rapides pour la base de données et les utilisateurs finaux.

Session.Close ne met pas fin à la connexion sous-jacente au serveur mais il le renvoie plutôt au pool, le rendant disponible pour que d'autres sessions puissent le récupérer.

Pour plus d'informations, reportez-vous à la discussion connexe sur les performances des sessions : mgo - les performances des requêtes semblent constamment lentes (500-650ms).

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!