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?
>> >> 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.
>> 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.
>> It looks as though if the request is in the global queue then its not considered for redispatch? Is this the case?
>> 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.
>> Would that be a case of using 'option forceclose' or 'option httpclose' to resolve the problem ?
http://clk.atdmt.com/UKM/go/msnnkmgl0010000007ukm/direct/01/ Received on 2008/07/02 00:14
This archive was generated by hypermail 2.2.0 : 2008/07/02 00:31 CEST