As the number of TOS Jobs grows, one Container is unable to handle the load of multiple TOS Jobs (they are way too performance hungry, being Java and all...).
A natural way would be to re-visit Celery and create a concept on how to implement celery to the TOS Agent. Note that this could mean the the way to upload Jobs may change dramatically.
Edited
Designs
Child items ...
Show closed items
Linked items 0
Link issues together to show that they're related.
Learn more.
Celery is much more established than the solution I created myself. It may not increase performance per se, but it should add a lot more robustness towards a high number of jobs. Ultimately, I expect Celery to provide a better possibility to just add resources to and allow a performance increase that way.
But you are right, performance increase is pretty much wrong here
parciakchanged title from Concept: performance optimization of job queueing and running to Concept: robustness optimization of job queueing and running
changed title from Concept: performance optimization of job queueing and running to Concept: robustness optimization of job queueing and running
I implemented a prototype and added some documentation also. You can test and review the basic approach in this repository.
The code should not be of main interest here. Check the basic concept I applied to distribute TOS Jobs as tasks onto Celery workers and all the services I added to the agent.
Could we maybe have a semi-spontaneous developer meeting tomorrow where you talk the rest of us through the changes and concepts? Some time in the afternoon?
As discussed, @tobias.zimmer, check the merge request and the comments to hopefully get some insight on how the prototype works. Feel free to create an own merge request based on the MR in order to refactor some of the code.