Closed philderbeast closed 3 years ago
Unless this was running on the prod docker-compose there is nothing to do about this. Running concurrent intensive operations is well beyond the scope of the flask dev web server.
In prod there is queuing of background tasks (outside of the web server). If this was or were to be run on prod there may still be an issue if using the local dev mySQL as opposed to a proper dedicated mySQL instance, however it is less likely.
This was with docker-compose -f docker-compose-dev-local.yml up
. Can we not have queuing for that setup too?
regarding the time to process 1 task, given there are 120 pilots and the tasks are lengthy I think that is acceptable. There are some speedups that could be done but at this stage it has been fast enough.
This was with
docker-compose -f docker-compose-dev-local.yml up
. Can we not have queuing for that setup too?
I think redis workers could be set up for the dev server but not the SSE messages. This would be quite an effort to setup and fracture the code. IMHO far more effort than the 5-10 seconds it takes to switch between dev and prod (without the nice messages processing a track). Pull requests welcome, but in terms of time invested I think the payback period would take more years than the life of the project.
I just had a thought that perhaps you are unaware just how simple it is to swtich. When dev is running Ctl-c will stop it in the terminal. docker-compose -f docker-compose-prod-local.yml up
will start prod and then you can continue in the browser where you left off (provided you have logged in previously)
If I import the HG Worlds 2019, I note that the tasks [bulk import tracks] each take quite some time, upwards of 4 mins for each task.
I didn't want to wait that long repeating the test so I [bulk import tracks] for each task without first waiting for the prior import of tracks to complete. I encountered an error doing this: