> What is the difference between request-timeout and socket-timeout?
Socket timeout is a very low level timeout value that relates to how long a
blocking operation on a socket connection should allow to go on before timing
out.
If using mod_wsgi directly and not via mod_wsgi-express, the socket-timeout
option to WSGIDaemonProcess directive, if not defined, will default to the same
value as is set for Apache as a whole using the Apache Timeout directive. For
Apache 2.2 the Apache Timeout directive defaults to 300 seconds. In Apache 2.4,
this has been reduced down to 60 seconds.
If using mod_wsgi-express the socket-timeout option is defaulted to 60 seconds
and doesn't matter whether using Apache 2.2 or 2.4.
For mod_wsgi the socket-timeout relates specifically to communication over the
socket connection to the daemon processes.
Before I explain what request-timeout is for, if you are now seeing 504 gateway
timeout errors and logged messages of:
[Tue Feb 10 22:00:50 2015] [error] [client ::1] Timeout when reading response
headers from daemon process 'localhost:8000':
/tmp/mod_wsgi-localhost:8000:502/htdocs/
we will need to adjust this. The fact that your requests are long running but
do not actually return any response content until done complicates things and
means the default needs to be set higher in line with changes to
request-timeout.
One important point with socket-timeout is that it will cause the Apache worker
child process to timeout on waiting for a response from the daemon process.
Although it will timeout and return a 504 gateway timeout error, it doesn't
actually stop the request which would still be running in the daemon process.
Now we get to request-timeout. This is a fail safe timeout to protect against
hung requests causing all available request threads to be consumed and for your
daemon process running your web application to stop.
If using mod_wsgi directly, no request-timeout is specified at all and so there
is no protection against hanging requests.
If using mod_wsgi-express, the request-timeout is 60 seconds.
If the daemon process were single threaded, what will happen is that any HTTP
client would see the socket timeout expire and so it would see a 504 gateway
timeout.
At the same time, within the daemon process the request-timeout would expire
and the daemon process will enter an automatic restart to forcibly terminate
the long running request on basis that since has reach 60 seconds, it has got
stuck.
Remember at this point that web applications would want to generally return
with seconds and preferably sub second. A web application is not generally the
best place to be running very long running operations.
That said, the default timeouts are biased to what would be the norm for web
applications, which is very fast requests.
Now, if the daemon process is multithreaded things get complicated.
This is because if one request only were to reach request-timeout, but there
were much younger requests which had only just started running, you don't
really want to go restarting the process as you will interrupt the requests
which just started.
The best solution I could come up with to handle this situation of a
multithread daemon is that when the total running time of all currently active
requests, divided by the number of threads for the process, reaches the
request-timeout only then would the process be forcibly restarted. In effect
the notional average running time based on capacity.
This means that if only the one request was running and you had default of 5
threads, if it had been running for 60 seconds, then in fact you get a value of
12, which isn't greater than 60, so nothing has done.
So because there was spare capacity, the request is actually allowed to keep
running much longer than it would otherwise as there is no harm doing so since
we still have 4 spare threads with capacity to handle new requests.
If no other requests came in, then that one request could actually run out to
300 seconds before the process was forcibly restarted.
If however you had five requests start at the same time and they all ran out to
60 seconds, the derived value would be 60 and a restart would happen straight
away.
So in a multithread process an attempt is made to allow requests to keep
running while it looks like there is still capacity available.
As to the log messages you gave me, it is a bit hard for me to relate this to
what you saw as I don't know what the number of threads was you were running.
It seems you had increased it beyond 5. And I didn't know what the
request-timeout was set to either.
What one can see is that the socket-timeout did trigger too early.
> One page on site is calculating integral.
> There is time limit of 150 sec. If 150 seconds passed and no solution, then
> Python raises an Exception and request is returned (no solution).
If you have a hard limit within your algorithm of 150 seconds, and since you do
not return any data as the request goes on, change the options in
express-config to have:
--request-timeout 180
--socket-timeout 180
The --socket-timeout option is new.
I can't comment really on what the --threads option should be at this point.
> What is the best way to cut memory? Reduce time? Will this really help?
I don't know what your algorithm for integral calculation does.
Does the algorithm itself cause a lot of memory use?
Have you tried extracting the integral algorithm into a standalone Python
script separate from your web application and run it and watched how much
memory it uses?
Does the memory usage grow the longer it runs, or does it plateau and stay flat?
If it keeps growing in memory usage and so the only thing that keeps down the
memory usage is how long it runs for, you probably need to look at how your
algorithm works and whether it is working in an efficient manner such that
memory can be relaxed and reused as it goes.
> Will 60 or 90 seconds reduce memory?
No idea. Depends on what your integral algorithm is doing.
> What will be consequences if there will be more load on the page (more
> visitors)?
If the problem is your algorithm, having more threads to handle the load will
cause greater overall memory usage.
How complicated is this algorithm? Are you using a package which has
implemented such algorithms in an efficient way or have you implemented it
yourself?
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.
