Discussion :

[saxrub]

Bonjour

J'utilise un web service dédié à mon environnement web pour procéder à des géoréférencements inverses.

Depuis ce week-end, il faut dix minutes pour obtenir une réponse, qui est correcte quan dil y en a une !

Pour tester

https://visiolittoral.fr/ajax_JQUERY...=100&DEBUG=NON

NOTA : mettre DEBUG=OUI pour avoir le détail des appels API

[saxrub]

Bonjour

Le problème perdure depuis une semaine !


Mon hébergeur a poursuivi ses tests : ci-dessous son rapport



Comme vu ensemble par téléphone, voici le résultat de mes investigations :

Lors ce que le défaut se présente :

Le process PHP-FPM qui traite votre appel établi un appel vers l'IP 217.182.127.161 (ip OVH).

Un strace du process nous permet de voir qu'on attend quelque chose (Timeout en boucle) :
==========
poll([{fd=7, events=POLLIN|POLLPRI|POLLRDNORM|POLLRDBAND}], 1, 0) = 0 (Timeout)
rt_sigaction(SIGPIPE, {sa_handler=SIG_IGN, sa_mask=[PIPE], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7f460b20a970}, NULL, 8) = 0
rt_sigaction(SIGPIPE, NULL, {sa_handler=SIG_IGN, sa_mask=[PIPE], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7f460b20a970}, 8) = 0
rt_sigaction(SIGPIPE, {sa_handler=SIG_IGN, sa_mask=[PIPE], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7f460b20a970}, NULL, 8) = 0
poll([{fd=8, events=POLLIN|POLLPRI|POLLRDNORM|POLLRDBAND}], 1, 0) = 0 (Timeout)
==========

Lors d'un appel identique directement depuis votre serveur :
==========
root@saxrubsrv:~# curl -s -w '\nTemps de réponse pour: %{url_effective}\n\nLookup Time:\t\t%{time_namelookup}\nConnect Time:\t\t%{time_connect}\nPre-transfer Time:\t%{time_pretransfer}\nStart-transfer Time:\t%{time_starttransfer}\n\nTotal Time:\t\t%{time_total}\n' -o /dev/null "https://data.geopf.fr/geocodage/reverse\?index\=poi\&searchgeom\=%7B%22type%22:%22Polygon%22,%22coordinates%22:%5B\[\[-1.3270958575,46.1637001628\],\[-1.3399357582,46.1636996546\],\[-1.339933987,46.1548067355\],\[-1.3270961614,46.1548072436\],\[-1.3270958575,46.1637001628\]\]\]\}\&lon\=-1.3335154410308059\&lat\=46.15925362876149\&limit\=20\&citycode\=17360"

Temps de réponse pour: https://data.geopf.fr/geocodage/reve...dinates%22:%5B[[-1.3270958575,46.1637001628],[-1.3399357582,46.1636996546],[-1.339933987,46.1548067355],[-1.3270961614,46.1548072436],[-1.3270958575,46.1637001628]]]}\&lon\=-1.3335154410308059\&lat\=46.15925362876149\&limit\=20\&citycode\=17360

Lookup Time:  0.029046
Connect Time:  0.034258
Pre-transfer Time: 0.047756
Start-transfer Time: 0.073819

Total Time:  0.073890
==========

Cet appel est fonctionnel.

Puis, un nouvel appel dans la foulée qui termine en timeout :
==========
root@saxrubsrv:~# curl -s -w '\nTemps de réponse pour: %{url_effective}\n\nLookup Time:\t\t%{time_namelookup}\nConnect Time:\t\t%{time_connect}\nPre-transfer Time:\t%{time_pretransfer}\nStart-transfer Time:\t%{time_starttransfer}\n\nTotal Time:\t\t%{time_total}\n' -o /dev/null "https://data.geopf.fr/geocodage/reverse\?index\=poi\&searchgeom\=%7B%22type%22:%22Polygon%22,%22coordinates%22:%5B\[\[-1.3270958575,46.1637001628\],\[-1.3399357582,46.1636996546\],\[-1.339933987,46.1548067355\],\[-1.3270961614,46.1548072436\],\[-1.3270958575,46.1637001628\]\]\]\}\&lon\=-1.3335154410308059\&lat\=46.15925362876149\&limit\=20\&citycode\=17360"

Temps de réponse pour: https://data.geopf.fr/geocodage/reve...dinates%22:%5B[[-1.3270958575,46.1637001628],[-1.3399357582,46.1636996546],[-1.339933987,46.1548067355],[-1.3270961614,46.1548072436],[-1.3270958575,46.1637001628]]]}\&lon\=-1.3335154410308059\&lat\=46.15925362876149\&limit\=20\&citycode\=17360

Lookup Time:  0.152534
Connect Time:  0.163818
Pre-transfer Time: 0.000000
Start-transfer Time: 0.000000

Total Time:  300.659069
==========

Je reproduis exactement ce même comportement avec dysfonctionnent aléatoire depuis un poste distinct, situé derrière un lien d’accès Unyc.

Une trace réseau nous permet de visualiser que l'échange semble s'arrêter après l'initiation de la connexion SSL (durant laquelle il semble y avoir eu une perte de paquet, cf PJ).

Fait notable cependant, je n'ai pas reproduis le cas derrière un lien d'accès Orange.

Également, nous ne reproduisons pas d'autres cas similaire depuis un lien d’accès Unyc vers d'autres services hébergé chez OVH.

A ce stade, il serait intéressant que le service distant réalise également une capture des flux de son côté pour déterminer s'ils observent également ces pertes de paquets, visible dans la trace.

Disposent t'ils de pare-feux applicatif qui pourraient bloquer l'appel selon la source ? (Un genre de rate-limite sur la fréquence d'appels ?)

Cordialement,

[saxrub]

Retour à la normale avec "un bricolage" de mon hébergeur.

Je vous livre la solution de contournement qu'il a mis en place.

Concrètement, nous suspectons donc une problématique de MTU incorrect sur un lien d'interconnexion entre le backbone d'Unyc et celui de OVH, raison pour laquelle les règles de routage ont été modifiées suite à votre remontée. Il s'agit d'une solution de contournement temporaire.

Selon notre équipe d’ingénierie, le défaut serait localisé sur la partie chez OVH. Je n'ai malheureusement pas plus de détails à vous communiquer, si ce n'est que des actions sont entreprises pour une résolution long terme.