📖 Scenario: You are setting up an Nginx server to efficiently manage connections to a backend service. To improve performance and reduce latency, you want to use connection pooling to reuse connections to the upstream server.
🎯 Goal: Configure Nginx to use connection pooling with an upstream server. You will create an upstream block, set a configuration variable for maximum idle connections, apply the connection pooling settings, and finally verify the configuration by printing the relevant part.
📋 What You'll Learn
Create an upstream block named backend with one server at 127.0.0.1:8080
Add a variable max_idle_conns set to 32
Configure the upstream backend block to use keepalive with the value of max_idle_conns
Print the upstream backend block configuration to verify connection pooling
💡 Why This Matters
🌍 Real World
Connection pooling reduces the overhead of opening new connections to backend servers, improving response time and resource usage in web servers.
💼 Career
Understanding how to configure connection pooling in Nginx is essential for DevOps engineers and system administrators to optimize web server performance and scalability.
Progress0 / 4 steps
1
Create the upstream block
Create an upstream block named backend with a server at 127.0.0.1:8080.
Nginx
Hint
Use the upstream directive followed by the name backend. Inside the block, add the server directive with the IP and port.
2
Add max_idle_conns variable
Add a variable called max_idle_conns and set it to 32.
Nginx
Hint
Use the set directive to create a variable named $max_idle_conns with the value 32.
3
Configure connection pooling with keepalive
Inside the upstream backend block, add the keepalive directive with the value 32 to enable connection pooling.
Nginx
Hint
Add keepalive 32; inside the upstream backend block to set the maximum idle connections.
4
Print the upstream block configuration
Print the upstream backend block configuration to verify the connection pooling settings.
Nginx
Hint
Nginx configuration files do not support print statements. To verify, check the configuration file or reload Nginx.
Practice
(1/5)
1. What is the main purpose of using keepalive in an upstream block in nginx?
easy
A. To limit the number of client connections to nginx
B. To close all connections immediately after each request
C. To reuse open connections to backend servers and improve response speed
D. To enable caching of static files on the server
Solution
Step 1: Understand the role of keepalive in upstream
The keepalive directive in the upstream block tells nginx to keep a number of connections open to backend servers for reuse.
Step 2: Identify the benefit of connection reuse
Reusing connections avoids the overhead of opening new connections for each request, improving speed and reducing latency.
Final Answer:
To reuse open connections to backend servers and improve response speed -> Option C
Quick Check:
Connection pooling = reuse connections = To reuse open connections to backend servers and improve response speed [OK]
Hint: Remember: keepalive means keep connections open for reuse [OK]
Common Mistakes:
Thinking keepalive limits client connections
Confusing keepalive with caching
Assuming keepalive closes connections immediately
2. Which of the following is the correct syntax to enable connection pooling with 32 keepalive connections in an nginx upstream block?
easy
A. upstream backend { keepalive 32; server backend1.example.com; }
B. upstream backend { keepalive_connections 32; server backend1.example.com; }
C. upstream backend { keepalive=32; server backend1.example.com; }
D. upstream backend { keepalive 32 servers; server backend1.example.com; }
Solution
Step 1: Recall the correct directive syntax
The correct directive to set connection pooling count is keepalive followed by the number, ending with a semicolon.
Step 2: Check each option's syntax
upstream backend { keepalive 32; server backend1.example.com; } uses keepalive 32; which is correct. Options A, B, and C use incorrect directive names or syntax.
Final Answer:
upstream backend { keepalive 32; server backend1.example.com; } -> Option A
Hint: Use HTTP/1.1 and clear Connection header to enable reuse [OK]
Common Mistakes:
Assuming HTTP/1.1 disables reuse
Not clearing Connection header disables pooling
Confusing keepalive with client connections
4. You configured connection pooling with keepalive 10; in your upstream block, but nginx is still opening new connections for every request. What is the most likely cause?
medium
A. You forgot to set proxy_http_version 1.1; and clear the Connection header
B. The keepalive directive only works with HTTP/2
C. You need to increase keepalive to at least 100
D. The backend server does not support keepalive connections
Solution
Step 1: Check proxy settings required for connection reuse
For connection pooling to work, nginx must use HTTP/1.1 and clear the Connection header to avoid closing connections.
Step 2: Identify common misconfiguration
If proxy_http_version 1.1; and proxy_set_header Connection ""; are missing, nginx will close connections after each request despite keepalive.
Final Answer:
You forgot to set proxy_http_version 1.1; and clear the Connection header -> Option A
Hint: Always set proxy_http_version 1.1 and clear Connection header [OK]
Common Mistakes:
Believing keepalive works without proxy_http_version 1.1
Thinking backend server must be changed first
Assuming keepalive number is too low
5. You want to optimize nginx to reuse connections to multiple backend servers with different keepalive limits. Which configuration correctly sets 20 keepalive connections for backend1 and 10 for backend2?
hard
A. upstream backend { server backend1.example.com; keepalive 20; server backend2.example.com; keepalive 10; }
B. upstream backend1 { server backend1.example.com; keepalive 20; } upstream backend2 { server backend2.example.com; keepalive 10; }
C. upstream backend { server backend1.example.com keepalive=20; server backend2.example.com keepalive=10; }
D. upstream backend { server backend1.example.com; server backend2.example.com; keepalive 30; }
Solution
Step 1: Understand keepalive scope
The keepalive directive applies per upstream block, not per server inside it.
Step 2: Check options for setting different keepalive values
upstream backend1 { server backend1.example.com; keepalive 20; } upstream backend2 { server backend2.example.com; keepalive 10; } defines two separate upstream blocks, each with its own keepalive setting, which is correct. Options B, C, and D try to set different keepalive values inside one upstream block, which is invalid.
Final Answer:
upstream backend1 { server backend1.example.com; keepalive 20; } upstream backend2 { server backend2.example.com; keepalive 10; } -> Option B
Quick Check:
Separate upstream blocks for different keepalive values = upstream backend1 { server backend1.example.com; keepalive 20; } upstream backend2 { server backend2.example.com; keepalive 10; } [OK]
Hint: Use separate upstream blocks to set different keepalive values [OK]
Common Mistakes:
Trying to set keepalive per server inside one upstream
Using invalid syntax with equal signs
Setting one keepalive for multiple servers expecting different limits
Recommended
Ready to prove it?
Pass the test and this pattern moves unknownstrongwhile earning +1 Grip toward your certificate.