From what I understand, the Tq time is the time between the end of the TCP client handshake (presumably when using HTTPS the timer starts at the end of the SSL handshake) and the time that the last HTTP header is read.
The haxproxy 1.4 manual describes Tq time as:
Tq: total time to get the client request (HTTP mode only). It's the time elapsed between the moment the client connection was accepted and the moment the proxy received the last HTTP header. The value "-1" indicates that the end of headers (empty line) has never been seen. This happens when the client closes prematurely or times out.
However, further in the haxproxy manual, it is reported that Tq can be affected by haproxy waiting for the request:
If "Tq" is close to 3000, a packet has probably been lost between the client and the proxy. This is very rare on local networks but might happen when clients are on far remote networks and send large requests. It may happen that values larger than usual appear here without any network cause. Sometimes, during an attack or just after a resource starvation has ended, haproxy may accept thousands of connections in a few milliseconds. The time spent accepting these connections will inevitably slightly delay processing of other connections, and it can happen that request times in the order of a few tens of milliseconds are measured after a few thousands of new connections have been accepted at once. Setting "option http-server-close" may display larger request times since "Tq" also measures the time spent waiting for additional requests.
- How does waiting for other requests to be processed affect the Tq time if Tq is measured after the end of the TCP or SSL handshake? If possible, please describe this in terms of c programming calls to socket, listen and accept functions.
- How much time would Tq typically be increased because haproxy is serving other requests? Ball park figures are ok here. I'm guessing that the Tq increase will be only a few 10s of milliseconds.