Va-t-il ralentir ma base ?
En une phrase
Recommandé : il travaille sur une copie, et votre base de production n'est pas sollicitée. Sinon, le gros calcul se fait à chaque mise à jour, la nuit, et le jour le site lit seulement ce qu'il a préparé.
MontrerLe jour, l'applicationLe schémaVotre base en trois couleurs
Comment ça marche
Le mode recommandé. L’observatoire travaille sur une copie de votre synthèse, ou sur une base dédiée. Votre base de production n’est alors ni lue ni chargée. Le branchement direct sur une base de production est possible, validé lors de la première installation par un tiers.
Deux moments. À chaque mise à jour, au rythme convenu avec vous, la nuit, la fabrication lit les observations, prépare ce qui peut être montré, puis recalcule les vues. Le jour, l’application ne touche pas aux tables d’observations de GeoNature : elle lit ce qui a été préparé et ses réglages. Ces tables préparées vivent pourtant dans la même base, donc sur le même serveur PostgreSQL.
Le jour, peu de connexions. Chaque processus du site garde un petit nombre fixe de connexions, volontairement bas. Une requête trop longue est coupée, et une demande qui attend trop échoue proprement au lieu de bloquer la page. Les cartes de points et la liste des observations d’une fiche interrogent la base à chaque visite.
Le cache. Les statistiques restent 24 heures dans le navigateur, et sur un éventuel réseau de diffusion de contenu. Un observatoire fermé par mot de passe ne garde rien en cache partagé.
Pendant le recalcul. Une seule session à la fois, qui attend son tour. Les nouvelles vues se construisent à côté des anciennes : les visiteurs voient les anciennes pendant tout le calcul, et l’espace disque des vues double le temps du calcul. L’échange final est bref, ou abandonne sans rien casser.
Combien de temps. Une douzaine de minutes sur un à deux millions d’observations, environ quatre heures sur plus de cinq millions (mesures de septembre et d’octobre 2026).
Un préchauffage, si vous le choisissez, ouvre des fiches à intervalle régulier pour éviter des premières visites lentes : c’est une charge de jour.
Pour votre informaticien
- Pool
pgà plafond fixe par processus (constantePOOL_MAX, pas de variable d’environnement), délai de requête côté base et côté application,jit=offsur chaque connexion et dans les scripts de fabrication. - Recalcul : vues
_newpuis renommage en une transaction, sous verrou consultatif, sans limite de durée de requête. À lancer détaché du terminal, avec l’espace disque de deux jeux de vues. - À relever sur votre serveur :
SHOW max_connectionsetSELECT count(*) FROM pg_stat_activity. La durée réelle des derniers recalculs est écrite dans le journal des bascules, dans le schéma de l’observatoire. - Docs à paraître.
Ce que l’observatoire ne fait pas (encore)
- Le plafond de connexions ne se règle pas sans toucher au code.
- Aucune mesure de durée n’est encore liée à une description du serveur qui l’a faite.
- Un cas reste très lent, non résolu : la préparation de beaucoup d’observations floutées avec le référentiel national de sensibilité.
- La mise à jour n’est pas encore programmée d’office.
La suite : À quand datent les chiffres affichés ?
Vérifié le 29 octobre 2026.