amélioration / optimisation temps d'affichage des données atlas

[Aurelien-Cheylan]

Bonjour, je travaille à la mise à jour des cartes en ligne sur le site de l’observatoire national des mammifères (ONM). Notre architecture est construite autour de 2 serveurs distants. Le premier avec uniquement le module atlas qui est alimenté via des Vms. Le second, un geonature plus complet (synthese / atlas / validation) accessible en interne, sur lequel je travaille principalement dans la table synthèse. J'ai un foreign data wrappers pour faire le lien entre les 2.

J’ai quelques questions au niveau de la création des VM de l’atlas. Si je simplifie la génération des pages espèces. Je crois comprendre que d’abord il y a la création de la vm_observations qui contient l’ensemble des données de la synthèse avec des filtres sur la validation de la donnée et peut être d’autres critères. Puis il y a la création d’une vm_maille qui intersectes les geom des obs avec les geom des mailles_10x10 et retourne les données sous forme de maille. Puis les différentes pages web sont générées en fonction du cd_ref dans l’atlas.

J’ai des temps d’affichage des cartes espèces / données assez long exemple : http://www.observatoire-mammiferes.fr/atlas/espece/60630 http://www.observatoire-mammiferes.fr/atlas/espece/60479

Est ce que vous avez des idées de méthodes d’optimisation des requêtes ?

D'autre part, j'ai des mailles qui s'affichent alors que je n'ai pas de données à cette date dans la synthèse, comme si dans la table mailles j'avais des données anciennes qui ont été invalidé mais toujours présentes d'une manière ou d'une autre.

Merci de votre aide, Bonne journée, Aurélien

[camillemonchicourt]

• En effet vm_observations récupère l'ensemble des observations, mais par défaut il n'y a pas de critères sur la validité des données ou autres : https://github.com/PnX-SI/GeoNature-atlas/blob/master/data/atlas/2.atlas.vm_observations.sql
• Si vous voulez filtrer les données remontées dans l'ATLAS (ne prendre que certains rangs taxonomiques, que certains jeux de données, que certains organismes, que les données validées...), vous pouvez justement ajouter des conditions WHERE dans vm_observations, c'est fait pour ça
• Ensuite il y a différentes VM qui sont créées pour calculer la liste des taxons, les classes d'altitude, la liste des communes... : https://github.com/PnX-SI/GeoNature-atlas/tree/master/data/atlas
• On créé ensuite une table des mailles présentes dans le territoire défini et selon la taille de maille choisi dans les paramètres du GeoNature-atlas - https://github.com/PnX-SI/GeoNature-atlas/blob/master/data/atlas/12.atlas.t_mailles_territoire.sql
• Et enfin on créé la VM vm_observations_mailles, intersectant les observations présentes dans vm_observations et t_mailles_territoire : https://github.com/PnX-SI/GeoNature-atlas/blob/master/data/atlas/13.atlas.vm_observations_mailles.sql

Les VM (vues matérialisées) ont justement l'intérêt de ne pas relancer les calculs à chaque fois à la volée, mais de stocker les infos à plat pour les récupérer rapidement.

Donc on ne calcule pas à la volée à chaque fois les nombres de données, les intersections par maille, etc...

Mais oui, les données à afficher sur la carte, peuvent être un longues à récupérer et c'est pour ça qu'on charge quand même la page web sans attendre d'avoir récupérer les données de la carte (pour ne pas pénaliser l'ouverture de la page) et qu'on charge les données de la carte en parallèle et qui peuvent donc s'afficher dans un second temps.

Et c'est vrai que les mailles sur la carte de http://www.observatoire-mammiferes.fr/atlas/espece/60630 sont un peu longues à s'afficher. Il faudrait creuser et analyser pourquoi.

Sur une espèce avec moins d'observations (http://www.observatoire-mammiferes.fr/atlas/espece/60243), c'est plus rapide :

La question principale qu'il faudrait vérifier c'est est-ce que cette différence de temps de chargement est lié au fait que le calcul côté serveur est beaucoup plus long si il y a plus de données, ou si c'est juste que le fichier à récupérer est plus lourd et donc plus long à télécharger quand il y a beaucoup d'observations...

[Aurelien-Cheylan]

Bonjour Camille merci pour ces précisions. J'utilise déjà le code sql de ces tables pour générées mes cartes (je vais tout de même regarder ce code plus en détail et voir s'il y a eu des optimisations par rapport à ma version du script sql). Où est ce que je peux chercher d'où peut venir ce temps d'affichage / calcul un peu plus long que prévu stp ? Au niveau des logs je suppose, mais ça se situe où dans l'arborescence du serveur ? Merci, Aurélien

[camillemonchicourt]

Les logs c'est plutôt pour identifier les erreurs et bugs. Là ce n'est ni une erreur ni un bug.

[lpofredc]

Ces problèmes de performances proviennent probablement de l'ancienneté de votre instance, beaucoup d'améliorations ont été apportées sur ce volet.

Dans votre instance, l'API renvoie un objet par observations! Donc en ce qui vous concerne, pour la loutre par exemple, 47k mailles (le json décompressé pèse près de 29Mo).

La version actuelle améliore le fonctionnement en faisant l'aggrégation des données à la maille et ajoutant des filtres temporels (cf. exemple sur Biodiv'Aura, une plus grosse instance: https://atlas.biodiversite-auvergne-rhone-alpes.fr/espece/60630 et l'API associée https://atlas.biodiversite-auvergne-rhone-alpes.fr/api/observationsMaille/60630).