Hi Paul, On Thu, Jan 14, 2010 at 03:21:13PM -0800, Paul Hirose wrote: > A simple question - is the data received from the back-end server > stored on haproxy until "all" the data is received, before that date > is then sent on to the client? I didn't think so, but I wasn't sure > now.
no it's not. Data is sent as it is received, and at most a buffer size can be buffered (16kB by default). > I'm now seeing a few "cD" connection status: > Jan 14 14:51:15 lbtest1 haproxy[18994]: BBBB:42553 > [14/Jan/2010:14:48:15.329] LDAPFarm LDAPFarm/dp2 0/0/180008 196 cD > 0/10/10/3/0 0/0 > > My config > defaults > mode tcp > log global > option tcplog > option dontlognull > # option dontlog-normal > option redispatch > option tcpka > retries 3 > maxconn 4096 > > listen LDAPFarm VIP:389 > mode tcp > option tcplog > option httpchk > balance roundrobin > timeout connect 5s > timeout client 180s > timeout server 180s > timeout check 900ms > server dp1 AAAA:389 check addr 127.0.0.1 port 9101 inter 5s > fastinter 1s downinter 3s fall 2 rise 2 > server dp2 BBBB:389 check addr 127.0.0.1 port 9102 inter 5s > fastinter 1s downinter 3s fall 2 rise 2 > server dp3 CCCC:389 check addr 127.0.0.1 port 9103 inter 5s > fastinter 1s downinter 3s fall 2 rise 2 > > > These are LDAP queries. If I read this correctly, there were 196 > bytes sent from haproxy to the client. The docs define bytes_read as > "- "bytes_read" is the total number of bytes transmitted from the > server to the client when the log is emitted." Is that necessarily > how much the back-end server sent to haproxy, and how much haproxy > sent to the client? Could there be a difference in those two numbers? yes there could be if some data was stuck in haproxy because the client did not read it. To be precise, the number in the logs is the amount of data read from the server (which is supposed to be sent to the client). So in theory it *would* be possible that those 196 bytes were never sent to the client. In practice, it's not possible because 196 bytes is a lot smaller than the smallest system buffer (4kB min), so you're certain that everything was sent. The fact that the client received it or not is another question we can't respond since we don't have the info. In fact under linux we could ask the socket about unacked data, but that's so much not portable that I prefer not to do it. So there, we can say with certainty that the 196 bytes were forwarded and that the connection expired just because it was idle. > Is there a log enttry (or option) that records how many bytes was sent > from the client to haproxy and forwarded from haproxy to the server? No. Someone already asked this to me a long time ago, but the problem is to know where to log it. So I have added this to the TODO list, and it will be covered with a later rewrite of the logging subsystem. The info is present in the code, so if you're interested in patching a little bit, you don't risk much, as that area almost never changes. (...) > Finally, if anyone is using haproxy for LDAP/S, and would be willing > to share any best-practices, configurations, etc for such a setup, I'd > be most appreciative. Ours has been working for several days now, and > seems to be happy. But it's still only a tiny handful of various > LDAP/S clients using the haproxy VIP. We're slowly ramping up, adding > a few more here and there at a time. But sooner or later, we'll > change the DNS for our LDAP IP to the VIP of haproxy, and then it'll > be "everyone" using it all at once. I know someone who set it up just as an on/off switch in front of an ldap server. There was nothing special to do there. Ah, you might want to add "option contstats" so that your stats are updated along the transfers, not only once a session closes. It's better for monitoring purposes. Regards, Willy
