Checkout Pool: Round Robin on Wildly Unequal Hardware, No Persistence

The measurements are the diagnosis: two members with 4x the CPU are half idle while an 8-vCPU member sits at 98%. Round Robin hands every new connection out equally, so the 8:1 capacity ratio is simply ignored.

What to change:

• Set the Load Balancing Method to Ratio (member) with member ratios 4 / 4 / 1 / 1, matching 32 : 32 : 8 : 8 vCPU.
• If the members expose SNMP or a performance monitor, Dynamic Ratio (member) is better still because it tracks reality instead of a hand-written ratio. Ratio is the safe 20-minute choice: no external dependency, no monitoring to tune.
• Priority Group Activation is currently meaningless. All four members are in one priority group, so 'Less than 2 available' can never fire. Either remove it or make it real: web-01/web-02 as priority 1, legacy-01/02 as priority 2 with 'Less than 1 available', if legacy capacity is only overflow.

Why not Least Connections: with OneConnect and HTTP keep-alive enabled, connection counts no longer measure work in flight. A handful of multiplexed server-side connections can carry thousands of requests, so 'fewest connections' is close to noise. Worse, a slow member's connection count can drop precisely because it is finishing a batch of slow requests, and Least Connections then rewards it with more traffic.

Root cause: with no persistence profile, any member can serve the next request, so a cart held in node-local memory disappears the moment the next request lands elsewhere. Note that the app's own JSESSIONID cookie is opaque to the BIG-IP: cookie persistence in passive mode can only read a cookie the BIG-IP itself wrote, so naming a profile 'JSESSIONID' does nothing on its own.

Two workable designs:

1. Cookie persistence, Insert mode. BIG-IP injects its own cookie whose value maps to the member, so affinity follows the browser. Set Expiration to a specific interval slightly longer than the app's session timeout rather than 'session cookie'. Best default: nothing in the app has to change.
2. Universal persistence keyed on the app cookie, via iRule: on HTTP_RESPONSE, persist uie [HTTP::cookie "JSESSIONID"]; on HTTP_REQUEST, persist uie. The value is hashed to a member, so the same cookie always lands on the same node without BIG-IP needing to decode it. Choose this only if the app never regenerates JSESSIONID mid-session, because a new value hashes to a different member and drops the cart.

What still breaks: persistence is not replication. When legacy-01 goes down, every entry pointing at it is invalidated, the request is load balanced to a healthy member, and the in-memory cart is gone. The only mitigations are operational (disable the member with connection drain before maintenance, warn users) or architectural (shared session store) - both outside this window.

Raising the idle timeout does not address either failure. The cart is lost because the affinity key (source address, with the built-in Source Address profile) does not follow the user, and because node-local state cannot survive a member going down. A longer timeout only means a user stays pinned to the same - possibly wrong - member for longer, and it delays the moment when a client behind a shared NAT address picks up a recycled session belonging to someone else.

What a longer timeout does buy you is fewer mid-session re-mappings when a client's public IP changes (mobile handover, dual-stack roaming). That is a real but small effect, and cookie-based persistence solves it properly because the cookie travels with the browser across IP changes.

If you must choose one action in this window, attach cookie persistence first. If you have room for a second, keep the source-address profile as a lower-precedence fallback for clients that reject cookies. Treat the timeout as a tuning parameter to revisit after you see the actual session duration distribution, not as the fix.