Load testing guide¶
Fairness vs. persistence¶
Many LB vservers use COOKIEINSERT (or similar) persistence, which pins a
real client session to one backend after its first response. Testing
naively with persistent cookies would only ever show one backend per
simulated user, hiding the actual load-balancing algorithm. adc-locust
runs two distinct modes to separate these concerns:
- Fairness — every simulated request clears cookies first, so each request looks like a brand-new session. This reveals the underlying LB method's real distribution (round robin, least connection, custom load, etc.), independent of persistence.
- Persistence — a simulated user's cookies are kept for its whole run, confirming that persistence actually holds (no unexpected mid-session rebalancing across backends).
Pick a longer duration and higher concurrency for vservers using
CUSTOMLOAD, since that method reacts to live appliance metrics rather
than a static rule — short bursts won't reveal real behavior.
Content-switched vservers¶
Some LB vservers have no routable address (0.0.0.0:0) and are only
reachable through a Content Switching (CS) vserver's IP with a matching
Host header and/or URL path. adc-locust automatically detects this case
using the Nitro API — searching CS vservers' default targets and bound CS
policies for one that routes to the selected LB vserver — and directs
Locust at the CS vserver instead. If no CS vserver targets it, the vserver
cannot be load tested and adc-locust reports that clearly rather than
silently sending requests nowhere useful.
Measuring actual balance¶
HTTP responses generally don't reveal which backend served a request.
adc-locust snapshots each bound service's Nitro service_stats
totalrequests counter immediately before and after a Locust run, then
reports the delta per service. A service receiving far less than its
expected even share of new traffic is flagged as a warning — useful for
spotting misconfigured weights, disabled services that still show as
bound, or an LB method not behaving as configured.
This read-only stats comparison is the same approach used in earlier
ad-hoc distribution_check.py scripts, now built into the TUI so no
separate script or manual before/after snapshotting is required.