Processing queries concurrently in gunicorn-powered Python Web server
I solved this issue now by separating the Web server and the query processing into separate processes that communicate over UNIX sockets. It seems that sockets only add a tiny overhead, which is likely acceptable in this case.
If there is a better solution, I'm still open for further suggestions.
Because of tight time constraints and good parallelization possibilities, my server backend needs to process a single query in multiple independent worker processes. To this end, I provided a set of n worker processes that communicate with the main process over multiprocessing queues. The main thread puts data into the input queue and each worker thread takes an item from it and processes it.
For clarification, an example: Suppose, this is a system that checks which numbers in [0, 100) are divisible by x. A user submits a number x to the REST API. Thus, the main process puts tuples (i, x) for i in range(100) into a queue. Each worker process then takes one tuple out of the queue and puts (i, i % n == 0) into the result queue. Once the main process got 100 results back, it'll respond to the user.
Although this works fine on a stand-alone system, this makes problems once I put it behind a gunicorn server, namely, the information in the queues is lost and the main process hangs up. I need gunicorn because I want to make this service available via a REST API on the Web.
(1) Is there any possibility to make this compatible with gunicorn? 
According to my previous research, gunicorn is incompatible with the multiprocessing module of Python. Hence, (2) are there any alternatives to the above described approach in this case?
For example, as an alternative, I thought about multiple independent service processes that are not spawned within the Python application, but are rather stand-alone. However, I cannot think of a simple and efficient possibility to implement that. If I'd implement another REST API for those worker processes, I'd lost a lot time with sending messages through the network stack. Thus, I'd need a more low-level approach, such as pipes or shared memory. (3) Do you have suggestions for me?