brandon-rhodes
commented
7 years ago Alas, the "request queue size" is merely the argument that the library passes to the operating system listen() call:
If you search the source code, you will see that no further use of the request queue size is made anywhere else. While the ForkingMixIn does have logic to limit the number of children, the ThreadingMixIn — which I would be most likely to be interested in using — does not seem to have any protection against, say, 1,000 new connections creating 1,000 threads. Thus my recommendation against using it!
If you figure out that it does have a limit, and I've simply missed it, feel free to re-open this issue for further discussion!
In the book, you recommended against using this because you can not limit the number of connected clients. From reading the documentation, we can set 'request_queue_size' which says:
_The size of the request queue. If it takes a long time to process a single request, any requests that arrive while the server is busy are placed into a queue, up to request_queuesize requests. Once the queue is full, further requests from clients will get a “Connection denied” error. The default value is usually 5, but this can be overridden by subclasses.
Does this limit the number of clients? is it a new addition to the library?