Hypermail

From: asim s <asim_s3000#hotmail.com>
Date: Tue, 1 Jul 2008 23:14:48 +0100

The testing is being done internally with ab or siege to simulate the traffic. In production there will usually be 10 in the queue.

I use to use proxy balancer in apache to forward to rails apps. Using haproxy I set it in tcp mode because all i want to do is forward the connection onto rails.

Does 'option httpclose' take effect in tcp mode?

> Date: Tue, 1 Jul 2008 22:41:00 +0200
> From: w#1wt.eu
> To: asim_s3000#hotmail.com
> CC: haproxy#formilux.org
> Subject: 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
>

http://clk.atdmt.com/UKM/go/msnnkmgl0010000007ukm/direct/01/ Received on 2008/07/02 00:14

RE: NOSRV and retries