Closed Alexandre-Monney closed 2 weeks ago
pix-bot-github
commented
2 weeks ago Une fois les applications déployées, elles seront accessibles via les liens suivants :
Les variables d'environnement seront accessibles via les liens suivants :
laura-bergoens
commented
2 weeks ago Hello, je passe une petite tête ! Tu peux peut-être demander aux captains, avec leur accompagnement et monitoring à chaque étape, de te monter une petite API connectée avec la base de répli (comme ça t'as le volume). Pour ce qui est du trafic, c'est loin d'être idéal mais c'est mieux que rien, je te conseille l'usage de siege par exemple pour bombarder ton API et avoir des stats de temps de réponse. Evidemment, à faire avec des endpoints SANS effets de bord (ne pas altérer la base de réplication)
Alexandre-Monney
commented
2 weeks ago Hello, je passe une petite tête ! Tu peux peut-être demander aux captains, avec leur accompagnement et monitoring à chaque étape, de te monter une petite API connectée avec la base de répli (comme ça t'as le volume). Pour ce qui est du trafic, c'est loin d'être idéal mais c'est mieux que rien, je te conseille l'usage de siege par exemple pour bombarder ton API et avoir des stats de temps de réponse. Evidemment, à faire avec des endpoints SANS effets de bord (ne pas altérer la base de réplication)
Le soucis c'est que ce endpoint est utilisé par data la nuit aprés la réplication. Donc c'est pas le trafic de la journée dont on a besoin mais plutôt de la charge de la nuit pendant la repli/calculs etc. Parce que la journée ça passe très bien !
Edit : Et j'ai posé la question a @sandalfon pour justement faire des tests hors prod, mais compliqué. Donc étant donné que c'est trigger que via leurs webhook, on peut se permettre un test en réel quand ça sera mergé :D Et coté captains @MathieuGilet suit le sujet également :D
:unicorn: Problème
Suite à cette PR :
Nous avons constaté que, pour notre POC, l'utilisation de mécanismes et méthodes existantes n'était pas du tout optimisée au niveau des performances. Lorsque ce endpoint était appelé pour faire la récupération des stats, il pouvait mettre plus de 60 sec à envoyer sa réponse, ce qui provoquait la fermeture de la connexion côté client et donc des erreurs des deux côtés.
:robot: Proposition
Créer des méthodes de repository spécifique a ce cas d'usage afin de réduire considérablement le nombre de requêtes faites a la BDD.
:rainbow: Remarques
J'ai ajouté l'information de l'organisationId au niveau du model PlaceLots en optionnel car dans notre cas nous en avons besoin pour recouper les infos avec la bonne orga alors que dans d'autres usages plus classiques il n'est pas nécessaire. Dans le cas où ce code règle notre souci de performance, on pourra possiblement faire un refacto pour sortir cet organisationId de ce model et plutôt formatter les données depuis le repository (comme c'est le cas pour la répartition des places)
:100: Pour tester
Mis à part les tests au vert, il n'est pas possible de tester l'amélioration des performances tant que ce ne sera pas avec les véritables données, le volume et le trafic de la production