A worker process is an operating system process that a master or parent process starts to perform the actual work of a server application, such as handling network requests, executing scripts or processing queued jobs. On servers, the master usually reads configuration, binds privileged ports and manages the lifecycle, while a pool of workers does the request handling in parallel.
The model appears in web servers such as NGINX and Apache httpd, in application servers such as PHP-FPM, Gunicorn and Puma, and in job runners. It turns one long-running service into a supervised group of replaceable units, which is the basis for graceful restarts, crash isolation and controlled resource use.
How the master and worker model operates
The master process starts first, often as root, opens the listening sockets and then forks the workers, which typically drop privileges to an unprivileged account. Because a forked child inherits open file descriptors, every worker can accept connections on the same socket without the master forwarding traffic.
After startup the master rarely touches requests. It monitors its children, replaces any worker that exits unexpectedly, reacts to signals such as SIGHUP or SIGUSR2 and reopens log files. Each worker has its own process ID and its own memory space, so a crash or memory leak in one worker does not corrupt the others.
The following table shows how responsibilities are usually divided between the two roles.
| Responsibility | Master process | Worker process |
|---|---|---|
| Configuration | Reads and validates it | Receives a copy at fork time |
| Listening sockets | Binds ports, including 80 and 443 | Accepts connections on inherited sockets |
| Privileges | Often runs as root | Runs as an unprivileged user |
| Request handling | None or minimal | Parses, executes and responds |
| Lifecycle | Spawns, monitors and replaces workers | Exits on signal, limit or error |
Worker concurrency models
A worker process can serve one request at a time or many concurrent connections, depending on its internal design. This choice determines how many workers a server needs and how memory scales with traffic.
| Model | Concurrency per worker | Typical examples | Main trade-off |
|---|---|---|---|
| Prefork, one request per process | One | PHP-FPM, Apache prefork MPM | Simple and isolated, but memory-heavy |
| Threaded workers | Several to dozens of threads | Apache worker MPM, Puma | Less memory, but threads share failures |
| Event-driven workers | Thousands of connections | NGINX, Apache event MPM | Very efficient, but blocking code stalls the loop |
| Job workers | One job or a small batch | Queue consumers, cron runners | Decoupled from requests, needs a queue |
For event-driven servers the usual rule is one worker per CPU core, because each worker already multiplexes many connections. For prefork and blocking application servers, the worker count is limited mainly by available memory divided by per-worker memory, since most workers spend time waiting on databases or external services.
Key parameters for sizing worker processes
Correct sizing keeps the server busy without pushing it into swap or out-of-memory kills. The table lists parameters that most worker-based servers expose under different names.
| Parameter | Typical range | What it affects |
|---|---|---|
| Worker count | 1 per core (event) to 5-200 (prefork) | Parallelism and total memory use |
| Memory per worker | About 10 MB to over 300 MB | Maximum safe worker count |
| Maximum requests per worker | 500 to 10,000, or unlimited | Recycling that contains slow memory leaks |
| Request timeout | 30 to 300 seconds | How long a stuck worker blocks a slot |
| Spare or idle workers | A few to about 20 percent of the pool | Readiness for traffic spikes |
A practical starting formula is usable RAM divided by the measured average worker size, reduced by a safety margin of 10 to 20 percent for the operating system, caches and the database. The measured resident memory of real workers under load matters more than any default value.
Worker process compared with related concepts
A worker process is often confused with neighboring concepts in services and processes. The distinctions below clarify who starts what and who restarts whom.
| Concept | Role | Relation to a worker process |
|---|---|---|
| Daemon | Long-running background service | The master of a daemon commonly spawns workers |
| Process supervisor | External manager such as systemd | Restarts the whole service, not individual workers |
| Thread | Execution unit inside one process | Shares memory; a worker may contain many threads |
| Graceful restart | Reload without dropping connections | Achieved by replacing workers one generation at a time |
Common mistakes with worker processes
Most production incidents involving workers come from sizing errors and blocking behavior, not from the model itself.
- Too many workers for the RAM causes swapping and kernel out-of-memory kills, which is slower than queuing requests.
- Too few workers lets slow upstream calls occupy every slot, so new requests wait even though the CPU is idle.
- Blocking calls in an event loop freeze every connection that the affected worker holds.
- No request recycling lets small memory leaks grow until workers reach several times their normal size.
- Per-worker state such as local caches or sessions breaks when the next request reaches a different worker.
Explained without jargon
Think of a busy restaurant. The manager opens the doors, assigns tables and replaces anyone who goes home sick, but the waiters do the actual serving. On a server, the manager is the master process and the waiters are the worker processes.
If one waiter drops a tray, the others keep working and the manager hires a replacement. Hiring more waiters helps only while there is room in the kitchen, which is why the number of workers must match the server memory.
A typical use case
An online shop runs PHP-FPM on a virtual server with 8 GB of RAM. Measurements show each PHP worker uses about 80 MB under normal load. After reserving roughly 3 GB for the database, the operating system and caches, the administrator sets the pool to 60 workers and recycles each one after 1,000 requests to contain a known plugin memory leak.
During a seasonal sale, request volume doubles. Because the pool is capped, extra requests wait briefly in the listen queue instead of starting new processes, the server never swaps, and response times rise moderately rather than collapsing. The result is a stable shop under peak load with predictable memory use.