Worker processes and connections in Nginx - Deep Dive

Overview - Worker processes and connections

What is it?

Worker processes in nginx are separate programs that handle client requests. Each worker process manages multiple connections from users at the same time. This setup helps nginx serve many users efficiently by dividing the work. Connections are the individual links between users and the server that carry data back and forth.

Why it matters

Without worker processes, nginx would handle one request at a time, making websites slow and unresponsive. Worker processes allow nginx to handle many users simultaneously, improving speed and reliability. Understanding how connections are managed helps optimize server performance and avoid crashes under heavy traffic.

Where it fits

Before learning about worker processes and connections, you should understand basic web servers and how clients communicate with servers. After this, you can learn about load balancing, caching, and advanced nginx tuning for high traffic websites.

Mental Model

Core Idea

Worker processes are like multiple cashiers serving customers simultaneously, each handling many customers (connections) at once to keep the line moving fast.

Think of it like...

Imagine a busy supermarket with several cashiers (worker processes). Each cashier can scan items for many customers (connections) one after another quickly. If there was only one cashier, the line would be very slow and long.

┌───────────────┐
│   Master      │
│   Process     │
└──────┬────────┘
       │
       ▼
┌───────────────┐   ┌───────────────┐   ┌───────────────┐
│ Worker Proc 1 │   │ Worker Proc 2 │   │ Worker Proc N │
│ Connections  │   │ Connections  │   │ Connections  │
│ 1,2,3,...    │   │ 1,2,3,...    │   │ 1,2,3,...    │
└───────────────┘   └───────────────┘   └───────────────┘

Build-Up - 7 Steps

1

Foundation

What is a worker process

Concept: Introduces the idea of worker processes as separate programs handling requests.

Nginx runs a master process that controls several worker processes. Each worker process handles the actual work of receiving and responding to client requests. This separation helps nginx manage many users efficiently.

Result

You understand that worker processes are the main units doing the work in nginx.

Knowing that worker processes do the real work helps you see why nginx can handle many requests at once.

2

Foundation

Understanding connections in nginx

Concept: Explains what connections are and how they relate to worker processes.

A connection is a communication link between a client (like a browser) and the nginx server. Each worker process can manage many connections at the same time using efficient event handling.

Result

You see that connections are the individual conversations between users and the server.

Understanding connections clarifies how nginx serves multiple users simultaneously.

3

Intermediate

How worker processes handle multiple connections

🤔Before reading on: do you think each worker process handles one connection at a time or many connections simultaneously? Commit to your answer.

Concept: Introduces nginx's event-driven model allowing one worker to handle many connections.

Nginx uses an event-driven model where each worker process can handle thousands of connections without creating a new thread or process for each. It waits for events like data arriving or being ready to send, then acts on them.

Result

You learn that one worker process can efficiently manage many connections at once.

Knowing nginx uses event-driven handling explains its high performance and low resource use.

4

Intermediate

Configuring worker_processes in nginx

🤔Before reading on: should the number of worker processes be less than, equal to, or greater than the number of CPU cores? Commit to your answer.

Concept: Shows how to set the number of worker processes to optimize performance.

In nginx configuration, the 'worker_processes' directive sets how many worker processes run. A common best practice is to set this equal to the number of CPU cores to maximize CPU use without overhead.

Result

You can configure nginx to use the right number of worker processes for your server.

Understanding how worker_processes relates to CPU cores helps avoid wasting resources or causing contention.

5

Intermediate

worker_connections and max clients

🤔Before reading on: does increasing worker_connections always increase max clients linearly? Commit to your answer.

Concept: Explains the worker_connections directive and how it limits simultaneous connections per worker.

The 'worker_connections' directive sets the max number of connections a single worker can handle. The total max clients nginx can serve is roughly worker_processes × worker_connections. But other limits like OS file descriptors also matter.

Result

You understand how to calculate and tune max simultaneous clients nginx can handle.

Knowing worker_connections limits helps prevent overload and plan capacity.

6

Advanced

Master process role in worker management

🤔Before reading on: does the master process handle client requests directly? Commit to your answer.

Concept: Details the master process's role in managing workers but not handling requests.

The master process starts, stops, and reloads worker processes. It does not handle client connections itself. This separation allows smooth configuration reloads without dropping connections.

Result

You see the master process as a manager, not a worker.

Understanding the master-worker split explains nginx's stability and zero-downtime reloads.

7

Expert

Unexpected limits and tuning pitfalls

🤔Before reading on: do you think increasing worker_processes beyond CPU cores always improves performance? Commit to your answer.

Concept: Explores subtle performance issues and system limits affecting workers and connections.

Increasing worker_processes beyond CPU cores can cause context switching overhead, reducing performance. Also, OS limits like file descriptors and network buffers can block more connections. Proper tuning requires balancing these factors and monitoring system metrics.

Result

You learn why blindly increasing workers or connections can hurt performance.

Knowing system-level limits and overhead prevents common tuning mistakes that degrade nginx performance.

Under the Hood

Nginx runs a single master process that spawns multiple worker processes. Each worker uses an event-driven, non-blocking model to handle many connections simultaneously. It listens for events like new data or readiness to send data, then processes them quickly without waiting. This avoids creating a thread or process per connection, saving memory and CPU.

Why designed this way?

Nginx was designed to handle many thousands of simultaneous connections efficiently on limited hardware. Traditional thread-per-connection models used too much memory and CPU. The event-driven worker process model was chosen to maximize performance and scalability with minimal resource use.

┌───────────────┐
│   Master      │
│   Process     │
└──────┬────────┘
       │
       ▼
┌─────────────────────────────┐
│ Worker Process (Event Loop)  │
│ ┌─────────────────────────┐ │
│ │ Connection 1            │ │
│ │ Connection 2            │ │
│ │ ...                    │ │
│ │ Connection N            │ │
│ └─────────────────────────┘ │
└─────────────────────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does one worker process handle only one connection at a time? Commit to yes or no.

Common Belief: Each worker process handles only one connection at a time.

Reality: Each worker process can handle thousands of connections simultaneously using an event-driven model.

Why it matters: Believing this limits understanding of nginx's efficiency and leads to wrong tuning decisions.

Quick: Should worker_processes always be set to 1 for simplicity? Commit to yes or no.

Common Belief: Setting worker_processes to 1 is simpler and enough for most servers.

Reality: Setting worker_processes to match CPU cores maximizes performance by using all CPU resources.

Why it matters: Using only one worker wastes CPU power and reduces server capacity.

Quick: Does increasing worker_connections always increase max clients linearly? Commit to yes or no.

Common Belief: Increasing worker_connections always increases max clients proportionally.

Reality: Other system limits like file descriptors and network buffers can prevent linear scaling.

Why it matters: Ignoring system limits causes unexpected connection failures under load.

Quick: Does the master process handle client requests directly? Commit to yes or no.

Common Belief: The master process handles client requests along with workers.

Reality: The master process only manages workers; it does not handle client connections.

Why it matters: Misunderstanding this can cause confusion about nginx's reload and stability behavior.

Expert Zone

1

Worker processes do not share memory, so all shared data must use inter-process communication or external storage.

2

The event-driven model depends on OS support like epoll or kqueue for efficiency; performance varies by OS.

3

Tuning worker_connections without adjusting OS limits like 'ulimit -n' can silently fail to increase capacity.

When NOT to use

Using many worker processes on a single-core or low-memory server can cause overhead and reduce performance. For very low traffic, a single worker may suffice. Alternatives like multi-threaded servers or asynchronous frameworks may be better for some workloads.

Production Patterns

In production, nginx is often configured with worker_processes equal to CPU cores and worker_connections tuned to expected load. Monitoring tools track connection counts and CPU usage to adjust settings. Zero-downtime reloads rely on the master process managing workers carefully.

Connections

Event-driven programming

Worker processes use event-driven programming to handle many connections efficiently.

Understanding event-driven programming clarifies how nginx avoids blocking and scales well.

Operating system file descriptors

Worker connections depend on OS file descriptor limits to open network sockets.

Knowing OS limits helps prevent connection failures and guides tuning worker_connections.

Restaurant kitchen workflow

Like a kitchen with multiple chefs (workers) handling many orders (connections) efficiently.

Seeing worker processes as chefs managing many orders helps understand concurrency and resource use.

Common Pitfalls

#1 Setting worker_processes too high causing CPU contention.

Wrong approach:

worker_processes 16;

Correct approach:

worker_processes auto;

Root cause:

Misunderstanding that more workers than CPU cores cause overhead, not better performance.

#2 Not increasing OS file descriptor limits when raising worker_connections.

Wrong approach:

worker_connections 65535;
# no change to ulimit or system limits

Correct approach:

worker_connections 65535;
# and increase ulimit -n to 65535 or higher

Root cause:

Ignoring OS limits causes nginx to silently fail to open new connections.

#3 Believing master process handles client requests directly.

Wrong approach:

# Trying to configure master process for request handling (not possible)

Correct approach:

# Master process only manages workers; no request handling config

Root cause:

Confusing master process role leads to wrong expectations about reloads and stability.

Key Takeaways

Nginx uses multiple worker processes to handle many client connections efficiently and concurrently.

Each worker process can manage thousands of connections simultaneously using an event-driven model.

Configuring worker_processes to match CPU cores and tuning worker_connections optimizes performance.

The master process manages workers but does not handle client requests directly.

Understanding system limits like file descriptors is essential to properly scale nginx connections.