BDD : Amélioration de la gestion des connexions

ah ca c'est parfait ! ton code m'interesse parce que moi je loggue quand j'ouvre et j'essaye de voir si j'ai pris une nouvelle connexion. Si oui c'est que la dernière fois j'ai mal fermé...
Si tu arrives a logguer les requetes avec connexions non fermées on peut surtout si nous sommes plusieurs interessés faire tourner le logiciel et au fur et à mesure ces quelques cas devraient disparaitre.
Pour les temps de connexion il faut effectivement faire des tests et peut être proposé un pool dans une option de configuration avancée. Si tu preferes cette méthode là je pourrai peut etre degager un peu de temps pour la coder...

en piece jointe un patch sur 2 DB.Close() manquants lors de l'ouverture de la fiche famille.
(Patch en .txt du fait des restrictions du forum)

Ok. Je t'enverrai bientôt mon fichier GestionDB modifié. J'ai quelques tests à faire encore.

Par contre, je viens d'acheter ce matin un serveur dédié KIMSUFI pour effectuer des tests. Et là surprise, j'ai des temps d’exécution vraiment pas mauvais : 6 secondes pour ouvrir une fiche famille. Idem pour ouvrir le gestionnaire des conso. C'est "presque" fonctionnel.

Et là 2ème surprise : c'est plus lent si j'utilise mysql.connector (7 secondes au lieu de 6). Bizarre, non ?

Ivan

Ivan écrit: Par contre, je viens d'acheter ce matin un serveur dédié KIMSUFI pour effectuer des tests. Et là surprise, j'ai des temps d’exécution vraiment pas mauvais : 6 secondes pour ouvrir une fiche famille. Idem pour ouvrir le gestionnaire des conso. C'est "presque" fonctionnel.

J'ai vu la même chose hier soir sur mon serveur chez ovh également (mais plutot 8 s que 6 s) c'est pour cela que je n'ai pas encore compris pourquoi les temps lorsque je me connecte à distance à la structure sont si longs ... (0.5s vs 15s ...)

pour la difference entre les 2 libraires d'accces à la bd je ne saurai expliquer ces différences

bon une info si cela peut aider quelqu'un.
J'avais des temps très long lors de l'ouverture d'une connexion à la base de données en accès a distance.

J'ai pu corriger cela en positionnant le parametre "skip-name-resolve" dans ma configuration Mysql.
Le probleme tenait au fait que MySql essayait de resoudre le nom d'hote lié a mon adresse IP et qu'il n'y arrivait pas ...

Je passe de 15s à moins d'1 s....

Quelle efficacité !

Maintenant que t'en parles, j'ai déjà lu ça quelque part mais je n'avais jamais essayé. Tu as obtenu ces chiffres (15s > 1s) en faisant tes tests sur quel type de serveur ? Ton serveur OVH ?

Ivan

Bonsoir,

Je pense que le skip-name-resolve peut améliorer la vitesse d'établissement des connexions, mais en toute logique ça ne devrait pas aller plus loin... Donc si un pool est mis en place (ce qui serait une très bonne chose comme il a été dit), le gain se fera uniquement sur les premières actions dans l'appli (le temps d'établir toutes les connexions du pool).

A titre professionnel j'ai pas mal travaillé sur des applications critiques, et notamment sur des problématiques de performances.
Par expérience, les problèmes de performances d'une application sont très souvent liées à l'accès aux données.

Pour ma part, j'ai surtout constaté des lenteurs sur l'affichage des "gros" tableaux (effectifs de la page d'accueil, gestionnaire de consommations, calendrier de la famille, etc...). Pour info, j'ai 2 activités qui génèrent en tout 16 consommations différentes, le tout sur un calendrier d'une année scolaire (10 mois).

Et, même si je n'ai hélas pas beaucoup pratiqué MySql (plutôt SQLServer/Sybase), je pense que les problèmes de lenteurs dans l'application (du moins ceux que j'ai rencontrés) sont probablement dus aux requêtes qui remontent les données de la base. Je suis prêt à aider

Olivier

Bonjour,

Avec plaisir. Toute aide est la bienvenue car nombreux sont les utilisateurs qui attendent de pouvoir utiliser Noethys en réseau distant...

Ivan

...et ceux qui l'ont déjà installé en réseau distant et font le dos rond quand les utilisateurs râlent... :whistle:

Je suivrai vos progrès avec gourmandise, courage, les gars :woohoo:

Existe-t-il une base "type" ? Une sorte de base de démo, mais avec des volumétries importantes, sur lesquelles on pourraient effectuer des tests ?
On ne s'en servirait que pour des tests de performances, de manière à toujours effectuer les mêmes tests sur les mêmes données (histoire de voir si on progresse ou pas).

Et pour la partie python, hélas, je ne connais ce langage que de nom. J'ai cru comprendre que ce n'était pas trop difficile à apprendre, mais je crains de ne pas avoir suffisamment de temps pour un apprentissage... Si certains d'entre vous se sentent de mettre quelques petits chronos dans le code pour mesurer les temps passés sur certaines requêtes, qu'ils n'hésitent pas
Plus sérieusement, je peux me pencher sur quelques requêtes SQL et tenter de les améliorer, en les faisant tourner sur une base test. Il faudrait identifier les requêtes qui pénalisent le plus.

J'ai l'impression également, quelques fois, de percevoir une légère fatigue des temps de réponse de l'appli dans le temps. Je veux dire que lorsque je l'appli démarre tout semble répondre correctement, et ça n'est plus forcément aussi fluide au bout de 30mn ou 1h d'utilisation. Je suis le seul dans ce cas ? C'est peut-être mes yeux qui me jouent des tours...