Améliorer le temps de chargement des données

[joelclems]

Le temps de chargement peut être long pour un nombre relativement réduit de données.
Voir quelle sont les possibilités d'amélioration:

• : travail sur le chargement des géométries
  • : récupérer la géométrie au format json directement depuis le sql ou depuis la requête sqlachemy

[jbdesbas]

Pour une vingtaine de sites, le geojson met près de 3 secondes à être généré par le serveur. Je n'ai pas de requêtes de plus de 1 sec loguée, donc c'est bien côté python que ça bouchonne.
J'ai environ 2000 sites ponctuels à intégrer, mais à partir de 100 je commence à avoir des timeout.

Edit : je constate tout de même que sur le serveur de demo, le délai pour généré le geojson des 17 sites STOM n'est que de 120ms. Peut-être un truc a voir de mon côté

[joelclems]

ça reste un des gros points noirs du module, je pense qu'il y a quelque chose à jouer dans la serialisation ou dans le module utils_flask_sqla_geo
je regarde ça demain en détail
c'est des points ou des polygones?

[jbdesbas]

Salut,
Il s'agit bien de points. Après quelques tests, ca semble bien être la sérialisation qui coince. Je suis toujours intrigué par la différence entre mon serveur et le serveur de demo. Le matériel n'est peut-être pas le même, mais ça fait une sacrée différence.

Si ca peut t'aider, voici ce que j'ai relevé de mon côté :
sérialisation d'un site : 0,08 sec (temps entre le début et la fin de fonction serialize() )
Dont environ 50% (0.04 sec) du temps sur la récupération des valeurs d'attributs. (pas encore de notion de géometrie il me semble)

gn_module_monitoring/backend/monitoring/serializer.py

Lines 108 to 112 in a554622

	for field_name in self.properties_names():
	val = getattr(self._model, field_name)
	if isinstance(val, (datetime.date, uuid.UUID)):
	val = str(val)
	properties[field_name] = val

En remplaçant val = getattr(self._model, field_name) par val = self._model.__dict__.get(field_name) je gagne 50% sur cette boucle (qui passe donc a 0.02sec), mais ca reste trop long pour être utilisable (et c'est peut-être pas sans conséquence, cf : https://stackoverflow.com/questions/9790991/why-is-getattr-so-much-slower-than-self-dict-get )

[joelclems]

En mettant le nez dans les requêtes, j'ai pu décéler pas mal de problèmes

• le fait de passer une partie le config en base dans t_module_complements et de verifier la date de modification de cette table engendrait une requete à chaque appel de la config du module en backend

  • c'est résolu verifiant la config seulement une fois par api, au début de l'appel

• il restait pas mal de sous-requetes, cela à pu être résolu en:

  • mettant au maximum de lazy='joined' (pour les realtions comme observers, datasets, medias, ...) (sauf pour les relation enfants comme sites visites observations, ...
  • les colonnes hybride générait aussi des sous requetes (last_visit, nb_visits, nb_observation)
    • elles sont remplacées par des column_property https://docs.sqlalchemy.org/en/13/orm/mapped_sql_expr.html

gn_module_monitoring/backend/monitoring/models.py

Lines 209 to 217 in 17910b3

	last_visit = column_property(
	select([func.min(TBaseVisits.visit_date_min)]).\
	where(TBaseVisits.id_base_site==id_base_site)
	)
	nb_visits = column_property(
	select([func.count(TBaseVisits.id_base_site)]).\
	where(TBaseVisits.id_base_site==id_base_site)
	)

• Les column_property sont accessible avec as_dict de la classe serializable, les propriétés hybrides non.

• avec column_property on peut directement récupérer la geométrie au format geojson depuis la base ce qui pourrait accélérer les requetes

gn_module_monitoring/backend/monitoring/models.py

Lines 219 to 223 in 17910b3

	geom_geojson = column_property(
	select([func.st_asgeojson(TBaseSites.geom)]).\
	where(TBaseSites.id_base_site==id_base_site).\
	correlate_except(TBaseSites)
	)

@jbdesbas est ce que ces modifications te permettent de faire les requetes sur ton serveur?

je n'ai pas changé getattr en self._model.__dict__.get parce que j'ai des relationships dans la liste (medias observers datasets, ...) mais normalement cette partie du code ne génère plus de sous-requetes

de mon coté ça me fait des reponse de 1Mo pour 2000 sites, il y a peut être des pistes pour gagner au niveau de la taille des données

[camillemonchicourt]

Super bravo pour ces optimisations !

[jbdesbas]

Salut @joelclems
Ca fait une sacré différence avec le dernier commit 17910b3 : pour les 20 sites, la requête abouti en 300ms 🚀 (contre 2~3 sec 🐢 avant), bien joué !
(Pour appliquer le commit, j'ai dû rajouter une colonne id_sites_group dans la base)

La taille des réponses peuvent être considérablement réduites (80~90%) en ajoutant une compression des fichiers json dans apache (cf PnX-SI/GeoNature#560 (comment) )

Je test avec les 2000 sites et je te fais un retour.

Petite curiosité, la route permettant de charger la liste des sites est appelé 2 fois par le frontend :

[joelclems]

C'est qu'on appelle le module en tant qu'objet pour les detail et les listes
et on l'appelle pour les sites pour la carte (si par exemple on arrive directement sur une page d'un site d'une visite etc..)
il y a clairement des amélioration à faire de ce côté là

[joelclems]

il y a aussi une modification du front à prendre en compte dans le dernier commit

[jbdesbas]

800 ms pour les 2000 sites 👌
Merci encore pour ton travail et ta réactivité !