Re: act/fe/be/srv-conn explanation
On Fri, Jan 22, 2010 at 10:15:18AM -0800, Paul Hirose wrote: > I'm sending this again. I never saw it come back to me from the list > and the archive at > http://www.formilux.org/archives/haproxy/1001/date.html doesn't have > this copy either. you're damn right. While I correctly received your mail, it does not show up on the archives. I don't know why. The "marc.info" site has a copy of the list and does not appear to have this message either. We'll have to monitor this closely, maybe we have a problem somewhere in the delivery chain. Thanks Willy
Re: act/fe/be/srv-conn explanation
Hi Paul, On Wed, Jan 20, 2010 at 02:51:23PM -0800, Paul Hirose wrote: (...) > Sample entry from my logs: > Jan 20 14:33:49 lbtest1 haproxy[25582]: :34456 > [20/Jan/2010:14:33:47.826] LDAPFarm LDAPFarm/dp2 0/0/1227 202 -- > 29/29/29/13/0 0/0 (...) > Is actconn across all pools (eg: all listen stanzas)? yes. > So it's equal > to the number of connections across LDAP, LDAPS, WWW, services that > I'm serving, as well as incoming requests from clients for all those > services? exactly. > Shouldn't it be equal to feconn+srvconn? So feconn for > LDAP + srvconn for LDAP + feconn for LDAPS + srvconn for LDAPS? no it's equal to the sum of all feconns. > Is feconn only for that particular listen? yes, it's the number of connections of the frontend which served the request. > So it's only for just the > LDAP, or only just the LDAPS, etc service I'm serving? If I had 10 > requests each of LDAP, LDAPS, and WWW, the actconn would be 60 (30 > total incoming requests and 30 total server connections serving those > requests) but feconn would be 10? ah no I understand the problem you have with actconn. Here, we refer to a "connection" as a connection from a client to a server through the proxy, which generally means two TCP connections (one per side), but only means one as long as the connection has not been forwarded to the server. > Is beconn total across all backends for a particular listen? no, beconn is for the backend which processes the request, regardless of the frontend which brings it there. > I'm not > sure, because the docs say "the backend" implying just one specific > backend server (in my example log entry "dp2"). But the docs later > state "includes the total number of concurrent connections active on > servers", yes, on this backend's servers, since servers belong to a backend. > implying it's across all the backend servers for a specific > listen statement. beconn includes both the number of active > connections to all (or one) backend server(s) plus all the requests > "backed-up" in haproxy that haven't yet been sent to the backend > servers, right? yes, that's it. > srvconn is only the number of actual active connections for a single > specific backend server (again in this case "dp2")? yes. If you only had one server, one backend, one frontend and one process, you'd have srvconn <= beconn <= feconn <= actconn. This is still normally the case as long as the frontend and backend are dedicated and there is no crossed traffic between multiple frontends and multiple backends. Hoping this clarifies the behaviour a bit more, Willy
act/fe/be/srv-conn explanation
I'm sending this again. I never saw it come back to me from the list and the archive at http://www.formilux.org/archives/haproxy/1001/date.html doesn't have this copy either. PH -- Forwarded message -- From: Paul Hirose Date: Wed, Jan 20, 2010 at 2:51 PM Subject: act/fe/be/srv-conn explanation To: haproxy@formilux.org I'm having a bit of difficulty interperting the act/fe/be/srv connection numbers in my option tcplog (definitions from manual appended below.) Sample entry from my logs: Jan 20 14:33:49 lbtest1 haproxy[25582]: :34456 [20/Jan/2010:14:33:47.826] LDAPFarm LDAPFarm/dp2 0/0/1227 202 -- 29/29/29/13/0 0/0 haproxy is usually only one process at a time, unless I use the unrecommended nbproc at more than 1, or I'm in the middle of a -sf/-st and there's a second process that started running and the first is still waiting to close out existing connections. actconn mentions process. Is actconn across all pools (eg: all listen stanzas)? So it's equal to the number of connections across LDAP, LDAPS, WWW, services that I'm serving, as well as incoming requests from clients for all those services? Shouldn't it be equal to feconn+srvconn? So feconn for LDAP + srvconn for LDAP + feconn for LDAPS + srvconn for LDAPS? Is feconn only for that particular listen? So it's only for just the LDAP, or only just the LDAPS, etc service I'm serving? If I had 10 requests each of LDAP, LDAPS, and WWW, the actconn would be 60 (30 total incoming requests and 30 total server connections serving those requests) but feconn would be 10? Is beconn total across all backends for a particular listen? I'm not sure, because the docs say "the backend" implying just one specific backend server (in my example log entry "dp2"). But the docs later state "includes the total number of concurrent connections active on servers", implying it's across all the backend servers for a specific listen statement. beconn includes both the number of active connections to all (or one) backend server(s) plus all the requests "backed-up" in haproxy that haven't yet been sent to the backend servers, right? srvconn is only the number of actual active connections for a single specific backend server (again in this case "dp2")? Thank you, PH - "actconn" is the total number of concurrent connections on the process when the session was logged. It it useful to detect when some per-process system limits have been reached. For instance, if actconn is close to 512 when multiple connection errors occur, chances are high that the system limits the process to use a maximum of 1024 file descriptors and that all of them are used. See section 3 "Global parameters" to find how to tune the system. - "feconn" is the total number of concurrent connections on the frontend when the session was logged. It is useful to estimate the amount of resource required to sustain high loads, and to detect when the frontend's "maxconn" has been reached. Most often when this value increases by huge jumps, it is because there is congestion on the backend servers, but sometimes it can be caused by a denial of service attack. - "beconn" is the total number of concurrent connections handled by the backend when the session was logged. It includes the total number of concurrent connections active on servers as well as the number of connections pending in queues. It is useful to estimate the amount of additional servers needed to support high loads for a given application. Most often when this value increases by huge jumps, it is because there is congestion on the backend servers, but sometimes it can be caused by a denial of service attack. - "srv_conn" is the total number of concurrent connections still active on the server when the session was logged. It can never exceed the server's configured "maxconn" parameter. If this value is very often close or equal to the server's "maxconn", it means that traffic regulation is involved a lot, meaning that either the server's maxconn value is too low, or that there aren't enough servers to process the load with an optimal response time. When only one of the server's "srv_conn" is high, it usually means that this server has some trouble causing the connections to take longer to be processed than on other servers.
act/fe/be/srv-conn explanation
I'm having a bit of difficulty interperting the act/fe/be/srv connection numbers in my option tcplog (definitions from manual appended below.) Sample entry from my logs: Jan 20 14:33:49 lbtest1 haproxy[25582]: :34456 [20/Jan/2010:14:33:47.826] LDAPFarm LDAPFarm/dp2 0/0/1227 202 -- 29/29/29/13/0 0/0 haproxy is usually only one process at a time, unless I use the unrecommended nbproc at more than 1, or I'm in the middle of a -sf/-st and there's a second process that started running and the first is still waiting to close out existing connections. actconn mentions process. Is actconn across all pools (eg: all listen stanzas)? So it's equal to the number of connections across LDAP, LDAPS, WWW, services that I'm serving, as well as incoming requests from clients for all those services? Shouldn't it be equal to feconn+srvconn? So feconn for LDAP + srvconn for LDAP + feconn for LDAPS + srvconn for LDAPS? Is feconn only for that particular listen? So it's only for just the LDAP, or only just the LDAPS, etc service I'm serving? If I had 10 requests each of LDAP, LDAPS, and WWW, the actconn would be 60 (30 total incoming requests and 30 total server connections serving those requests) but feconn would be 10? Is beconn total across all backends for a particular listen? I'm not sure, because the docs say "the backend" implying just one specific backend server (in my example log entry "dp2"). But the docs later state "includes the total number of concurrent connections active on servers", implying it's across all the backend servers for a specific listen statement. beconn includes both the number of active connections to all (or one) backend server(s) plus all the requests "backed-up" in haproxy that haven't yet been sent to the backend servers, right? srvconn is only the number of actual active connections for a single specific backend server (again in this case "dp2")? Thank you, PH - "actconn" is the total number of concurrent connections on the process when the session was logged. It it useful to detect when some per-process system limits have been reached. For instance, if actconn is close to 512 when multiple connection errors occur, chances are high that the system limits the process to use a maximum of 1024 file descriptors and that all of them are used. See section 3 "Global parameters" to find how to tune the system. - "feconn" is the total number of concurrent connections on the frontend when the session was logged. It is useful to estimate the amount of resource required to sustain high loads, and to detect when the frontend's "maxconn" has been reached. Most often when this value increases by huge jumps, it is because there is congestion on the backend servers, but sometimes it can be caused by a denial of service attack. - "beconn" is the total number of concurrent connections handled by the backend when the session was logged. It includes the total number of concurrent connections active on servers as well as the number of connections pending in queues. It is useful to estimate the amount of additional servers needed to support high loads for a given application. Most often when this value increases by huge jumps, it is because there is congestion on the backend servers, but sometimes it can be caused by a denial of service attack. - "srv_conn" is the total number of concurrent connections still active on the server when the session was logged. It can never exceed the server's configured "maxconn" parameter. If this value is very often close or equal to the server's "maxconn", it means that traffic regulation is involved a lot, meaning that either the server's maxconn value is too low, or that there aren't enough servers to process the load with an optimal response time. When only one of the server's "srv_conn" is high, it usually means that this server has some trouble causing the connections to take longer to be processed than on other servers.
