⚡ Error 500 in heavy load conditions

[lpofredc]

Describe the bug

Last sprint, BiodivSports app instance have often been unusable due to an heavy load (almost camptocamp calls, which culminate to more than 250000 hits/day this summer). Consequently, server returned very often an 500 error to users.

Problem have been fixed by configuring ASGI Django mode, instead of traditional WSGI mode. (PR Coming very very soon).

To Reproduce

Difficult to reproduce...

Expected behavior

No error ;)

Screenshots

None

[babastienne]

Thanks @lpofredc for your feedbacks. Glad to hear that your change in configuration has solved the issue.

Looking forward to see your PR 👍

[submarcos]

Hello @lpofredc

ça serait bien d'en discuter

Dans la mesure ou vos données ne changent pas trop souvent, peut être qu'un simple cache au niveau nginx pourrait convenir sans pour autant compléxifier le code pour un cas qui n'est pas forcément généraliser.

à disposition pour en parler

[lpofredc]

Merci @submarcos pour ces pistes. A ma connaissance, le cache nginx ne pourra pas répondre à ce cas de figure. la forte charge de l'instance concernait très majoritairement des appels d'API sur la liste des zones sensibles au format geojson filtrées par bbox, avec des coordonnées de bbox spécifiques à chaque appel.

[submarcos]

Merci @submarcos pour ces pistes. A ma connaissance, le cache nginx ne pourra pas répondre à ce cas de figure. la forte charge de l'instance concernait très majoritairement des appels d'API sur la liste des zones sensibles au format geojson filtrées par bbox, avec des coordonnées de bbox spécifiques à chaque appel.

Hello, en effet je ne connais pas toutes les problématiques, d'ou mon intérêt d'en discuter avant pour avoir tes retours d’expérimentations, avant de te laisser ouvrir une PR qui pourrait apporter d'autres problématiques en résolvant certaines.
L'ASGI est un grand pas en avant, mais pour avoir expérimenté avec django ce n'est pas encore totalement au point, aussi en essayant d'être un peu le garde fou de la complexité du code je voudrais être certain que ce qui est implémenté est nécessaire et relativement simple.
Je suis dispo pour discuter conception avant de relire ta PR si jamais

[submarcos]

Utiliser un moteur asgi avec du code synchrone peut en effet aider à paralleliser et résoudre certains de tes problèmes mais en empirant les perfs générales car les actions synchrones seront convertties à la volée. As-tu fait des benchmarks poussés, et comparé avec d'autres système synchrones utilisant les threads comme gevent ou gthread ?
https://blog.muehlemann-popp.ch/gunicorn-uvicorn-and-uwsgi-tested-which-wsgi-server-leads-in-speed-652d9bf9d2a7
Il es tfort probable que l'utilisation de gevents avec gunicorn soit tout aussi efficace sans changer le moteur pour du faux asynchrone (synchrone converti mais threadé)

[submarcos]

Donc autant je serai méfiant et j'attendrai pas mal de tests pour passer à uvicorn (du moins tant qu'on utilise pas les fonctions asynchrones de django qu isont tjrs en cours d'implémenation), autant si il est vrai que gunicorn + gevents améliore considérablement les perfs, alors on pourrait le mettre en place très rapidement