I’m currently testing an implementation of multiple render queues, to be rolled out to the public production server, soon.
So far all render requests were processed by a single render service process only, leading to all requests being processed in a serialized first-come-first-serve way.
This lead to long running requests, like especially the multi page renders, starving the requests that came in after them. Also with the render API probably getting to see quite a few more requests in the future these could start to compete with regular user requests, and API clients may file multiple request within a short time span.
By having multiple render queues served by different render service processes part of this can be handled in a more graceful way, and at the same time increase total render throughput by having more than just a single render process on a machine with many CPU cores.
For a start there will be three different queues:
- default
- this is the classic queue for interactive requests
- multipage
- interactive requests for multi page map booklets go here as they usually take longer to render
- api
- all requests coming in via the API will end up here so that they do not starve regular requests by web UI users
So far testing went well, so if nothing unexpected pops up in the last minute I will roll out the changes to the public server on Friday.