yahoo-eng-team team mailing list archive

[Stephen Balukoff <stephen@xxxxxxxxxxxx>]

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