BDD : Amélioration de la gestion des connexions
- goutatou
- Auteur du sujet
- Hors Ligne
- Membre elite
- Messages : 160
- Remerciements reçus 4
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...
Connexion ou Créer un compte pour participer à la conversation.
- goutatou
- Auteur du sujet
- Hors Ligne
- Membre elite
- Messages : 160
- Remerciements reçus 4
(Patch en .txt du fait des restrictions du forum)
Connexion ou Créer un compte pour participer à la conversation.
- Ivan
- Hors Ligne
- Administrateur
- Messages : 3793
- Remerciements reçus 522
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
Connexion ou Créer un compte pour participer à la conversation.
- goutatou
- Auteur du sujet
- Hors Ligne
- Membre elite
- Messages : 160
- Remerciements reçus 4
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
Connexion ou Créer un compte pour participer à la conversation.
- goutatou
- Auteur du sujet
- Hors Ligne
- Membre elite
- Messages : 160
- Remerciements reçus 4
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....
Connexion ou Créer un compte pour participer à la conversation.
- Ivan
- Hors Ligne
- Administrateur
- Messages : 3793
- Remerciements reçus 522
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
Connexion ou Créer un compte pour participer à la conversation.
- ODouville
- Hors Ligne
- Membre senior
- Messages : 49
- Remerciements reçus 0
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
Connexion ou Créer un compte pour participer à la conversation.
- Ivan
- Hors Ligne
- Administrateur
- Messages : 3793
- Remerciements reçus 522
Avec plaisir. Toute aide est la bienvenue car nombreux sont les utilisateurs qui attendent de pouvoir utiliser Noethys en réseau distant...
Ivan
Connexion ou Créer un compte pour participer à la conversation.
- Fred.th
- Hors Ligne
- Membre platinium
Je suivrai vos progrès avec gourmandise, courage, les gars
Fred.th, pour le Relais des Enfants à Montpellier
www.relaisdesenfants.org
Connexion ou Créer un compte pour participer à la conversation.
- ODouville
- Hors Ligne
- Membre senior
- Messages : 49
- Remerciements reçus 0
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...
Connexion ou Créer un compte pour participer à la conversation.