You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Sur un serveur hébergeant un sous-module POP-Amphibien, le chargement de ce module est long (une dizaine de secondes) En analysant ce qui se passe dans la console, on voit que la page d'accueil du sous-module POP-Amphibien fait une requête par aire à charger dans la liste des aires disponibles. Soit plus de 100 appels à l'API. Ne serait-il pas préférable/possible, de faire 1 seul appel renvoyant toutes les aires ?
Ce serveur est affecté par des crash de postgres récurrents. Possiblement en lien avec ces appels multiples.
Je me demande si ce comportement génére une connexion par appel. Ce qui pourrait potentiellement saturer le nombre de connexion postgres en lien avec le max_connexions du postgresql.confsi elles ne sont pas fermée.
Ces crashs de postgres sont une enigme. @DonovanMaillard me dit qu'il a des soucis de crash postgres lui aussi sur un serveur sans module monitoring et plutôt en lien avec la synchro mobile : PnX-SI/gn_mobile_occtax#221
The text was updated successfully, but these errors were encountered:
J'ai a priori identifié ces soucis de crash postgres qui serait plutôt en lien avec l'absence d'espace de swap sur les VPS OVH.
Voir à la fin de ce ticket : PnX-SI/GeoNature#2613
Par contre les multiples appels pour remonter les aires génèrent toujours un très long temps d'attente pour le chargement du contenu du module.
Version
GN 2.11.2
Monitoring 0.4.1dev0
Sur un serveur hébergeant un sous-module POP-Amphibien, le chargement de ce module est long (une dizaine de secondes) En analysant ce qui se passe dans la console, on voit que la page d'accueil du sous-module POP-Amphibien fait une requête par aire à charger dans la liste des aires disponibles. Soit plus de 100 appels à l'API. Ne serait-il pas préférable/possible, de faire 1 seul appel renvoyant toutes les aires ?
Ce serveur est affecté par des crash de postgres récurrents. Possiblement en lien avec ces appels multiples.
Je me demande si ce comportement génére une connexion par appel. Ce qui pourrait potentiellement saturer le nombre de connexion postgres en lien avec le
max_connexions
dupostgresql.conf
si elles ne sont pas fermée.Ces crashs de postgres sont une enigme. @DonovanMaillard me dit qu'il a des soucis de crash postgres lui aussi sur un serveur sans module monitoring et plutôt en lien avec la synchro mobile : PnX-SI/gn_mobile_occtax#221
The text was updated successfully, but these errors were encountered: