Re: NOSRV and retries

On Mon, Jun 30, 2008 at 10:39:21PM +0100, asim s wrote:
>
> Thank you for taking the time to respond.
> I have read your post carefully and tried to apply some new settings to my haproxy config:
>
> I set checks to 3s and maxconn 2, this came back with
>
> 127.0.0.1:40082 [30/Jun/2008:22:04:32.446] accounts accounts/acc1 5742/1/6221 30485 -- 68/68/68/2/+3 0/72
>
> I assume +3 means 3 attempts.

it means "3 retries + 1 redispatch (the '+' means redispatch).

> After playing around with it more and more I've realised that reproducing the redispatch is very difficult with rails servers, I've only been able to get redispatch to work a few times in my testing. In the log I do not see the servers drop out due to failed checks, however the checks may affect the ability for a client to make a connection in maxconn 1 or a client connection may hinder checks as you've said.

Your health checks should be fast, so there should be no reason why they would block incoming requests. In your log above, I see that the request spent 5 seconds in the queue, and was queued at the 72nd position. Is this normal for your application ?

> It looks as though if the request is in the global queue then its not considered for redispatch? Is this the case?

No it is not the case. The redispatch happens when the retry count is exhausted after last failed connection attempt to a server. But depending on the load balancing algorithm involved, you may still end up on the same server (eg: hash). Also, it might be weird to run between clients and Rails in pure TCP mode, because if neither of them closes the connection, it will remain opened (keep-alive) and unusable for all other requests.

> On another note, I've noticed 503s with sQ and NOSRV followed by some long running requests being logged with cD (client timeout is 50s and the requests are 70-80s). I assume thats down to those requests that disconnect using all the available servers.

Most likely yes.

> Would that be a case of using 'option forceclose' or 'option httpclose' to resolve the problem ?

You mean you really don't have "option httpclose" ? I should have added that this is a critical requirement with servers limited in number of connections, because you don't want a client to maintain a connection. "option forceclose" should slightly accelerate release of the closed connection.

Regards,
Willy Received on 2008/07/01 22:41