Skip to main content
This document explains why NGINX is so efficient at handling large numbers of concurrent connections. At its core is an event-driven, non-blocking architecture combined with a multi-process model for multicore systems. The explanation below preserves the original diagrams and order while improving flow and clarity.

​
Overview: event-driven, non-blocking I/O

NGINX uses an event-driven (asynchronous, non-blocking) model inside each worker process. Instead of dedicating a thread or process to each connection, each worker runs an event loop that polls for readiness events (readable sockets, writable sockets, timers, etc.) and processes events as they become ready. This avoids blocking on slow I/O (disk, upstream servers, or slow clients) and allows a single worker to handle thousands of simultaneous connections with low memory and CPU overhead.

​
The coffee-shop analogy

Imagine a busy coffee shop:
  • If a single barista took an order, prepared the drink, and then took the next order, the line would grow.
  • Instead, one person takes orders, another prepares drinks, and a third hands them out. While a drink is being prepared, the order-taker continues taking new orders.
This separation of responsibilities—decoupling the waiting work from the active work—is the essence of NGINX’s event-driven model. While a request is waiting for I/O, the worker’s event loop moves on to other ready events.

​
How the event loop operates

The event loop repeatedly polls the operating system for events and dispatches ready events to handlers. On Linux NGINX typically uses epoll; on BSD and macOS it uses kqueue. Because the loop never blocks on a single connection, workers can make progress on many connections concurrently.
A flow diagram titled "Event Handling in Nginx" showing boxes for Incoming Request → Event Loop → Processing the Event → Response Sent connected by arrows. A user icon at left sends an HTTP request to the pipeline and receives the response after processing.

​
Core steps in NGINX request processing

This event-driven loop allows a single worker to multiplex many connections efficiently without creating a thread per connection.

​
Scaling across CPU cores: master and worker processes

To utilize multiple CPU cores and to provide process-level isolation, NGINX runs as multiple processes:
  • Master process
    • Runs with elevated privileges.
    • Loads configuration, opens listening sockets, and manages worker lifecycles (start, stop, reload).
    • Does not handle client requests directly.
  • Worker processes
    • Each worker runs a single-threaded event loop.
    • Workers accept connections and handle all request processing using non-blocking I/O (epoll, kqueue, etc.).
    • Multiple workers run in parallel across cores, giving both concurrency and resilience.
Think of the master process as a supervisor who manages staffing and resources, while the workers are the chefs and servers doing the request handling.
A diagram titled "Request Handling in Nginx" showing a single Master Process at the top delegating incoming Request/Response connections to multiple Worker Processes. Each worker contains an Event Loop that handles the requests.

​
Why this design is efficient

  • Event-driven, non-blocking I/O minimizes idle CPU and memory usage when many connections are waiting.
  • A single worker can handle thousands of simultaneous connections because it relies on readiness notifications rather than blocking threads.
  • Multiple worker processes provide parallelism across cores and enable graceful restarts and configuration reloads with minimal disruption.
NGINX achieves high concurrency by combining an event loop (non-blocking I/O) inside each worker with multiple worker processes to utilize multiple CPU cores. This design delivers memory-efficient, high-throughput request handling suited for modern web workloads.
Thanks for your time.

Watch Video