Architecture, Operation, and Basic Configuration of Nginx
Nginx (Engine X) is a popular open-source HTTP web server, initially developed by Igor Sysoev in 2004 to solve the C10k problem (handling 10,000 simultaneous connections). Today, Nginx is not just a web server but also a powerful reverse proxy, load balancer, and HTTP cache.
1. Overview of Nginx
- Nginx is an HTTP web server, reverse proxy, load balancer, content cache, TCP/UDP proxy server, and mail proxy server.
- Known for its flexibility, high performance, stability, low resource consumption, and simple configuration.
- Efficiently handles thousands of connections simultaneously using an event-driven and non-blocking I/O mechanism.
2. Key Components of Nginx Architecture
Key components of Nginx architecture
Master Process:
- Manages the entire lifecycle of Nginx.
- Reads and checks the configuration file (nginx.conf).
- Creates and starts the worker processes.
- Handles signals from the system (like restart, reload, stop).
- Does not directly handle client requests.
Worker Processes:
- Handles client requests, serves static content, or forwards requests to the backend.
- Works independently and utilizes event-driven mechanisms to handle multiple connections simultaneously.
- The number of worker_processes is typically equal to the number of CPU cores to maximize resource usage.
Cache Loader Process (optional):
- Loads cache content from disk into memory on restart.
Cache Manager Process (optional):
- Manages the size and periodically cleans up cache content.
3. How the Worker Process Works
The Worker Process follows an event-driven model and uses mechanisms like epoll (on Linux) to handle multiple connections concurrently on a single thread.
A. Initialization and Event Waiting
Initialization: After being created by the Master Process, the Worker Process reads configuration information from the Nginx configuration file and sets up an event loop to monitor new connections, I/O requests, or tasks that need processing.
Event Waiting: The Worker Process registers events to be monitored (such as new connections, incoming data, or data write completion) with the system through the epoll mechanism.
B. Connection Handling
Receiving Events from Epoll: When an event occurs (such as a new client request), epoll notifies the Worker Process, and the Worker Process handles the event immediately.
Non-blocking Connections: The Worker Process does not block when waiting for data or resources. If data is not ready (e.g., the request body is not fully read), the Worker Process pauses and continues processing other connections in the queue.
Parallel Processing: Although each Worker Process runs on a single thread, it can handle thousands of simultaneous connections by switching between events in the loop.
C. Request Handling
Request Parsing: The HTTP request is parsed (headers, method, URL, etc.), validated, and steps specified in the configuration are executed.
Task Execution: Serve static content, proxy request to the backend server, or process SSL/TLS.
D. Sending Response
Prepare Response: Create an HTTP response with status code, headers, and body.
Send Response: Write data to the socket or send it in chunks if the data is large (chunked response).
E. Close or Keep Connection
After processing is complete, the Worker Process will close the connection if there are no further requests or keep the connection open if HTTP keep-alive is enabled.
4. Configuring Worker Processes
A. Worker Processes
Configuration file: /etc/nginx/nginx.conf (Typically, the configuration file can be found in /usr/local/nginx/conf or /etc/nginx or /usr/local/etc/nginx).
Customize via the worker_processes directive (default: auto = number of CPU cores).
Example:
worker_processes auto;
B. Worker Connections
Each worker process can handle many simultaneous connections.
The maximum number of concurrent connections is configured via the worker_connections directive.
Example:
worker_connections 1024;
Formula for calculating the maximum concurrent connections:
Max Connections = worker_processes × worker_connections
Example:
- worker_processes 4;
- worker_connections 1024;
- Max Connections = 4 × 1024 = 4096 concurrent connections.
C. Use Epoll (Linux-specific)
On Linux systems, it is recommended to enable the epoll mechanism for optimized event handling performance.
Example:
use epoll;
D. CPU Affinity
Specify which CPU core each Worker Process should use to reduce context-switching overhead.
Example:
worker_cpu_affinity auto;
5. Conclusion
Nginx, with its event-driven architecture and superior concurrency handling, is ideal for:
- Web server (static content).
- Reverse proxy server.
- Load balancer and cache management.
- Microservices application gateway.
Understanding Nginx architecture and optimizing its configuration helps improve performance, reduce resource consumption, and ensure system stability for large-scale web applications.
Tip: If you’re working with Nginx, testing and performance monitoring are essential for optimizing for specific use cases. Tools like Nginx Amplify and Prometheus + Grafana are very helpful in this regard.
References:
![]() | Nguyễn Thị Mỹ Phương Developer |