Like this?
frontend all 0.0.0.0:80 <http://0.0.0.0/>
log global
maxconn 10000
option http-server-close
no option tcp-smart-accept
timeout client 4000
default_backend psb
acl is_psb path_beg /psb
acl is_crossdomain path_beg /crossdomain
acl is_stats path_beg /stats
use_backend psb if is_psb
use_backend psb if is_crossdomain
use_backend stats if is_stats
Its still .236s.
Not to get distracted, but its not just in curl, using android's
HttpClient, I get worse results when looking at the haproxy logs, though
proportionally the Tq is higher. With android's I occasionally also see Tt
of just under 4seconds, though I think thats a tcp dropped packets issue.
My main focus right now is getting the curl times in line with each other.
With the test in curl, the lowest in the set of 100 was .231s and the
highest .239s.
On Sun, Mar 4, 2012 at 6:36 PM, Willy Tarreau <[email protected]> wrote:
> Hi Randy,
>
> On Sun, Mar 04, 2012 at 05:11:30PM -0500, Randy Shults wrote:
> > I must be configuring something incorrectly, but I dont know what,
> because
> > I've seen response times increase by 200ms with haproxy than on Nginx.
>
> 200ms typically sounds like a TCP delayed ACK issue.
>
> Could you please test if adding "no option tcp-smart-accept" to the
> frontend
> fixes the issue ? If so, I'd be very much interested in getting a network
> capture of a whole request (please use tcpdump -s0 to get full packets).
>
> It might be possible that curl uses an "Expect: 100-continue" header and
> that we don't disable the delayed ACK when sending it (just a suggestion,
> I'm not saying this is what happens).
>
> Regards,
> Willy
>
>
