Can I send only a certain percentage of traffic to a new version?
Short answer
Yes. For a permanent share, Weight is given to the Backend Services of the new and old versions and Weighted Round Robin is selected in the LB Algorithm field of the vService; the share of the new version is the ratio of its own Weight value to the total Weight. For a random percentage per request, a Dynamic Condition condition that uses the Random Number variable is bound to a Conditional Backend Services (Content Switching) block. To send only a copy without affecting the user, the Sampling Percentage (%) field of the Traffic Mirroring action is used.
Problem: The New Version Must Be Tried with a Small Share of the Traffic
The new version is wanted to run first with a specific percentage of the traffic so that the risk stays limited. Whether the share is applied as a permanent distribution ratio, as a decision made anew on every request, or as a copy that never touches the user varies according to the need.
Solution: Three Methods
The three methods are alternatives to each other; Methods 1 and 2 send real user traffic to the new version, and Method 3 sends only a copy.
| Your situation | Suitable method |
|---|---|
| I want a fixed ratio; the same user should be able to always go to the same version | Method 1: Weight + Weighted Round Robin |
| I want a random percentage that is decided anew on every request | Method 2: Dynamic condition + Random number |
| Users should not be affected; the new version should receive only copied traffic | Method 3: Traffic Mirroring Sampling Percentage |
Method 1: Weight + Weighted Round Robin Recommended
- How it works Each Backend Service receives requests in proportion to the ratio of its Weight value to the total Weight. Example: old version 90, new version 10 → the new version receives 10% of the requests.
- Where it is openedLoad Balancer → Backend Services → Weight · vService → LB Algorithm
- Requirement Both versions in the Default Backend Services list of the vService; LB algorithm = Weighted Round Robin
- vService type HTTP · L7 TCP (on the Network vService, the equivalent is Weighted Round-Robin)
Step-by-Step Configuration
If the new version is not yet defined in TR7 as a Backend Service, the Add button is clicked on the Load Balancer → Backend Services screen; the add form opens. If the new version is already defined, the procedure continues from Step 4.
The Backend Service Name and Address (the IP address or domain name and the port of the new version server) are entered. The Details switch at the bottom of the form is turned on (off by default), and the value that determines the share is written in the Weight field (e.g. 10; range 1–256, 1 is applied while the field is empty). For it to be detected that the server has gone down, a profile is selected in the Health Check field; the default is No check. Details: How is a Backend Service added; which information is required?
The Add button at the bottom of the form is clicked.
The Backend Service of the old version is selected in the list and opened with Edit; the Details switch is turned on and the remaining share is written in the Weight field (e.g. 90). If the servers are in a Backend Group, the same field is found in the server rows of the group; details: Backend Groups · Server-Level Weights.
The Edit button at the bottom of the form is clicked.
On the Load Balancer → Load Balancer vService List screen, the vService is selected and the edit form is opened.
It is checked that the Backend Services of the old and new versions are in the Default Backend Services list; if not, they are added.
In the LB Algorithm field in the Details panel, Weighted Round Robin is selected. The default Round Robin does not take Weight values into account.
If the same user is wanted to always go to the same version, New cookie is selected in the Persistence field. This option exists only on the HTTP vService.
The Save button is clicked. In a cluster, the change is transferred to the peer device automatically with auto-sync (default); if Manual Sync Mode is on, it is sent with Synchronize.
Verification
On the Left Monitor Panel → Load Balancer vServices → vService → Logs & Tracking → HTTP Logs screen, the distribution of the requests in the Backend Service column is examined. For HTTP Logs, a log profile must have been assigned to the vService (how to enable HTTP Logs). On the L7 TCP vService, which Backend Service the connections went to is seen on the vService Sessions screen.
New version ≈ 10% · old version ≈ 90%Method 2: Dynamic Condition + Random Number
- How it works On every request, a number between 0 and one less than the Random max. value is generated; if the number is below the threshold, the request goes to the new version in the Conditional Backend Services block. Random max. = 100 and threshold 10 → 10% of the requests.
- Where it is openedLoad Balancer → Conditions → Dynamic Condition · vService → Conditional Backend Services
- Requirement The Backend Service of the new version is defined
- vService type HTTP · L7 TCP
Step-by-Step Configuration
If the new version is not yet defined in TR7 as a Backend Service, the Backend Service Name and Address are entered with Load Balancer → Backend Services → Add and saved with Add (How is a Backend Service added; which information is required?). If multiple servers are to be managed as a single target, a Backend Group is created on the Load Balancer → Backend Groups screen.
On the Load Balancer → Conditions screen, the Add button is clicked (how to add).
The Add button at the bottom of the form is clicked.
On the Load Balancer → Load Balancer vService List screen, the vService is selected and the edit form is opened.
A new block is added with + Conditional backend services; in the condition field of the block, the condition created in Step 3 is selected, and in the Backend Services field, the Backend Service (or Backend Group) of the new version is selected. If this block needs to be evaluated before the other blocks, if any, it is dragged to the top (How do I change the evaluation order of Conditional Backend Services blocks?).
The Save button is clicked. Requests that do not meet the condition (90%) go to the old version in the Default Backend Services list. In a cluster, the change is transferred to the peer device with auto-sync (default); if Manual Sync Mode is on, it is sent with Synchronize.
Verification
The distribution of the requests in the Backend Service column is checked on the HTTP Logs screen; on the L7 TCP vService, the same information is on the vService Sessions screen.
≈ 10% of the requests from the Backend Service of the blockMethod 3: Traffic Mirroring Sampling Percentage
- How it works A copy of the selected percentage of the requests is sent to the new version; the user always receives the response from the actual Backend Service, and the response of the copy is discarded.
- Where it is openedLoad Balancer → Actions → Traffic Mirroring → Sampling
- Requirement A single Backend Service to which the copy will be sent; a Backend Group cannot be selected
- vService type HTTP
Step-by-Step Configuration
If the new version to which the copy will be sent is not yet defined in TR7 as a Backend Service, the Backend Service Name and Address are entered with Load Balancer → Backend Services → Add and saved with Add (How is a Backend Service added; which information is required?).
On the Load Balancer → Actions screen, the Add button is clicked.
Action Type = Traffic Mirroring is selected; in the Mirror Target Service field (required), the Backend Service of the new version is selected. The target Backend Service must have its own IP address and port defined in its Address field; no copy is sent to a Backend Service with Use Frontend Port selected.
The Sampling switch is turned on (off by default) and the Sampling Percentage (%) is entered (default 10, range 0–100).
The Add button at the bottom of the form is clicked.
On the Load Balancer → Load Balancer vService List screen, the vService is selected and the edit form is opened; the action is added to the Actions field in the Details panel. Creating the action alone is not enough.
The vService is saved with Save.
Verification
The Mirrored/s, Skipped/s and Dropped/s values in the Traffic Mirroring section of the Live Stats screen of the vService are checked; for the past flow, the Mirror Flow chart in the Traffic Mirroring tab of the Dashboard is checked (monitoring the mirroring).
Mirrored/s > 0Common Mistakes
- Expecting Weight to apply with the default Round Robin. Round Robin does not take Weight values into account; for a ratio, LB algorithm = Weighted Round Robin is selected.
- Using the Random number split in session-based applications. Since the decision is made anew on every request, the requests of the same user are distributed between the two versions; in a session-based application, Method 1 and New cookie persistence are used.
- Mistaking mirroring for real routing. Traffic Mirroring only sends a copy; the user does not see the response of the new version.
- Configuring the peer device separately in a cluster. While auto-sync (default) is on, the configuration is done on a single device and passes to the peer device on its own; Synchronize is needed only while Manual Sync Mode is on.
How it is done in the documentation
