> On 23 Aug 2015, at 5:46 am, Julien Delafontaine <[email protected]> wrote:
>
> Hello,
>
> I am really having a hard time finding out what happens here :
> I send requests to my python server that take maximum 1-3 secs each to
> respond (so way below the usual 60 sec timeout), but sometimes, I randomly
> get this response instead :
>
> mod_wsgi (pid=8447): Queue timeout expired for WSGI daemon process
> 'localhost:8000'.
>
> I can't reproduce it at will by a sequence of actions. It seems that it once
> the server sends back an actual andwer, it does not happen anymore.
> What sort of parameter do I have to change in order that to never happen ?
What you are encountering is the backlog protection which for mod_wsgi-express
is enabled by default.
What happens is if all the available threads handling requests in the WSGI
application processes are busy, which would probably be easy if your requests
run 1-3 seconds and with default of only 5 threads, then requests will start to
queue up, causing a backlog. If the WSGI application process is so backlogged
that requests get queued up and not handled within 45 seconds, then they will
hit the queue timeout and rather than be allowed to continue on to be handled
by the WSGI application, will see a gateway timeout HTTP error response sent
back to the client instead.
The point of this mechanism is such that when the WSGI application becomes
overloaded and requests backlog, that the backlogged requests will be failed at
some point rather than left in the queue. This has the effect of throwing out
requests where the client had already been waiting a long time and had likely
given up. For real user requests, where it is likely they gave up, this avoids
handling a request where if you did still handle it, the response would fail
anyway as the client connection had long gone.
This queue timeout is 45 seconds though, so things would have to be quite
overloaded or requests stuck in the WSGI application for a long time.
Now if you are running with very long requests which are principally I/O bound,
what you should definitely be doing is increasing the default of 5 threads per
process, which since there is only 1 process by default, means 5 in total
threads to handle concurrent requests.
So have a look at doing something like using:
—processes=3 —threads=10
which would be a total of 30 threads for handling concurrent requests, spread
across 3 processes.
Exactly what you should use really depends on the overall profile of your
application as to throughput and response times. But in short, you probably
just need to increase the capacity.
The question is though, are you using the defaults, or are you already
overriding the processes and threads options?
Graham
--
You received this message because you are subscribed to the Google Groups
"modwsgi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/modwsgi.
For more options, visit https://groups.google.com/d/optout.
