Stress testing methods for NLB-Server Load Balancer(SLB)-阿里云帮助中心

Stress testing NLB requires selecting the right framework, connection strategy, and tool for each performance metric. Without the correct setup, TIME_WAIT port exhaustion, session conflicts, and health check overhead can all produce misleading low scores. This document covers two testing frameworks, metric-specific connection strategies, pre-test configuration checklist, and a guide to diagnosing common causes of low scores.

Stress testing frameworks

Use Alibaba Cloud Performance Testing Service (PTS). PTS lets you set a high level of concurrency and allocates public IP addresses from various locations to ensure that the traffic source is distributed. You can also integrate Cloud Monitor with PTS to view end-to-end performance data in real time.
Do not use Apache ab as a stress testing tool. In high-concurrency scenarios, Apache ab experiences staggered pauses at 3-, 6-, and 9-second intervals. Apache ab determines whether a request is successful by checking the content length. If multiple backend servers are attached to an ALB instance, the content length of responses may be inconsistent, which leads to incorrect test results.

NLB stress tests use one of two topology frameworks.

Standard stress testing framework

Single-VIP stress testing framework

Use the standard framework in most scenarios. Use the single-VIP framework only when client IP preservation is enabled or when the standard framework produces session conflicts on backend servers. For details, see Stress testing methods and Low stress test scores.

Simple stress test example with PTS

This example walks you through a basic stress test setup with an NLB instance.

Environment setup

Create an NLB instance with the following configuration:

Component	Configuration
Listeners	TCP on port 80 and TCP/SSL on port 443
Backend servers	Two ECS instances per listener, backend port set to 80
ECS specifications	2 vCPUs, 2 GiB memory, CentOS 7.9 64-bit

Install the web service

Log on to each of the two ECS instances and run the following steps to set up a web service. For more information about how to connect to an ECS instance, see ECS remote connection guide.

Install Apache Web Server:
```
sudo yum install -y httpd
```

Create a default homepage:

echo "testvm" | sudo tee /var/www/html/index.html

Start the HTTP service:
```
sudo systemctl start httpd
```
Verify that the web service is running on port 80:
```
curl http://localhost
```
Alternatively, run the following command:
```
curl http://127.0.0.1:80
```
Create a test scenario in PTS and start the stress test. For more information, see Start a stress test in one minute.

Stress testing methods

NLB measures performance across three independent metrics. Each requires a different connection strategy.

Metric	Connection type	Key consideration
New connections	Short-lived connections	Use a heartbeat service with a simple mechanism to avoid high bandwidth consumption. Make sure the NLB instance has enough frontend ports for clients.
Concurrent connections	Persistent connections	Each persistent connection should use a heartbeat service with a simple mechanism to maintain session persistence. Make sure the NLB instance has enough frontend ports for clients.
Forwarding capacity	Persistent connections	Suitable for bandwidth limit tests and specific service tests.

Setting the timeout period

Set the timeout period on the stress testing tool to an appropriate value, such as 5 seconds.

A large timeout period increases average response time, making it difficult to determine whether the NLB instance can withstand the load.
A small timeout period lets you judge the result based on the request success rate shown in test output.

Before you run a stress test

The following configurations are intended for stress testing only. Revert them in your production environment after testing.

Apply these settings before running a stress test to get accurate, reproducible results.

Listener configuration

Associate at least five elastic IP addresses (EIPs) with the NLB instance if it supports up to 5,000 concurrent connections.

Server group configuration

Disable consistent hashing based on source addresses. This algorithm concentrates requests on a single backend server, skewing results. If session persistence is required, use Four-Element Hashing (source IP address, destination IP address, source port, and destination port) to widen the hash distribution. For more information about scheduling algorithms, see SLB scheduling algorithms.
Disable health checks. Health check traffic inflates the request count sent to backend servers and reduces test accuracy.
Use the single-VIP framework if client IP preservation is enabled. The standard framework increases the chance of session conflicts on backend servers when the client count is small or consistent hashing by source IP is used.
Add enough backend servers when client IP preservation is disabled. When client IP preservation is disabled, the NLB instance uses its own IP address to connect to backend servers. Because the system allocates only a limited number of source IP addresses per NLB instance, too few backend servers cap the maximum concurrent connections.

Stress testing tools

Avoid using Apache Bench (ab) for stress tests. In high-concurrency scenarios, Apache Bench increases wait time in 3-second increments (3 s, 6 s, 9 s). It also evaluates success based on a specified content length — when multiple backend servers return responses of different lengths, results are inaccurate.

Low stress test scores

If your stress test scores are lower than expected, the following causes are the most common.

Insufficient client ports

The NLB instance removes the timestamp property of TCP connections by default. This makes the tw_reuse flag in the Linux stack ineffective: tw_reuse normally allows the kernel to reuse connections in the TIME_WAIT state, but without TCP timestamps, the kernel cannot safely determine whether a TIME_WAIT connection is stale. As a result, TIME_WAIT connections accumulate and exhaust frontend ports, causing new connection attempts to fail.

Solution: Switch clients to persistent connections and close connections with RST packets by setting the SO_LINGER socket option. This bypasses the TIME_WAIT state entirely and keeps ports available.

Full accept queues on backend servers

When the accept queue on a backend server is full, the server stops returning SYN-ACK packets and new connection requests from clients time out.

Solution: Increase the accept queue size and restart the application.

sysctl -w net.core.somaxconn=1024

The default value of net.core.somaxconn is 128.

Insufficient backend servers

When client IP preservation is disabled, the NLB instance connects to backend servers using its own IP address. Each backend server supports up to 120,000 concurrent connections by default. If the backend server count is too low, the total concurrent connection capacity is capped.

Solution:

For TCP or UDP listeners: enable client IP preservation.
For SSL over TCP listeners: add more backend servers or enable auto scaling.

Application dependency bottleneck

Even when backend server CPU and memory are within limits, an application dependency — such as a database — can become the bottleneck and limit throughput.

Solution: Clear applications that are no longer in use on the backend servers.

Unhealthy backend servers

If a backend server is declared unhealthy or the health status of the backend server changes frequently, the performance of the NLB instance in stress tests may be degraded.

Solution: Disable health checks before the stress test to prevent health check traffic from interfering with results.

Session conflicts on backend servers

When using the standard stress testing framework with a small number of clients or with consistent hashing by source IP, session conflicts occur on backend servers. The backend servers respond by frequently sending RST packets to close connections, as shown below.

Solution: Switch to the single-VIP stress testing framework. For details, see Stress testing frameworks.