A technical question please. When 'mod_qos' decides to delay the reply (based on the QS_EventPerSecLimit directive, for example) then in what state is the 'httpd' process.
I wonder if the process remains (1) in a 'blocked' state associated with the given HTTP request for the time of the delay, or (2) somehow the client HTTP connection gets retired, the worker continues to process other queries and when delay is over it continues with the completion of the delayed response?
Cheers
B.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The delay is added while reading the request (header parser). Yes, the thread/process is blocked during that time. I recommend to use it together with a QS_EventRequestLimit directive only.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello
A technical question please. When 'mod_qos' decides to delay the reply (based on the QS_EventPerSecLimit directive, for example) then in what state is the 'httpd' process.
I wonder if the process remains (1) in a 'blocked' state associated with the given HTTP request for the time of the delay, or (2) somehow the client HTTP connection gets retired, the worker continues to process other queries and when delay is over it continues with the completion of the delayed response?
Cheers
B.
The delay is added while reading the request (header parser). Yes, the thread/process is blocked during that time. I recommend to use it together with a QS_EventRequestLimit directive only.