Traffic is not distributed evenly across the servers; how do I investigate?

Short answer

First, the distribution is measured: Current Sessions and HTTP Request/s per Backend Service in the Backend Services table in Live Stats, and Backend Request Distribution in the Backend tab of the Dashboard, are compared over time; the counts on the Backend service card in HTTP Logs give a sample of requests. Then the LB Algorithm and Persistence setting of the vService and the Weight, Connection Limit, Maintenance Mode and Backup Service settings of the Backend Services are read. The imbalance is mostly the expected result of a setting: the default Round Robin algorithm does not use Weight; a weighted or dynamic algorithm, Persistence, users coming from behind NAT or long-lived connections also change the distribution. In a cluster, each device shows only its own traffic.

Problem: One Server Receives More Load Than the Others

One of the Backend Services receives far more or far fewer requests than the others. It must be determined whether the imbalance is caused by a failure or is the expected result of the algorithm, Weight or Persistence setting.

Where Is It Monitored?

Screen	Path	What it shows
Live Stats → Backend Services	Load Balancer vServices → vService → Live Stats	Instant Current Sessions, HTTP Request/s, Avg. response time, the weight suffix (W=) and the status strip
Dashboard → Backend	vService → Dashboard	Backend Request Distribution (HTTP only), Backend Current Sessions Distribution, Backend Connections Distribution
HTTP Logs → Filter	vService → Logs & Tracking	The distribution of Backend service and Client IP in the fetched records
Load Balancer Management → LB Algorithm	vService → Load Balancer Management	A summary of the algorithm and Persistence setting as a sentence

Solution: Three Methods

The three methods are applied in order: first the distribution is measured, then the request sample is examined, and last the configuration is read and the finding is matched to the cause.

Your situation	Suitable method
Measuring the distribution	Method 1: Live Stats and Dashboard
Request sample and client concentration	Method 2: HTTP Logs
Matching the cause	Method 3: Configuration

Method 1: Live Stats and Dashboard Recommended

• How it worksLive Stats shows the instant distribution, and Dashboard shows the distribution over time.
• Where it is opened Load Balancer vServices → vService → Live Stats · Dashboard → Backend
• Requirement No additional setting is required.
• vService type HTTP · L7 TCP · Network

Step-by-Step Configuration

1

Adım 1 Open Live Stats

In the Left Monitor Panel → Load Balancer vServices → vService → Live Stats tab, the Backend Services table is checked: the status strip of each Backend Service, Current Sessions, HTTP Request/s (New Connection/s on L7 TCP), Avg. Response Time and the weight suffix (W=) next to the name are seen. In a cluster, each device shows only its own traffic; the values are not summed.

2

Adım 2 Compare over time

In the Backend view of the Dashboard tab, the Backend Request Distribution (HTTP only), Backend Current Sessions Distribution and Backend Connections Distribution panels are checked.

Verification

1DistributionTR7 side

The ratios per Backend Service are read on the panels.

ExpectedHow much load each server receives is seen in numbers

Method 2: HTTP Logs

• How it works The Backend service and Client IP cards in the HTTP Logs filter strip show the server distribution in the fetched records and whether a small number of clients dominate.
• Where it is opened Load Balancer vServices → vService → Logs & Tracking → HTTP Logs
• RequirementLog Profile must be on in the vService.
• vService type HTTP

Step-by-Step Configuration

1

Adım 1 Increase the record count

On the Logs & Tracking → HTTP Logs screen, Line Limit (default 1000) is increased and the Refresh button is clicked; the counts on the cards are based only on the fetched records.

2

Adım 2 Check the cards

In the Filter panel, the counts on the Backend Service card give the server distribution. If a few addresses dominate the Client IP card, users behind NAT may be gathering on a single server (All users coming from behind a corporate NAT go to a single server; why?).

Verification

1CardsTR7 side

The Backend service and Client IP cards in the filter strip are checked.

ExpectedRecord counts per server and per client

Method 3: Configuration

• How it works The settings that determine the distribution are read, and the finding is matched to the cause.
• Where it is opened vService form · Load Balancer → Backend Services
• Requirement No additional setting is required.
• vService type HTTP · L7 TCP · Network

Step-by-Step Configuration

1

Adım 1 Read the settings

The LB Algorithm, the Persistence type and durations, and the Hash Consistency settings of the vService; the Weight, Connection Limit, Maintenance Mode and Backup Service settings of the Backend Services; and the Conditional Backend Services blocks are read. The algorithm and Persistence are also seen as a sentence on the Load Balancer Management screen (LB Algorithm).

2

Adım 2 Match the cause

Finding	Cause
The Weights differ but the distribution is equal	Round Robin does not use Weight: What is the difference between Round Robin and Weighted Round Robin?
The ratio matches the Weight ratio	Expected result: How do I distribute load proportionally across servers with different capacities?
Sessions accumulate on one server, the request rates are close	Long-lived connections: When is Least Connection better than Round Robin?
A new server receives little traffic	Persistence pins the existing users: Persistence is causing uneven load distribution; what can I do?
One server receives no traffic at all, yellow strip	What does Maintenance Mode do?
One server receives no traffic at all, the others are up	What is a Backup Service; when does it take over, and when does it step back?
One server is at its limit, the others carry excess load	What is Connection Limit; what happens to new requests when the limit is reached?
The first server fills up first	What is the First algorithm used for?
The hash algorithm overloads a single server	Low value diversity: What does the Hash Consistency option do in hash-based algorithms?
The distribution is split according to the condition blocks	What is the difference between Conditional Backend Services and Default Backend Services?

All the causes: Why is traffic not distributed evenly across the servers?

Verification

1DistributionTR7 side

After the setting change, the Backend Request Distribution panel on the Dashboard is monitored.

ExpectedThe ratios approach the expected distribution

If cookie-based Persistence is on, the existing sessions stay on the old server (with Hash persistence, the mapping table is reset on every reload); the new distribution is seen over time with new sessions.

Common Mistakes

• Taking the screen of a single device in a cluster as all the traffic. Each device shows its own traffic.
• Drawing conclusions about the past from Live Stats. Live Stats shows only the instant state and does not store data; the past distribution is read from the Dashboard; details are in the Scope and Limits section in the docs.
• Deriving an exact ratio from a log sample of a few hundred lines. The distribution over time is read from the Dashboard.
• Assigning Weight and leaving the algorithm as Round Robin. For Weight to take effect, Weighted Round Robin or another algorithm that uses Weight is selected.

How it is done in the documentation

• Live Stats · Backend Services
• Dashboard · Backend Request Distribution
• Load Balancer Management · LB Algorithm
• Backend Services · Weight

Related questions

• Why is traffic not distributed evenly across the servers?
• Persistence is causing uneven load distribution; what can I do?
• All users coming from behind a corporate NAT go to a single server; why?