I am a bit confused at this point. If you are manually configuring Apache for mod_wsgi, then you would not be using mod_wsgi-express. They are distinct ways of doing things.
The defaults for doing it manually with Apache don’t have the queue timeout having a default and so you shouldn’t see the timeout. Can you describe better the architecture of your system and more about the whole configuration? Graham > On 25 Aug 2015, at 1:36 am, Julien Delafontaine <[email protected]> wrote: > > Thanks for the very clear explanation ! > > I have 2 CPUs at my disposal and I use an Apache config where I have > WSGIDaemonProcess ... processes=2 threads=6 > although my wsgi.py is untouched, and the `mod_wsgi-express` command to > launch it does not have parameters. > I believe that I am seeing 2 processors used at the same time with this > config. > > I think I cannot set more processes than I have CPUs, am I right ? Which > means the only ways to solve my problem are to speed up the computations, or > buy more CPUs ? > > On Monday, 24 August 2015 06:17:25 UTC+2, Graham Dumpleton wrote: > > > On 23 Aug 2015, at 5:46 am, Julien Delafontaine <mura...@ <>gmail.com > > <http://gmail.com/>> 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] > <mailto:[email protected]>. > To post to this group, send email to [email protected] > <mailto:[email protected]>. > Visit this group at http://groups.google.com/group/modwsgi > <http://groups.google.com/group/modwsgi>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. -- 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.
