Application Load Balancer (ALB) provides high elasticity and large-scale Layer 7 traffic processing. If you need to benchmark ALB performance in your environment, use the methods described in this topic.
Test topology
Design your test environment based on the following architecture:
Stress testing methods
Key metrics
ALB has four key metrics. Each metric requires a different testing approach.
New connections
Use short connections to test the ability of ALB and backend servers to handle new connections.
Use a simple heartbeat service for testing to minimize the impact of excessive bandwidth consumption. When you test with short connections, watch for client port exhaustion issues.
Concurrent connections
Use long connections to test the ability of ALB and backend servers to handle concurrent connections.
Keep each long connection alive with a simple heartbeat service. When you test high concurrency with long connections, also watch for client port exhaustion.
Data throughput
Use long connections to test bandwidth limits or specific workload patterns.
Set a short timeout for the stress testing tool, such as 5 seconds. A long timeout increases the average response time in results, which makes it difficult to determine whether you have reached the target load. A short timeout reflects issues in the success rate, which makes it easier to identify the load level.
Requests per second
Test the request processing capability of ALB and backend servers. You can test with any of the following connection types:
HTTP short connections
HTTP long connections
HTTPS short connections
HTTPS long connections
Server group configuration
Disable health checks during stress tests to reduce the number of requests sent to backend servers.
Stress testing tools
Do not use Apache ab as a stress testing tool:
Apache ab exhibits staircase-pattern pauses of 3, 6, and 9 seconds under high concurrency.
Apache ab uses content length to determine whether a request succeeds. When ALB distributes traffic across multiple backend servers, each server may return a different content length, which causes inaccurate test results.
Causes of low stress test performance
If your stress test shows lower-than-expected performance, check for the following common causes.
Client port exhaustion
During stress testing, client port exhaustion causes connection failures. ALB strips the TCP timestamp attribute by default, which prevents tw_reuse (TIME_WAIT connection reuse) from working in the Linux protocol stack. As a result, connections in TIME_WAIT state accumulate and exhaust the available client ports.
Solution: Use one of the following approaches:
Replace short connections with long connections.
Use RST packets to close connections by setting the
SO_LINGERsocket option.
Backend server accept queue full
The backend server accept queue is full, which prevents the server from sending SYN_ACK packets. This causes client-side timeouts.
Solution: The default value of net.core.somaxconn is 128. Increase the value by running the following command, then restart the application on the backend server:
sysctl -w net.core.somaxconn=1024
Application dependency bottleneck
After requests pass through ALB and reach the backend servers, the server load may appear normal. However, if applications on the backend servers depend on other services, such as a database, the dependent service can become a bottleneck and degrade overall performance.
Solution: Identify and remove unnecessary applications from backend servers, or scale out the dependent services.
Unhealthy backend servers
During stress testing, an unstable health check status on backend servers can reduce performance. If a backend server health check repeatedly alternates between healthy and unhealthy states (flapping), ALB frequently adds and removes the server from the load balancing rotation.
Solution: Disable health checks during stress tests to reduce the number of health check requests sent to backend servers.