Persistence is causing uneven load distribution; what can I do?

Short answer

Since Persistence keeps users on the Backend Service they were first assigned to, the load can become unbalanced over time: a newly added server receives only new users, and users with long sessions accumulate on the old servers. If SAM is used, part of the sessions on the busy servers is cleared with Rebalance. In addition, the right algorithm and Weight are selected for the distribution of new sessions, the persistence durations are shortened, the Hash key is diversified; if the application is stateless, persistence is removed (None).

Problem: Pinned Sessions Accumulate

While persistence is on, the load balancing decision is made only for new users. When a server returns from maintenance, when a new server is added, or when some users' sessions last very long, the existing sessions stay where they are. Users coming from behind a NAT or keys with low diversity can also gather on a single server.

Diagnosis First

• SAM tab: The session percentage and count of each Backend Service are seen; if Weight is greater than 1, the Weight=N label appears on the bar.
• Dashboard: The Backend Current Sessions Distribution and Backend Queue Distribution charts are examined.

Solution: Five Methods

Your situation	Suitable method
SAM is used; redistributing the existing sessions	Method 1: SAM Rebalance
New sessions are also distributed unevenly	Method 2: Algorithm and Weight
Sessions stay pinned longer than necessary	Method 3: Shortening the durations
Many users gather on a single key (NAT, fixed header)	Method 4: Diversifying the key
The application does not keep the session on the server	Method 5: Removing persistence

Method 1: SAM Rebalance Recommended

• How it works The specified percentage of the session records bound to the selected servers is deleted; these users are reassigned according to the algorithm on their next request.
• Where it is opened vService screen → Session Affinity Manager (SAM) tab → Rebalance
• Requirement Persistence = SAM; at least two Backend Services in the list
• vService type HTTP

Step-by-Step Configuration

1

Adım 1 Open the tab

The vService's management screen is opened and the Session Affinity Manager (SAM) tab is selected (tabs); the tab appears only when Persistence is SAM.

2

Adım 2 Open the Rebalance form

Rebalance in the header of the list where the busy servers are (Default Backend Services or a conditional set) is clicked; the Rebalance Sessions form opens.

3

Adım 3 Select the servers and the percentage

In the Backends field, only the busy servers are checked, and Percent (1–100, default 100) is lowered to a low value (e.g. 30). In the Selection field, which appears while Percent is below 100, the selector is determined (e.g. Oldest (By expiry) selects the sessions closest to expiring).

4

Adım 4 Submit with Accept

The Accept button at the bottom of the form is clicked.

5

Adım 5 Confirm

In the Rebalance Sessions? window, the approximate number of sessions to be cleared is checked and confirmed. Open connections are not cut; users are reassigned on their next request.

Verification

1Session distributionSAM tab

After the operation, the tab is refreshed; the session percentage of the busy server drops.

ExpectedThe session percentages get closer to each other

Method 2: Algorithm and Weight

• How it works Persistence takes effect only after the first assignment; the first assignment is made by the algorithm. The right algorithm and Weight ensure that new sessions are distributed evenly.
• Where it is opened vService → Edit → Details → LB Algorithm; Backend Service → Edit → Details → Weight
• Requirement None
• vService type HTTP, L7 TCP

Step-by-Step Configuration

1

Adım 1 Open the vService edit form

On the Load Balancer → Load Balancer vService List screen, the vService is selected and Edit is clicked.

2

Adım 2 Select the algorithm

In the Details → LB Algorithm box, the default Round Robin ignores Weight. If the server capacities differ, Weighted Round Robin is selected; if the session durations differ greatly, Least Connection is selected.

3

Adım 3 Save with Save

The Save button in the vService form is clicked.

4

Adım 4 Open the Backend Service edit form

On the Load Balancer → Backend Services screen, the Backend Service is selected and Edit is clicked.

5

Adım 5 Enter the Weight

A Weight proportional to the capacity (1–256, default 1) is entered.

6

Adım 6 Save with Edit

The Edit button at the bottom of the form is clicked; steps 4–6 are repeated for the other Backend Services. The existing pinnings stay where they are until their durations expire or a Rebalance is performed.

Verification

1DistributionTR7 side

The Backend Current Sessions Distribution chart on the vService Dashboard is monitored.

ExpectedSessions are distributed more evenly across the servers

Method 3: Shortening the Durations

• How it works Persistence records end sooner; users are redistributed more often.
• Where it is opened vService → Details → LB Algorithm box → Persistence fields
• Requirement The durations must not be shorter than the application's session duration
• vService type HTTP, L7 TCP

Step-by-Step Configuration

1

Adım 1 Open the vService edit form

On the Load Balancer → Load Balancer vService List screen, the vService is selected and Edit is clicked.

2

Adım 2 Set the duration according to the method

In the Persistence fields in the Details → LB Algorithm box: New cookie: Cookie max-idle (default 30 min) and Cookie max-life (default 8 hours) · SAM: Max idle (default 30 min) and Max life (default 24 hours) · Hash: Hash Key Expire Time (default 7 days). The durations are lowered so that they are not shorter than the application's own session duration. In SAM, this change does not reset the session table.

3

Adım 3 Save

Save is clicked.

Verification

1DistributionTR7 side

The Backend Current Sessions Distribution chart on the vService Dashboard is monitored.

ExpectedSessions are distributed more evenly across the servers

Method 4: Diversifying the Key

• How it works If the Hash key or the SAM session ID produces a small number of distinct values, many users gather in a single record; a user-specific value prevents this pile-up.
• Where it is opened vService → Persistence → Hash Key or SAM → Session ID Format
• Requirement A user-specific value must be present in the request
• vService type HTTP, L7 TCP

Step-by-Step Configuration

1

Adım 1 Open the vService edit form

On the Load Balancer → Load Balancer vService List screen, the vService is selected and Edit is clicked.

2

Adım 2 Change the Hash key

In Hash persistence, if the key is the client IP address (behind a NAT), a Smart Variable that gives a user-specific header or cookie value is added to the Hash Key list.

3

Adım 3 Change the SAM ID

In SAM, if Custom Format is used, the keys are enriched with user-specific values, or a switch is made to the UUID format. A Session ID Format change resets the SAM table.

4

Adım 4 Save

Save is clicked.

Verification

1DistributionTR7 side

The Backend Current Sessions Distribution chart on the vService Dashboard is monitored.

ExpectedSessions are distributed more evenly across the servers

Method 5: Removing Persistence

• How it works If the application keeps the session in a shared store (Redis, database) or in a token, persistence is unnecessary; when it is removed, each request is distributed according to the algorithm.
• Where it is opened vService → Details → LB Algorithm box → Persistence → None
• Requirement The application must be stateless
• vService type HTTP, L7 TCP

Step-by-Step Configuration

1

Adım 1 Check

It is confirmed with the application team that the session is not kept locally on the server.

2

Adım 2 Open the vService edit form

On the Load Balancer → Load Balancer vService List screen, the vService is selected and Edit is clicked.

3

Adım 3 Select None

None is selected in the Persistence field in the Details → LB Algorithm box; docs also recommends not using persistence in stateless applications (best practices).

4

Adım 4 Save

Save is clicked.

Verification

1DistributionTR7 side

The Backend Current Sessions Distribution chart on the vService Dashboard is monitored.

ExpectedSessions are distributed more evenly across the servers

Common Mistakes

• Thinking that Rebalance moves sessions. Rebalance deletes the records; the new server is selected by the algorithm.
• Selecting all servers with Percent 100. All the sessions of the list are cleared; for gradual balancing, the busy servers and a low percentage are selected.
• Trying to balance with Reload. Reload in the vService menu restarts the service; it is not controlled.
• Trying to solve it with a connection limit. Connection Limit does not move sessions; it only stops the service that has reached its limit from taking new connections, and on HTTP and L7 TCP, if all services are at their limit, the request waits in the queue for the Queue Timeout duration and then 503 is returned.

How it is done in the documentation

• HTTP (L7) vService · Rebalance
• HTTP (L7) vService · Session Persistence
• Dashboard · Backend Current Sessions Distribution

Related questions

• What do Rebalance and Clear All do on the Session Affinity Manager (SAM) tab?
• Can sessions be rebalanced when servers are added or removed?
• Why is traffic not distributed evenly across the servers?