vdbergh

From api.log ``` 2024-05-09 17:12:01.645786+00:00 : 5.52 ms (s) 1190.12 ms (w) https://dfts-0.pigazzini.it:443/api/upload_pgn 2024-05-09 17:14:10.054970+00:00 : 6.18 ms (s) 1191.21 ms (w) https://dfts-0.pigazzini.it:443/api/upload_pgn 2024-05-09 17:16:19.091182+00:00 : 5.40 ms (s) 2105.73...

On PROD ``` 2024-05-09 18:07:24.438469+00:00 : 21.81 ms (s) 1698.87 ms (w) https://tests.stockfishchess.org:443/api/upload_pgn 2024-05-09 18:29:16.939441+00:00 : 6.34 ms (s) 1341.83 ms (w) https://tests.stockfishchess.org:443/api/upload_pgn 2024-05-09 18:50:43.001719+00:00 : 56.01 ms (s) 1253.63...

Good numbers of DEV :smile: I assume PROD is not yet running this PR?

I rebased the PR and removed the conflicts. Future plans (after this PR): - create an internal api `/api/task_count` to ask the primary instance for the current number of tasks...

I think the validation of `(run_id, task_id)` on a non-primary instance is only invoked for `/api/upload_pgn` which is already a fairly expensive api which is only invoked once per task....

As I wrote above we should really have an api which asks the primary instance to send `(task_count, task)` if `task_id` is present in the request on a secondary instance....

But you showed me only part of the server log. No actual timings....

> it is sample based profiling, i.e. random interrupts of the execution, the probability of hitting that trace is proportional with the time spent. Hence the count is relevant. I...

This can be closed. Free monitoring is long gone.

> What about a table with a dropdown menu to select between pending, blocked and all? It is about blocked workers. Not blocked users.