Least connections in Nginx - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding Least Connections Load Balancing

What does the least connections method do in an NGINX load balancer?

A It sends requests only to the server with the highest CPU usage.

B It sends requests to servers in a fixed round-robin order regardless of load.

C It sends requests randomly to any server in the pool.

D It sends new requests to the server with the fewest active connections.

💡 Hint

Think about how to balance load by connection count.

The least connections method directs traffic to the server currently handling the fewest active connections, helping balance load dynamically.

❓ Configuration

intermediate

Configuring Least Connections in NGINX

Which NGINX configuration snippet correctly enables the least connections load balancing method?

Nginx

upstream backend {
    least_conn;
    server backend1.example.com;
    server backend2.example.com;
}

A

upstream backend {
    round_robin;
    server backend1.example.com;
    server backend2.example.com;
}

B

upstream backend {
    least_conn;
    server backend1.example.com;
    server backend2.example.com;
}

C

upstream backend {
    random;
    server backend1.example.com;
    server backend2.example.com;
}

D

upstream backend {
    ip_hash;
    server backend1.example.com;
    server backend2.example.com;
}

💡 Hint

Look for the directive that specifies least connections.

The least_conn; directive inside the upstream block enables least connections load balancing.

💻 Command Output

advanced

Interpreting NGINX Upstream Status Output

Given this NGINX status output snippet showing active connections per backend server, which server will receive the next request if least_conn is enabled?

backend1.example.com - active connections: 5
backend2.example.com - active connections: 3
backend3.example.com - active connections: 7

A backend3.example.com

B backend1.example.com

C backend2.example.com

D All servers equally

💡 Hint

Which server has the fewest active connections?

The server with the fewest active connections (3) is backend2.example.com, so it will receive the next request.

❓ Troubleshoot

advanced

Troubleshooting Uneven Load Distribution

You configured NGINX with least_conn load balancing, but one backend server is still overloaded while others are idle. What is the most likely cause?

A The overloaded server has long-lived connections that keep its active connection count high.

B NGINX is using round-robin instead of least connections.

C The backend servers have different IP addresses configured incorrectly.

D The DNS resolution for backend servers is failing.

💡 Hint

Think about how connection duration affects load balancing.

Long-lived connections on one server keep its active connection count high, causing least connections to keep sending requests to other servers, but the overloaded server remains busy.

🔀 Workflow

expert

Implementing Least Connections with Health Checks

You want to configure NGINX to use least_conn load balancing but also ensure that unhealthy backend servers are not used. Which configuration snippet correctly combines least connections with active health checks?

A

upstream backend {
    least_conn;
    server backend1.example.com max_fails=3 fail_timeout=30s;
    server backend2.example.com max_fails=3 fail_timeout=30s;
    health_check;
}

B

upstream backend {
    least_conn;
    server backend1.example.com;
    server backend2.example.com;
    check interval=3000 rise=2 fall=5 timeout=1000;
}

C

upstream backend {
    least_conn;
    server backend1.example.com;
    server backend2.example.com;
    health_check;
}

D

upstream backend {
    least_conn;
    server backend1.example.com max_fails=3 fail_timeout=30s;
    server backend2.example.com max_fails=3 fail_timeout=30s;
}

💡 Hint

Look for the combination of least_conn, server fail parameters, and health_check directive.

Option A correctly uses least_conn; with server parameters max_fails and fail_timeout to mark servers as down after failures, plus the health_check; directive to actively check server health.