Forums

I am working on a page that will automatically update certain elements when certain changes are made to my database (mongoDB Atlas)

At the moment, I am requiring the user to manually request (ajax) from client-to-server and retrieve the relevant data.

This is highly inefficient and costly as I am retrieving the data regardless of change. It is also not a smooth user experience.

As far as my novice knowledge goes, I am presented with 2 options:

1. Periodically (every few seconds) send a client-to-server request to check if there are any changes. This increases the server hits a lot.
2. Send a single client-to-server request and do the periodic checking on the server-side instead.

Is my understanding correct that 1 of my N web workers will be fully occupied with the periodic checking (since request is not replied by server till change is detected) and in this case I can only have up to N users with their dashboard open before exceeding the web worker limit?

Thank you for reading through this!! Appreciate any help or better solutions.

It depends on the time it takes to produce a response in your code. If it's fast it takes a lot of requests to saturate your workers.

Got it. Thank you for the response.

Just to be absolutely clear, 1 web worker is solely dedicated to running the code for 1 request and can only move on after the response is sent to the client.

What about CPU-hours then? As websockets is not currently available,

Suppose i am perodically (say, every 10s) pinging the server to check if a file exists on the server.

How will i gauge the CPU-time needed for this operation?

Can i use the time bash command and add the user + system timings ?

1 web worker is solely dedicated to running the code for 1 request and can only move on after the response is sent to the client.

Yes, that's exactly right.

What about CPU-hours then? As websockets is not currently available,

CPU-hours don't apply to WSGI websites, so you don't need to worry about that right now. (When we do support WebSockets in the future, we are likely to have to make the CPU quota apply to them, though, as they run in a very different way.)

Thank you for prompt response as always! Happy new year!

Happy new year to you too!