Public bug reported: Both the reference Octavia driver and the namespace driver use haproxy to deliver load balancing services with LBaaSv2. When closely looking at the operation of the haproxy daemons with a utility like hatop ( https://github.com/feurix/hatop ), one can see that the connection limit for back-ends is exactly 10% of whatever the connection limit is set for the pool's listener front-ends. This behavior could cause an unexpectedly low effective connection limit if the user has a small number of back-end servers in the pool.
>From the haproxy documentation, this is because the default value of a backend's "fullconn" parameter is set to 10% of the sum of all front- ends referencing it. Specifically: "Since it's hard to get this value right, haproxy automatically sets it to 10% of the sum of the maxconns of all frontends that may branch to this backend (based on "use_backend" and "default_backend" rules). That way it's safe to leave it unset." (Source: https://cbonte.github.io/haproxy- dconv/configuration-1.6.html#fullconn ) The point of this calculation (according to the haproxy documentation) is to protect fragile back-end servers from spikes in load that might reach the front-ends' connection limits. However, for long-lasting but low-load connections to a small number of back-end servers through the load balancer, this means that the haproxy-based back-ends have an effective connection limit that is much smaller than what the user expects it to be. ** Affects: neutron Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1622793 Title: LBaaS back-end pool connection limit is 10% of listener connection limit for reference and namespace drivers Status in neutron: New Bug description: Both the reference Octavia driver and the namespace driver use haproxy to deliver load balancing services with LBaaSv2. When closely looking at the operation of the haproxy daemons with a utility like hatop ( https://github.com/feurix/hatop ), one can see that the connection limit for back-ends is exactly 10% of whatever the connection limit is set for the pool's listener front-ends. This behavior could cause an unexpectedly low effective connection limit if the user has a small number of back-end servers in the pool. From the haproxy documentation, this is because the default value of a backend's "fullconn" parameter is set to 10% of the sum of all front- ends referencing it. Specifically: "Since it's hard to get this value right, haproxy automatically sets it to 10% of the sum of the maxconns of all frontends that may branch to this backend (based on "use_backend" and "default_backend" rules). That way it's safe to leave it unset." (Source: https://cbonte.github.io/haproxy- dconv/configuration-1.6.html#fullconn ) The point of this calculation (according to the haproxy documentation) is to protect fragile back-end servers from spikes in load that might reach the front-ends' connection limits. However, for long-lasting but low-load connections to a small number of back-end servers through the load balancer, this means that the haproxy-based back-ends have an effective connection limit that is much smaller than what the user expects it to be. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1622793/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
