[API] Timeout de certains endpoints clés

[alexphiev]

J'ai noté trois endpoints de l'API nécessaires au front qui échouent tout le temps :

• /zones 502 Bad Gateway après quelques dizaines de seconde de chargement ou timeout après 180s
• /vessels/{vessel_id}/excursions : Timeout après 180s (même pour une période de 1 jour)
• /metrics/vessels/{vessel_id}/activity/{activity_type} : 500 Internal Server Error instantanément ou timeout

Testés le 15/11/2024 sur le swagger et avec Postman.

[rv2931]

J'ai pas encore regardé mais Tu peux préciser si c'était avait des id en particulier ou si c'était sur tout

[alexphiev]

Oui pardon, j'ai principalement testé sur le vessel 1388 et sur la zone 660. Pas eu le temps de faire plus de tests pour l'instant.

[rv2931]

Sur postman j'ai une erreur Error: Maximum response size reached
Sur le Swagger j'ai effectivement un genre de timeout pas franc
je vais regarder un peu la gueule et la taille de la réponse voir si c'est si gros que ça

[rv2931]

Effectivement la réponse fait 72Mo
Sur postman, la valeur par défaut est de 50Mo, et il y a un warning disant d'éviter de dépasser 100Mo pour éviter des dysfonctionnement d'une manière générale.
Dans les bonnes pratiques API, il y a souvent une vue liste qui ne contient que les informations essentielles et ensuite il est préconisé d'aller chercher les infos plus détaillées soit sur un set restreint d'items avec une options demandant d'y ajouter les détails soit d'aller chercher les infos détaillées items par items pour éviter ce genre de souci de "grosse réponse"

[rv2931]

J'ai activé la compression gzip qui compresse la réponse dès qu'elle dépasse 1Mo et que le Accept-Encoding: contient gzip dans la requête
Je tombe bine à 21Mo au lieu de 72Mo mais Postman considère toujours que la réponse fait 72 car la limite des 50Mo est déclenchée même avec la compression

[rv2931]

A terme les zones devraient être échangées via des fichiers "tiles" qui seront sûrement moins gros mais resteront tout de même assez gros
Ce qui prend beaucoup de de place c'est les coordonnées Zones
J'ai modifié les réponses de requêtes pour n'avoir qu'une liste de champs limitée (ZoneIdent) dans les requêtes qui contiennent des zone, cependant il faudra tout de même à moment avoir les coordonnées de toutes les zones au moins une fois
La best practice API est plutôt de récupérer la liste de zones retournant seulement les infos d'idnetification (ZoneIdent) et ensuite de récupérer les coordonnées des zones sur le endpoints /zones/{id} qui là renvoie toutes les données

Mais ce qui est prévu aujourd'hui normalement c'est d'avoir un endpoint qui renvoie tout d'un coup.

Après la manière list[ZoneIdent] puis requêtage zone par zone détaillée est pas forcément contradictoire avec es fichiers tiles à venir car j'imagine qu'il faudra de toutes façon avoir les infos d'identité des zones (sans la partie graphique) d'un côté et de l'autre la partie géométrie via les "tiles" qui représente bcp plus de données

[SebM42]

Etant donnée la difficulté de récupération des données des zones via API, est-il envisageable dans un premier temps et pour le 19 de récupérer les géométries de zones depuis un fichier hébergé sur le serveur que le front pourrait récupérer directement ?

[rv2931]

Pour les zones c'est bon
je vais mettre en place la pagination sur les autres endpoints qui posent soucis sur le même principe

[rv2931]

JE suis en train de voir pour généraliser le concept de pagination sans tout casser, la solution est déjà trouvée, par contre en essayant de le faire le plus proprement possible pour ne pas avoir trop de code répétitif et sale. ça va me prendre un peu de temps mais je pense que je suis à 50% de l'objectif

[marthevienne]

Je clos ?

[alexphiev]

Je ne vois plus de timeout sur les requêtes API faites par le front.