Question de mise en commun des connexions Mysql: cela en vaut-il la peine?

Question

Je me souviens avoir entendu dire que le processus de connexion dans mysql avait été conçu pour être très rapide par rapport aux autres SGBDR, et que, par conséquent, l'utilisation de a La bibliothèque qui fournit le regroupement de connexions (SQLAlchemy) ne vous aidera pas beaucoup si vous activez le pool de connexions.

Quelqu'un at-il une expérience avec cela?

Je suis réticent à l'activer en raison de la possibilité que, si un code génère quelque chose de dynamique dans une connexion à une base de données et ne nettoie pas (par erreur) après lui-même, cet état devrait normalement être nettoyé à la fermeture de la connexion. sera plutôt propagé au code suivant qui obtient une connexion recyclée.

Answer 1

Il n'est pas nécessaire de s'inquiéter de l'état résiduel d'une connexion lors de l'utilisation du pool de connexions de SQLA, à moins que votre application ne modifie les options de la connexion, telles que les niveaux d'isolation de transaction (ce qui n'est généralement pas le cas). Le pool de connexions de SQLA émet un message connection.rollback () sur la connexion lors de sa réintégration, de sorte que tout état transactionnel ou verrou est supprimé.

Il est possible que le temps de connexion de MySQL soit assez rapide, en particulier si vous vous connectez via des sockets Unix sur le même ordinateur. Si vous utilisez un pool de connexions, vous souhaitez également vous assurer que les connexions sont recyclées après un certain temps, car la bibliothèque cliente de MySQL arrêtera automatiquement les connexions inactives pendant plus de 8 heures (dans SQLAlchemy, il s'agit de l'option pool_recycle).

Vous pouvez rapidement analyser le pool de connexions plutôt que non avec une application SQLA en modifiant l'implémentation du pool par défaut de QueuePool en NullPool, qui est une implémentation de pool qui ne regroupe en réalité rien - elle se connecte et se déconnecte réel lorsque la connexion par proxy est acquise et ensuite fermée.

Answer 2

Même si la partie connexion de MySQL elle-même est assez lisse, il y a probablement encore une connexion réseau impliquée (que ce soit en boucle ou physique). Si vous faites un lot de demandes, cela pourrait coûter très cher. Cela dépendra (comme c'est souvent le cas) de ce que votre application fait exactement, bien sûr. Si vous faites beaucoup de travail par connexion, cela dominera et vous ne gagnerez pas beaucoup.

En cas de doute, testez les points de repère - mais je suis convaincu que la bibliothèque de pooling de connexions (du moins une bibliothèque réputée) fonctionnera correctement et réinitialisera les éléments de manière appropriée.

Answer 3

Réponse courte: vous devez le comparer.

Réponse longue: ça dépend. MySQL est rapide pour la configuration de la connexion, éviter les coûts n’est donc pas une bonne raison de choisir le pooling. Si vous lancez des requêtes peu nombreuses et rapides, vous gagnerez où vous gagnerez, car vous obtiendrez une victoire grâce à la mise en commun.

L'autre souci est de savoir comment l'application traite le thread SQL. S'il ne fait aucune transaction SQL et n'émet aucune hypothèse sur l'état du thread, le pooling ne posera pas de problème. OTOH, le code qui repose sur la fermeture du thread pour ignorer les tables temporaires ou pour annuler des transactions rencontrera de nombreux problèmes avec le pooling.

Answer 4

Le pool de connexions accélère les choses en évitant de créer un objet java.sql.Connection chaque fois que vous effectuez une requête dans une base de données. J'utilise le pool de connexions Tomcat à une base de données mysql pour les applications Web qui effectuent beaucoup de requêtes. Pendant la charge utilisateur élevée, il y a une amélioration notable de la vitesse.

Answer 5

J'ai créé un service RESTful simple avec Django et je l'ai testé avec et sans pool de connexions. Dans mon cas, la différence était assez notable.

Dans un réseau local sans réseau, le temps de réponse était compris entre 1 et 5 secondes. Avec cela, moins de 20 ms. Les résultats peuvent varier, mais la configuration que j'utilise pour MySQL & amp; Les serveurs Apache sont plutôt bas de gamme.

Si vous servez des pages d'interface utilisateur sur Internet, le temps supplémentaire risque de ne pas être perceptible par l'utilisateur, mais dans mon cas, il était inacceptable. J'ai donc opté pour l'utilisation de la piscine. J'espère que cela vous aide.