Update frequency of run state scales with number of submissions

[mpas97]

When a task is started, the UI refreshes around 1x per seconds. The more submission have been made, the more often the UI is refreshing. After one or two submissions, the UI is already firing at least 4 requests per second to check if there have been updates in the meantime. But this is too much. Doing 2-3 submissions more, we are already at ~10x/s and soon at >100x/s.

And currentIy I am the only user using this instance. So if the server is already going to be overloaded that way, we can't scale any further.

E.g., starting a task, doing 10 submissions, wait 10 seconds and the client has already done >1000 requests.

[lucaro]

I don't quite understand where this comes from. Could you elaborate on what exactly is requested?

[mpas97]

Being in the competion viewer, you can open the network inspector. When you start a task you'll see ~1 request per second. In the picture above I was in the viewer for run 3 (calling /api/run/state/3). But as soon there have been some submissions, the UI increases the refresh rate (I don't know why and this is what should be found and solved). So after having done some submissions, the UI calls /api/run/state/run_id much more often.

[lucaro]

Ok, so it is the call to /api/run/state/run_id which is the problem. Thanks for that clarification.

[ppanopticon]

Actually it has nothing to do with the submissions themselves but the WebSocket driven update of the RunState while a task is running.