BDD : Amélioration de la gestion des connexions

bonjour,

je vais essayer d'etre clair dans mes exmplications mais n'hésitez pas à demander si ce n'est pas le cas.

Comme le dit Ivan dans un autre fil Noethys n'a pas été concu au départ dans l'optique d'une utilisation distante. Or comme c'est surement le cas pour vous si vous lisez ce message c'est un besoin de plus en plus fréquent.

Chez nous le serveur MySQL est sur le poste principal (celui de la directrice de la structure) avec Noethys
et les autres postes ont Noethys seul et se connectent en réseau ==> Aucun souci dans ce cas là
Mais les membres du bureau qui ne sont pas sur place ont aussi besoin de se connecter à distance ==> et là c'est ... lent, très lent....

En étudiant un peu plus en profondeur j'ai fait le même constat que dirka (http://www.noethys.com/index.php/forum-34/installation/3043-serveur-dedie?limitstart=0#10482) la gestion des connexion n'est pas optimisée dans le sens où chaque requete entraine une connexion à la base de données. Et chez nous c'est très long jusqu'a 15 secondes... J'ai donc tenté l'approche d'une connexion partagée : en terme technique un singleton c'est à dire un objet qui est unique dans l'application et donc créé uniquement la 1ere fois ou il est utilisé. Cette approche n'a pas fonctionné parce que Noethys utilise parfois plusieurs connexions simultanées.

Du coup je me suis tourné vers ce l'on utilise tout le temps en java dans nos applications : un pool de connexion

(Ceux qui savent de quoi je parle peuvent zapper cette partie)
=============================
En termes simples un pool de connexion est un tableau dans lequel on stocke ... des connexions.
En effet ce qui est couteux c'est l'établissement d'une connexion
Lorsque une partie du programme P1 a besoin d'une connexion à la base de données il en demande une au pool. Le pool regarde alors ce tableau et donne la 1ere connexion libre. une fois que P1 n'a plus besoin de la connexion il la rend au pool : Cette connexion n'est pas fermée mais marquée comme libre : elle peut donc être attribuée à une autre partie du programme. Si P1 est une tache longue et que pendant son temps d'execution P2 a besoin de la base de données alors le pool va lui attribuer une nouvelle connexion etc.....
=============================

Je ne connais pas trop l'environnement python mais je me suis tourné vers le connecteur officiel de mysql : https://dev.mysql.com/downloads/connector/python/

La syntaxe est très proche du mysqldb utilisé en standard dans Noethys ce qui fait que l'adaptation est plutot simple.

Et une fois quelques bugs corrigés (certaines parties du programme ne fermaient pas leurs connexions) les performances sont plutot honorables:
Ouverture du gestionnaire des consommations (37 connexions demandées)
Avant : 3mn06 !!! (Je l'ai dit que c'etait lent...)
Apres : 12 secondes

Ouverture d'une fiche famille (30 connexions demandées):
Avant : 3mn36
Apres : 24s

alors bien sur vous n'aurez pas forcement les mêmes temps de base puisque ces tests sont faits à une heure ou les FAI sont plutot chargés avec des demandes de téléchargement en tout genre mais le gain devrait être similaire.

Ce qu'il reste a faire
================
Mes modifs sont pour l'instant effectué sur une version 1.1.4.1 de Noethys il faut que je les applique sur la version courante
Effectuer plus de tests afin de valider qu'il n'y a pas de régression
Convaincre Ivan d'integrer mes modifications dans une future version

Bonsoir,

Je pense que tu pourras convaincre Ivan sans problème si ça ne remet pas en cause en profondeur d'autres aspects.
Mais effectivement tes temps d'origine étaient déjà énormes, pour moi c'est environ 3 x moins, déjà trop lent pour une utilisation régulière.

Je pense que tu feras des heureux

Claude

La branche est ici si vous voulez tester : https://github.com/mpasteur/Noethys/tree/connexion_statique

Bonsoir Claude,

oui je sais que les temps de départ sont très élevés chez nous.
Je pense que c'est du au fait que le serveur MySql n'est pas dédié c'est un poste déjà ancien mais tournant sous Windows10 et en plus je pense que les 2 FAI (le mien et celui de la structure) ne sont pas les meilleurs amis du monde et le flux mysql ne doit pas être des plus prioritaires....

Pour me donner une idée tu as un serveur mysql dédié a cette tache ?

cdlt,

Bonsoir,

Oui la base de données est installée sur un vieux portable de récup, donc pas une bête de course, sous linux.
Le portable est à la mairie, derrière une freebox.
Au secrétariat de la mairie, un PC sous windows, sur le même réseau donc peu de différence avec un fichier local.
Au périscolaire, un pc sous windows derrière une livebox.
Et moi pour mes bidouilles depuis chez moi derrière une freebox, PC ou portable sous linux, ou au boulot, PC sous linux mais réseau très performant.
Dans tous les cas, dès que l'on est plus sur le réseau local, c'est lent, même si ça l'est beaucoup moins que pour toi.

Claude

Bonsoir,

Waouh, les temps que tu évoques sont impressionnants !!! C'est drôlement enthousiasmant !

J'ai ajouté tes modifications dan le fichier GestionDB. Manuellement, car je souhaitais effectuer des adaptations pour pouvoir permuter facilement entre les interfaces MySQLDB et Mysql.Connector. De façon à faciliter les test comparatifs.

Bon, ça a fonctionné 10 secondes . Quand je ferme une fiche famille, j'ai à chaque fois l'erreur "Failed getting connection; pool exhausted". Tu n'as pas eu ça ? Tu sais comment corriger ?

Merci pour ta contribution !

Ivan

Je me réponds à moi-même :

J'avais oublié d'ajouter DB.Close() dans le fichier CTRL_Remplissage. Maintenant, ça fonctionne un peu mieux. Mais je ne sais toujours pas pourquoi. D'autant que l'erreur revient désormais lorsque j'ouvre une fiche famille 3 fois d'affilée. C'est mieux mais pas top.

Ivan

en fait il y a quelques endroits ou la connexion à la base de données n'est pas rendue donc il finit par saturer le pool de connexion.
C'est effectivement le cas dans CTRL_remplissage mais il y en a surement d'autres...
Si tu dis que tu as l'erreur en ouvrant plusieurs fois la fiche famille c'est qu'il manque un DB.Close la dedans...
Je regarde si on a la possibilité de voir ou ca coince...

ah si une petite astuce si tu veux juste faire quelques tests tu peux aussi modifier la ligne 115 du fichier GestionDB.py
Le parametre pool_size peut être augmenté un peu pour qu'il tienne un peu plus longtemps.

En général si tu veux determiner ou les connexions ne sont pas bien fermées il est bien de mettre ce parametre le plus petit possible comme cela les erreurs surviennent vite et tu peux focaliser tes recherches sur ce que tu viens de faire...

Ok.

J'ai codé un petit truc dans le fichier GestionDB pour qu'il affiche les requêtes dont la connexion n'a pas été fermée. Mais ça promet un bon paquet de tests avant de vérifier toutes les fonctionnalités.

Il y a autre chose qui m'ennuie : d'après ce que j'ai lu sur internet, l'interface myslq.connector est bien plus lente que mysqldb. Ce serait dommage que les connexions en réseau local soient moins rapides qu'avant. Du coup, pour l'instant, je garde la possibilité d'utiliser l'un ou l'autre et on verra plus tard, après les tests...

Ivan