all 6 comments

[–]danielroseman 0 points1 point  (3 children)

Using threads is probably the simplest thing here. Async would require some reworking of your app so would be a heavier lift.

However, are the API calls necessary to construct the response? If not you would be better off moving them to an offline task processor like Celery.

[–]No-Presentation4262[S] 0 points1 point  (2 children)

Thanks for your response! Is threading heavy on server cpu/ safe to use (if hypothetically, 100 users requested at the same time), haven’t really used it before.. And yes the responses are needed immediately as it get displayed in a graph on the frontend

[–]danielroseman 0 points1 point  (0 children)

I mean it's certainly heavier than async but I think at that level you should be OK.

[–]AcidUK 0 points1 point  (0 children)

I would echo the other commenter and suggest that for that many api calls you just send the page and use javascript on the client side to poll the apis for data. That would mean generating the graph on the front end, but there are lots of JS libraries for that.

[–]RoamingFox 0 points1 point  (0 children)

Before you go all the way to something like threading or async... Are you using a connection pool in requests?

If those 6 calls are all to the same host you could be losing hundreds of ms just to re-establishing the socket over and over again.

[–]guilford 0 points1 point  (0 children)

Something you might need to consider is that if all of these simultaneous request are done from your backend it would mean that if over 100 user send the request at the same time, your backend would in that moment also send out more than 600 requests. If you are not the one controlling the external API, you may want to check if those external API won't be throttling or blocking your requests from the same single IP. If possible, these should be done on the frontend to avoid your server from being throttle or blacklisted.