From: Frederic Lecaille Date: Thu, 20 Aug 2026 13:53:58 +0000 (+0200) Subject: MINOR: haload: add -ee to probe and ramp back up after an error X-Git-Tag: v3.5-dev6~85 X-Git-Url: https://git.kaiwu.me/?a=commitdiff_plain;h=b24013000c9c1b4b2ac3b42eb177c6844211547d;p=haproxy.git MINOR: haload: add -ee to probe and ramp back up after an error -e stops the whole run on the first error. -ee is a softer variant: on the first error, it resets all counters and drops to 1 conn/req per second per URL, then doubles that rate every second, as long as requests keep succeeding, until 100 successes per URL have been seen. It then resumes the load asked for on the command line (uncapped, or the original -R value if one was given). The floor and target are expressed per URL, not per thread: with a per-thread scaling, a machine with many threads would start the probe far from gently. The doubling isn't capped at the original -R value on the way up either; only the success count ends the ramp. It never speeds up while the target is still failing, and reacts immediately to the first sign of recovery rather than waiting for the next scheduled check. A later, separate outage can trigger -ee again once a previous ramp has completed. A connection error means the affected user has no connection left anyway, so it is killed rather than rescheduled for a retry. This lets hld_rate_task() take over and create its replacement under the current ramp rate, rechecking every 100ms instead of trusting a single, possibly stale, wait time computed by hld_usr_schedule() (which, with a large -u and a low rate, could grow to several minutes and would never be reconsidered even as -ee doubles the rate afterwards). For this to work: - hld_rate_task() is now created for every thread whenever -ee is used, even without -R (it otherwise only exists if -R is set, so -ee alone would have nothing to recreate users with). - it no longer destroys itself once the target concurrency is reached; under -ee it stays alive, idle, so it can be woken up later to refill after a kill. It still checks all_usr_stop_asap and destroys itself for good once set, so an idle task never prevents the process from exiting cleanly at the end of a test. - once the main task's own initial ramp-up is over (usr_cnt >= arg_usr), a rate of 0 (no limit) is treated as "fill directly", not "zero budget": otherwise, once -ee hands the rate back to 0 after a successful probe, nothing could ever refill a later kill. - hld_usr_release() keeps the per-thread live user count accurate and wakes the rate task after a kill. Each user also remembers the -ee generation it was created in. Only successes from users created during the current ramp count towards the 100 needed to end it: a pre-existing user that was never affected by the error succeeding again does not mean the probe itself worked, and counting it would let a few leftover in-flight requests, or an unrelated majority of still-healthy users, satisfy the target almost instantly while the target is still actually down. --- diff --git a/doc/haload.txt b/doc/haload.txt index 99e8a8a39..d217c8890 100644 --- a/doc/haload.txt +++ b/doc/haload.txt @@ -58,6 +58,10 @@ HALoad displays its usage when run without argument or wrong arguments: where may be any combination of: -d