Discussion :

[elias couppe]

Bonsoir à tous,

un correctif majeur a été livré sur le service d'altimétrie, ses performances s'en trouvent largement améliorées.

N'hésitez à nous confirmer (ou infirmer) cette évolution positive.

[tybern]

Bonjour,

N'hésitez à nous confirmer (ou infirmer) cette évolution positive.

Je suis au regret de dire qu'il y a toujours de gros problèmes...

Voici les performances sur une requête pour une dizaine de points uniques (une requête GET pour un point), et d'environ 2700 points, segmenté en requêtes POST de 500 points chacune.
C'est assez parlant.
Les GET d'un point, c'est correct (moins d'une seconde), les POST pour 500 points, ça va de 3,3s à plus de 21s de temps de réponse !

Pour moi, pas de progrès, désolé...



Voici le détail de la requête la plus longue :



J'ai fait un essai avec une seule requête de 2700 points pour le POST, temps de réponse = 32s.

J'ai essayé de faire des requêtes plus petites, mais même en segmentant à 100 points maximum, j'ai jusqu'à plus de 10s de délai.

Pardonnez moi, mais je n'arrive pas à comprendre comment un service qui fonctionnait bien peut se mettre à être défaillant à ce point... vous avez changé quoi à part l'hébergeur ?

Ou alors c'est moi, mais qu'est-ce que je fais de mal ?

Cordialement,

[elias couppe]

Bonjour,

Merci pour votre réponse.

Malheureusement il ne s'agit pas d'une simple migration, le service d'altimétrie a été redéveloppé par un prestataire.

Nous avons constaté de nettes améliorations, notamment sur les profils altimétriques en GET. Je transmets vos retours pour investigation, notamment sur le POST qui semple être la méthode qui pose encore de gros problèmes.

Je reviens vers vous dès que possible.

[tybern]

Rebonjour,

Je viens de vérifier, en fait, je me suis trompé : toutes mes requêtes sont en POST, même pour un seul point.

C'était avec le précédent service que je faisais différemment.
Mais quand j'ai recodé pour la bascule, j'ai tout fait en POST pour me simplifier la vie.

Donc, la différence entre les requêtes du test ci-dessus, c'est le nombre de points.

Cordialement,

[tybern]

Re-re-bonjour,

Je viens de faire un autre test : j'ai recodé en GET, avec une requête de 200 points (pour ne pas dépasser la limite d'une requête GET).

Voici un résultat (c'est variable d'un essai à l'autre, mais toujours similaire) :



En conséquence, par rapport à la même requête en POST pour 200 points, je ne vois pas de différence majeure.
A noter qu'on a une requête à plus de 14s pour un seul point !.

Ma conclusion, c'est qu'au premier ordre, que ce soit en GET ou en POST, ça ne change pas grand chose.
C'est la longueur de la requête (le nombre de points) qui semble faire le délai (mais avec parfois un gros délai même pour un seul point...).

Il faut donc chercher ailleurs le problème que sur le protocole qui ne doit pas être en cause.

Cordialement,

[tybern]

PS du message précédent : je viens de tester avec des requêtes (aussi bien GET que POST) de 50 et 100 points pour le même ensemble (toutes sont envoyées en même temps) : les temps de réponses tournent en gros entre 1s et 3s, et surtout, le délai global est plus court !

Il me semble clair que le problème vient du nombre de points à traiter en une seule requête.

A vous de voir...

Si vous souhaitez que je fasse des essais "en temps réel" avec vous pour pouvoir mesurer de votre coté, faites le moi savoir.

Cordialement,

[elias couppe]

Merci pour vos retours détaillés,

j'ai de nouveau transmis vos résultats de test aux personnes en charge de l'analyse et de la recette du service, qui sont effectivement cohérents avec leurs observations.

Je reviens vers vous en cas de question complémentaire, et quand le problème sera résolu (espérons le)

[tybern]

Bonjour,

Je reviens une fois de plus, au désespoir...

La situation ne s'améliore toujours pas.
Voici ce matin, deux résultats de requêtes concernant environ 7000 points, segmentées par 500.

Première tentative :

On y voit la requête la plus longue qui attend 1,1 minutes !
Et aussi et surtout l'une d'elle qui échoue : la raison (pas sur cet écran) et HTTP 502, c'est à dire BAD GATEWAY !!! Etrange non... ?

Deuxième tentative :

Tout passe, mais une grosse partie des requêtes à plus de 20 sec ou 30 sec. La plus longue à 57 secondes.

Faites quelque chose...

S'il vous plait...

Cordialement

PS : si votre prestataire est incompétent, changez-en, je ne vois pas d'autre solution moi.

[elias couppe]

Bonjour,

nous vous présentons nos excuses pour ces problèmes qui durent et qui comme vous l'avez compris, ne sont pas complètement de notre ressort...

Je viens cependant avec de potentielles bonnes nouvelles : une fuite mémoire a été identifiée, le service devrait très prochainement être redéployé en production.
D'après nos premiers tests, on serait autour de 2 ou 3 secondes pour 200 points, et entre 7 et 10 secondes aux cas limites (5000 points en POST), et ce de manière régulière.

Je reviens vers vous dès que le correctif est poussé en production.

Bon week-end

[elias couppe]

Bonsoir,

le correctif a été poussé en production et permet, si l'on voit le verre à moitié plein, de régulariser les temps de réponses à de bien meilleures valeurs que celles expérimentées ces dernières semaines.

Si l'on voit le verre à moitié vide, aux cas limites (5000 points POST par exemple), on est sur du x3 / x5 par rapport à l'ancien service qui tournait sur le Géoportail. Malheureusement, le contrôle des requêtes émises vers la Géoplateforme par sa couche de sécurité implique du temps de réponse supplémentaire incompressible.

A court terme, si le correctif permet de bien valider la régularité du service, on aura malheureusement pas mieux.

[tybern]

Bonjour,

Je viens à l'instant de faire quelques essais suite à votre message :

Verre à moitié plein :

Pour 4000 points :
- si en une seule requête, un peu plus de 3 sec de délai ;
- si en deux requêtes de 2000 points : environ 2 sec de délai (et individuel, et total) ;
- si en requêtes de 500 points : moins d'une seconde (voire un poil plus) de délai (individuel et global).
Je ne détaille pas tout, mais descendre en dessous de 500 points par requête ne change plus grand chose, entre 500 et 4000, c'est environ linéaire.

Je vais donc m'en tenir raisonnablement à des requêtes de 500 points maximum.

A moitié vide ... :

Une dégradation d'un facteur 3x à 5x par rapport à l'ancien service, je préfère laisser la parole aux autres usagers s'il y en a qui nous lisent (j'ai un peu l'impression d'être seul ici sur ce sujet...).
En 2024, c'est bien entendu et forcément un état de fait difficile à comprendre sur le principe dans le cadre d'une opération de modernisation.
Je ne sais pas quel était votre cahier des charges vis à vis de votre prestataire, mais est-ce conforme aux attentes ?

Je discutais tout à l'heure avec un collègue d'un projet de migration d'une application ESRI utilisant des bases offline (chères...) vers les services en ligne de la Géoplateforme.
Les contre-performances de ce type de la Géoplateforme seront forcément un critère de décision sur un projet complexe de plusieurs années.

Tous ceux qui font de la maintenance de parcs savent que quand les applications ont des temps de réponses qui dépassent la seconde, le taux de panne des claviers et souris monte de façon exponentielle... les utilisateurs s'énervent vite...

Cordialement et merci pour votre écoute,