BDD : Amélioration de la gestion des connexions

Ivan écrit: 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

Non justement sur mon vps ovh j'ai des temps beaucoup moins mauvais (<1s). C'ets en me connectant vers le pc de la structure que héberge mysql (sous windows)

Edit : Pour preciser mon propos je parle là uniquement du temps d'ouverture de la connexion. Pas de l'ouverture d'une fiche famille ou autre...

Ok. Tu arrives à combien de temps pour l'ouverture d'une fiche famille maintenant ?

Ivan

ODouville écrit: 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).

Oui je pensais à ca également je n'ai pas regardé si les bases exemples contenait beaucoup de données....

ODouville écrit: 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.

De ce que j'ai lu du code d'Ivan ce sont plutot beaucoup de petites requetes fréquentes je ne pense pas qu'il y aie de grosses requêtes consommatrices.
Pour ma part je suis juste l'informaticien bénévole de service donc je ne connais pas trop le côté fonctionnel de Noehtys mais y-t-il une fonctionnalité courante qui rame en distant et sur laquelle on pourrait se baser pour nos tests ?

Ivan peut-etre peux-tu mettre en place une branche spécifique sur le github noethys si nous sommes plusieurs à vouloir participer ? ou on utilise à fond les fonctionnalités github et on forke tous une branche de référence..... Il va falloir que je demande une formation à mon chef moi....

ODouville écrit: 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...

Je n'utilise pas assez Noeths pour m'apercevoir de cela mais ce n'est pas impossible si certaines connexions ne sont pas refermées... le serveur mysql doit se charger de plus en plus...

cdlt, marc

Je viens de mettre sur Github une mise à jour du fichier FonctionsPerso.py qui comporte la fonction CreerDonneesVirtuelles(). Il suffit de regarder tout en bas du fichier :

Il faut juste modifier le nombre de fiches familles à créer puis exécuter le fichier. Attention il faut environ 1 minute pour créer 100 fiches... Ce petit bout de code permet juste de créer des fiches familles, des fiches individuelles, une réservation. A modifier en fonction des besoins. Il est nécessaire d'utiliser le fichier EXEMPLE_ALSH fourni avec Noethys (vous le copiez avec un autre nom pour qu'il ne soit pas écrasé lors de la prochaine mise à jour).

Bon, j'ai codé ça rapidement ce soir. C'est pas top, mais ça permet de remplir artificiellement une base avec des fiches familles.

Ivan

Ivan écrit: Ok. Tu arrives à combien de temps pour l'ouverture d'une fiche famille maintenant ?

Ivan

Noethys 1.1.5.0 non modifé : 10s
Noethys 1.1.5.0 avec pool de connexion : 7s30

Suite à ton dernier message Marc :

Pour les fonctionnalités qui rament le plus en distant : Je dirais en priorité l'ouverture des fenêtres suivantes : fiche famille, grille des conso, gestionnaire des conso.

Pour l'utilisation de Github, moi je veux bien forker les branches quand vous voulez mais je ne sais pas du tout ce que cela veut dire car je ne pige presque rien à Github. En gros, je ne sais faire que des commit... :S

Pour la fatigue de Noethys à la fin de la journée, je ne suis pas sûr : j'utilise souvent Noethys 10 heures par jour à mon travail sans interruption avec beaucoup de données sans rencontrer de ralentissements à la fin de la journée. Mais c'est totalement subjectif.

Ivan

Bonsoir
Pour avoir testé puis abandonné vu la lenteur Noethys sur un NAS le plus long était l'ouverture â distance du gestionnaire des consommations (45secondes)

Ivan écrit: Suite à ton dernier message Marc :

Pour les fonctionnalités qui rament le plus en distant : Je dirais en priorité l'ouverture des fenêtres suivantes : fiche famille, grille des conso, gestionnaire des conso.

Ok on va donc commencer par la fiche famille... Avec un peu de chance les pistes que l'on pourrait trouver s'appliqueront à d'autre endroits.
Quand tu utilises noethys ton serveur mysql est sur ta machine ? sur le réseau local ou en distant ?
Moi quand je parle de distant c'est site distant mais mon épouse me signalait qu'a son boulot l'ouverture du gestionnaire de conso est lent alors que le mysql est sur le réseau local.. Pour que l'on parle de la m^me chose il serait bien que les participants a ce poste exposent leur config (local, reseau local, distant) et les temps qu'ils observent

Pour l'utilisation de Github, moi je veux bien forker les branches quand vous voulez mais je ne sais pas du tout ce que cela veut dire car je ne pige presque rien à Github. En gros, je ne sais faire que des commit... :S

Alors moi j'essaye de vivre avec mon temps et de m'y mettre mais c'est vrai que c'est chaud des fois et pourtant je baigne la dedans tous les jours...
Si un expert git / github passe par là il expliquera ça mieux que moi mais je vais tenter une explication ...

L'idée derriere github est de dire : tu as du code que tu veux partager et pour lesquelles tu aimerais bien des contributions externes. Pour cela tu publies ton code (ce que tu commites) dans ton dépot. C'est pour nous (éventuels contributeurs) le dépot de référence. Si nous voulons contribuer il y a 2 modes : le 1er qui se fait sur des contributeurs réguliers (=equipe projet) qui ont un acces direct en ecriture aux dépot. Ils peuvent faire des commits et toutes les opérations nécessaires sur le dépot de référence (gestion des branches, merge...)

Le 2eme mode est le "fork" : C'est une personne externe au projet qui voudrait participer, pour prendre un exemple simple : corriger une erreur dans un calcul.
Le mode opératoire est le suivant : la personne forke le depot de référence dans son propre compte github (exemple pour moi : https://github.com/mpasteur/Noethys si on regarde le haut de la page il est inscrit mpasteur/Noethys
forked from Noethys/Noethys). Elle se retrouve a ce moment là avec un instantané du projet au moment du fork. Elle fait ses modifications en local (ou sur le site si les modifs sont minimes) puis pousse (push) ses modifications vers github. Cela n'impacte que son fork. S'il est satisfait de sa modifcation il va alors te proposer une "pull-request" c'est à dire un patch qui contient les modifs qu'il te propose. Si cela te convient toi ou un des contributeurs du projet n'avez plus qu'a commiter cette pull-request dans le depot principal ou sur une branche spécifique si besoin.
C'est donc un mode qui convient parfaitement a de nombreux projets pour lesquels les contributeurs peuvent être multiples et ne contribuer qu'a une seule fonctionnalité...

J'espère avoir été à peu près clair...

Pour résumer ce que je te propose c'est de créer une branche (copie de ton depot de reference) "performances_bd" par exemple que nous allons prendre comme référence pour notre "fork" et dans lequel tu peux déjà ajouter par exemple le début de pool de connexion ou les logs que tu as pu ajouter

[strike]sinon je vous propose de continuer cette conversation dans le coin développeur sinon on va polluer le forum principal [/strike]
Edit : on y est déja

Marc

Temps plus précis :

Ouverture d'une fiche famille :

Pas de pool de connexions : 8.67s

	Temps total	Nombre
Connexions a la bd	5,11s	24
Requetes	0,51s	39

Avec Pool de connexions : 5.45s

	Temps total	Nombre
Connexions a la bd	0.29s	24
Requetes	0,51s	0.5

malheureusement je n'ai pas de base locale sous la main pour effectuer un test comparatif...

Ivan,

on sort du sujet perf bd mais on reste dans le sujet perf :
Sur la fiche famille je suis en ce moment à 5.3s. Sur ce temps là il y a 3.4s qui sont passées dans la méthode __do_layout qui construit la fenetre
(et principalement les lignes grid_sizer_base.Fit(self), self.Layout() et self.SetSize(taille_fenetre)) qui sont particulierement lentes. Cela te parle ?

parce que du coup le temps passé dans les requetes et les connexions (<1s) il est négligeable !