BDD : Amélioration de la gestion des connexions

bon je me répond à moi même .. il faut creuser cette piste là (en tout cas pour la fiche famille) puisque les methodes de layout citées ci-dessus demande la MAJ des composants graphiques.
Mais lors du draw de ces composants graphiques on réeffectue des requêtes en base.
En déplaçant la recherche des valeurs dans l'init de chaque composant l'ouverture d'une fiche famille passe à 3s...
Cela demande toutefois quelques adaptations du code mais si les temps s'améliorent le jeu peut en valoir la chandelle.

je coupe pour la nuit le reveil va être délicat demain matin :pinch:

Bonsoir,

Je n'ai pas la possibilité de travailler dessus aujourd'hui ni demain car la rentrée est très chargée, mais j'essaye d'étudier ces pistes dans les jours à venir.

Merci pour ta contribution,

Ivan

Ivan écrit: C'est pas top, mais ça permet de remplir artificiellement une base avec des fiches familles.

C'est déjà très bien !
Il faut juste que j'arrive à me mettre au python que je ne connais pas du tout... A priori c'est pas pour tout de suite, vu la tournure que prend la rentrée...

goutatou écrit: 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 !

Très intéressants tes résultats goutatou !
Dans quelles conditions as-tu mesuré tous ces temps ? fichier local ou réseau ? si réseau, réseau local ou distant ?

ODouville écrit:
Très intéressants tes résultats goutatou !
Dans quelles conditions as-tu mesuré tous ces temps ? fichier local ou réseau ? si réseau, réseau local ou distant ?

Bonsoir,

pour ma part c'est réseau distant. J'ai 2 serveurs distincts : celui de la structure et mon serveur privé virtuel chez OVH sur lequel je fais le plus mes tests. Celui de la structure me sert plus a valider que cela fonctionne encore et à comparer les résultats. Comme je le disais au début du fil j'avais auparavant de gros problèmes de performances vers le serveur du centre (mais qui sont résolus depuis).

Marc

PS: C'est vrai que je ne signe pas à tous les coups alors moi c'est marc

grid_sizer_base.Fit(self), self.Layout() et self.SetSize(taille_fenetre) qui sont particulierement lentes

Je vais peut-être dire des bêtises hein... ne m'en voulez pas ! J'ai commencé le python, il y a environ 30min :laugh:

Je me demande pourquoi on voit avant le redimensionnement de la fenêtre ?
J'imagine que le redimensionnement de la fenêtre provoque un redimensionnement des composants internes (surtout si on a demandé au sizer de se "fitter" à la fenêtre).
Le n'est-il pas redimensionné au moins 2 fois dans ce cas ? De même pour le Layout(), ne gagnerait-il pas à être effectué seulement après le changement de taille de la fenêtre ? Voire à être supprimé dans le cas où un SetSize() sur la fenêtre provoquerait lui-même un Layout() ?

Bonjour

Merci pour ces retours. J ai pas mal avancé de mon coté egalement en partant de vos pistes. Malheureusement, je n ai plus de connexion internet depuis hier et ce jusqu a lundi. Donc la poisse... je posterai lundi mes travaux. Parce que taper sur le telephone, c est vraiment la plaie.

A lundi

Ivan

Bonjour ODouville,

ODouville écrit:

grid_sizer_base.Fit(self), self.Layout() et self.SetSize(taille_fenetre) qui sont particulierement lentes

Je vais peut-être dire des bêtises hein... ne m'en voulez pas ! J'ai commencé le python, il y a environ 30min :laugh:

Je me demande pourquoi on voit

Code:

grid_sizer_base.Fit(self)

avant le redimensionnement de la fenêtre ?
J'imagine que le redimensionnement de la fenêtre provoque un redimensionnement des composants internes (surtout si on a demandé au sizer de se "fitter" à la fenêtre).
Le

Code:

grid_sizer_base

n'est-il pas redimensionné au moins 2 fois dans ce cas ? De même pour le Layout(), ne gagnerait-il pas à être effectué seulement après le changement de taille de la fenêtre ? Voire à être supprimé dans le cas où un SetSize() sur la fenêtre provoquerait lui-même un Layout() ?

pour ma part ce n'est pas ca qui me semble couteux (puisque cela est fait de la m^me manière en local) mais plutot que ces méthodes appellent toutes la méthode redraw qui appelle elle m^me la méthode MAJ() qui fait beaucoup de requetes en base. Du coup dans le cas d'un accès distant on multiplie encore les temps. Si les requetes de selection de données sont replacées sur l'init du composant alors on gagne beaucoup de temps.

cdlt,

Salut Marc,

effectivement, si le chargement des données a lieu également lors d'un simple rafraîchissement visuel, ça explique des choses...

par contre, dans les temps que tu avais observés :

goutatou écrit: Ouverture d'une fiche famille :

[...]

Avec Pool de connexions : 5.45s

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

Ca donnait l'impression que sur l'ouverture de la fiche il n'y avait que 0.51 + 0.29 = 0.8s de passé dans "ouverture connexion + requêtes" sur les 5.4s de temps global d'ouverture.
C'est pour ça que je me suis dit que le layout était peut être en cause (j'ai déjà vu ça quelques fois, un layout hyper lourd à gérer qui plombait la réactivité d'une appli).
Sais-tu à quoi sont liées les 4.6s de dfiférence ?

Olivier

Bonjour,

Bon finalement, Orange m'a prêté hier soir une clé 3G pour conserver un accès internet. Ca rame un peu, mais j'arriverai peut-être à mettre ce soir mes travaux sur Github. Il me reste encore quelques choses à stabiliser dans les dernières modifications...

Pour le Layout de la fiche famille, il y avait en effet un souci : le redimensionnement imposait en effet une requête importante et inutile. Mais c'est maintenant corrigé.

Je ne peux pas comparer avec avant puisque ma connexion 3G est plus lente que la connexion habituelle mais je pense avoir quand même gagné pas mal de temps sur les ouvertures des fiches familles, individuelles, grille des conso et gestionnaire des conso. A tester...

Ivan

ODouville écrit: Ca donnait l'impression que sur l'ouverture de la fiche il n'y avait que 0.51 + 0.29 = 0.8s de passé dans "ouverture connexion + requêtes" sur les 5.4s de temps global d'ouverture.
C'est pour ça que je me suis dit que le layout était peut être en cause (j'ai déjà vu ça quelques fois, un layout hyper lourd à gérer qui plombait la réactivité d'une appli).
Sais-tu à quoi sont liées les 4.6s de dfiférence ?

En fait je traçais les requêtes de l'init et non celles passées après (je pensais que tout etait fait a ce moment là) mais comme le dit Ivan on passe plus de temps après.

Ivan écrit: Je ne peux pas comparer avec avant puisque ma connexion 3G est plus lente que la connexion habituelle mais je pense avoir quand même gagné pas mal de temps sur les ouvertures des fiches familles, individuelles, grille des conso et gestionnaire des conso. A tester...

c'est une très bonne nouvelle ce que tu nous annonce là !