Hi, I would have suggest playing with the "option tcp-smart-connect" or "no option tcp-smart-connect" on the backend side, since the response time you observe is on the server side. As Willy mentionned, it would be interesting to get a capture of a single curl request passing through the haproxy box, using the "-i any" flag as well to get incoming and outgoing traffic.
cheers On Mon, Mar 5, 2012 at 1:14 AM, Randy Shults <[email protected]> wrote: > Like this? > > frontend all 0.0.0.0:80 > 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 >> >
