Least connections in Nginx - Time & Space Complexity
We want to understand how the time to pick a server grows as the number of servers increases in nginx's least connections load balancing.
How does nginx find the server with the fewest active connections efficiently?
Analyze the time complexity of this nginx configuration snippet using least connections:
upstream backend {
least_conn;
server backend1.example.com;
server backend2.example.com;
server backend3.example.com;
}
server {
location / {
proxy_pass http://backend;
}
}
This config tells nginx to send each request to the server with the fewest active connections.
Identify the loops, recursion, array traversals that repeat.
- Primary operation: nginx checks the active connections count of each server in the upstream list.
- How many times: Once per incoming request, it compares all servers to find the one with the least connections.
As the number of servers (n) grows, nginx must check each server's connection count to pick the least busy one.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 | 10 comparisons |
| 100 | 100 comparisons |
| 1000 | 1000 comparisons |
Pattern observation: The number of operations grows directly with the number of servers.
Time Complexity: O(n)
This means the time to pick a server grows linearly as the number of servers increases.
[X] Wrong: "nginx instantly knows the least connected server without checking all servers."
[OK] Correct: nginx must compare all servers' connection counts each time to find the least busy one, so it takes longer with more servers.
Understanding how load balancers pick servers helps you explain real-world system behavior and shows you can think about efficiency in infrastructure.
"What if nginx used a priority queue to track servers by active connections? How would the time complexity change?"
Practice
least_conn directive do in an nginx upstream block?Solution
Step 1: Understand the purpose of
Theleast_connleast_conndirective is used to balance load by sending requests to the server with the fewest active connections.Step 2: Compare with other load balancing methods
Other methods like round-robin or fastest response time differ;least_connfocuses on active connections count.Final Answer:
Sends new requests to the server with the fewest active connections -> Option AQuick Check:
Least connections = fewest active connections [OK]
- Confusing least connections with round-robin
- Thinking it picks fastest server instead
- Assuming it sends to server with most connections
Solution
Step 1: Recall the exact directive name
The correct directive to enable least connections isleast_conninside theupstreamblock.Step 2: Verify syntax correctness
Options A, B, and D use incorrect directive names or misspellings.Final Answer:
upstream backend { least_conn; server 192.168.1.1; } -> Option AQuick Check:
Correct directive = least_conn [OK]
- Using 'least_connections' instead of 'least_conn'
- Misspelling the directive as 'leastconn' or 'least_conn_load'
- Placing directive outside the upstream block
<pre>upstream backend { least_conn; server 10.0.0.1; server 10.0.0.2; } If 10.0.0.1 has 5 active connections and 10.0.0.2 has 3 active connections, where will the next request be sent?
Solution
Step 1: Identify the load balancing method
Theleast_connmethod sends requests to the server with the fewest active connections.Step 2: Compare active connections of servers
10.0.0.1 has 5 connections, 10.0.0.2 has 3 connections, so the next request goes to 10.0.0.2.Final Answer:
To 10.0.0.2 because it has fewer active connections -> Option CQuick Check:
Least connections picks server with 3 connections [OK]
- Choosing server listed first instead of fewest connections
- Assuming equal distribution regardless of connections
- Picking server with more connections by mistake
least_conn but all requests keep going to the same server. What is the most likely cause?Solution
Step 1: Check if configuration changes are active
If nginx is not reloaded after config changes, old settings remain active causing unexpected behavior.Step 2: Consider other causes
Misspelling or missing servers cause errors or no load balancing, but requests going to one server usually means config not applied.Final Answer:
The nginx service was not reloaded after configuration change -> Option DQuick Check:
Reload nginx after config changes [OK]
- Ignoring the need to reload nginx after config update
- Assuming equal connections cause all traffic to one server
- Not verifying server directives exist in upstream block
- Server A: 2 active connections, slow response
- Server B: 5 active connections, fast response
- Server C: 2 active connections, medium response
Using
least_conn load balancing, which server will receive the next request and why?Solution
Step 1: Understand
It sends requests to servers with the fewest active connections, ignoring response time.least_connprioritizes active connectionsStep 2: Compare servers with fewest connections
Server A and C both have 2 connections, butleast_conndoes not consider response speed, so it picks the first with fewest connections, Server A.Final Answer:
Server A, because it has the fewest active connections and slow response is ignored -> Option BQuick Check:
Least connections ignores speed, picks fewest active connections [OK]
- Assuming fastest response server is chosen with least_conn
- Thinking least_conn balances by response time
- Expecting even distribution regardless of connections
Ready to prove it?
Pass the test and this pattern moves unknown
