nic-6443 opened a new pull request, #14188: URL: https://github.com/apache/apisix/pull/14188
Slow start currently lets a node pick up where it left off if it was unavailable for less than `slow_start_time_seconds`: a node a health check took out of the picker kept its ramp clock running (or stayed mature), and a node removed from the node set was tombstoned for one window so a re-add resumed its ramp. In practice that's the wrong way round. A backend restart takes seconds to tens of seconds while the window is usually minutes, so the freshly started, cold process comes straight back at full weight, which is exactly what slow start is supposed to prevent. This changes it so any observed unavailability ends the node's ramp or maturity, and when the node is available again it ramps from scratch from that moment, however short the outage was. That's also how nginx `slow_start`, HAProxy `slowstart` and Envoy's slow start behave. No new config field. The two signals are the ones already tracked: - Excluded from the eligible set by health checks: a node with state (mid-ramp or mature) that a reconcile finds out of the picker is moved to "waiting for a picker", and its next picker starts a new window. The separate `|i` ineligible-since marker is gone; the waiting state is stored as the negated time it was first found out, which keeps each interruption's value unique so the existing `add`-keyed election in `replace_start` still works when a node flaps. - Absent from the configured node set at a reconcile: its state is dropped instead of tombstoned, so a re-add ramps. Inside `startup_grace_period_seconds` the state is kept as "waiting" until the grace period ends, because the grace only covers nodes seen for the first time; a node seen, removed and re-added during start-up ramps too, matching the health check path. Unchanged: node identity (host or domain : port), weight changes including `weight: 0`, the first-reconcile baseline, HUP reload, the all-unhealthy fail-open (the whole set stays eligible, so nothing is interrupted), roundrobin only. A removal and re-add that both fall between two picker rebuilds is still invisible, since reconcile is request-driven. One edge worth calling out: a node that has no state yet and is already excluded by a health check at the reconcile that first sees it is now stored as waiting rather than mature, even on the baseline or inside the grace period, so it ramps once it becomes healthy. New health check targets start healthy, so this only happens when the node was actually observed down. Tests: TEST 5 encoded the old resume-within-window behaviour and now checks that a mid-ramp node removed and re-added inside the window ramps from the first bucket again (black-box through the Admin API). New TEST 12-14 cover a mature and a mid-ramp node going unhealthy and back, a mature and a mid-ramp node removed and re-added, and removal/re-add plus unhealthy/back inside the startup grace period. All of them fail on master. The Admin API docs (en/zh) are updated accordingly. Counterpart: the same change is being made in a downstream fork of this module, with identical code. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
