OK, I'll try setting timeouts like this and see how that works.
timeout connect 5s
timeout client 20s
timeout http-request 5s
timeout server 20s
timeout queue 20s
-Bryan
On Jan 8, 2010, at Jan 8, 12:38 PM, Willy Tarreau wrote:
> On Fri, Jan 08, 2010 at 12:13:37PM -0800, Bryan Talbot wrote:
>>
>> I'm trying to understand exactly what this termination state means. I'm
>> seeing http connections from clients that seem to be complete and queued.
>> These requests seem to be timing out from the queue well before the "timeout
>> queue" time though. The proxy is busy at these times and there are a number
>> of requests queued.
>>
>> Why are these sessions terminated? I was expecting it to be terminated
>> after the 30s "timeout queue" but it seems to have terminated after just 5s
>> while waiting for client data (which seems odd since the Tq value is present
>> and small). My understanding was that requests would not be queued until
>> the client completed sending the request.
>>
>> Here is a sample log entry that shows the issue. This is using 1.3.20 btw.
>>
>> 111.222.333.444:1234 [08/Jan/2010:13:05:42.055] web portal/<NOSRV>
>> 19/5000/-1/-1/5019 503 212 - - cQ-- 811/811/721/0/0 0/550 "GET /foo/bar
>> HTTP/1.1"
>
> I think I know what is happening :
>
>> defaults
>> timeout connect 5s
>> timeout client 5s
>> timeout http-request 5s
>> timeout server 20s
>> timeout queue 30s
>
> The "timeout client" fires before "timeout queue". Client and server
> timeouts have always covered the other ones, but I suspect that in
> this specific case we should be able to disable the client timeout
> when we're waiting in the queue. This is a risky change as we
> absolutely need to ensure we re-enable it when leaving the queue,
> but that's something that needs to be studied because I think it
> makes sense to do it.
>
> In the mean time, you should simply set your "timeout client" to
> at least the same value as "timeout queue". As a general rule of
> thumb, I recommend to set both client and server timeouts to
> similar values, because it avoids head scratching trying to
> understand which one should have fired first. Also, if your client
> timeout is smaller than the server's, haproxy will not necessarily
> know whether the server is not responding because it is waiting for
> the client or because it's working, so the client timeout will still
> fire when your server responds slowly. Thus, I think you could
> reasonably set "timeout client" to 30s and leave the other ones
> untouched.
>
> Regards,
> Willy
>
