Apache MPM motorz

How it Works ¶

motorz uses prefork as the framework for process management and an event core for connection handling. A single control process (the parent) launches a fixed number of child processes, as set by the StartServers directive. Unlike worker and event, the number of children does not float with load: motorz maintains a static pool, replacing children one-for-one as they exit. Concurrency within a host is scaled by adding worker threads (ThreadsPerChild) and, where the poll/dispatch path is the bottleneck, poller threads (PollersPerChild), rather than by spawning more processes.

Each child process runs:

• One or more poller threads. Each poller owns its own pollset, timer ring (with a guarding mutex) and lock-free transaction-pool recycle list, so pollers never contend with one another. A poller polls, dispatches ready I/O events and expired timers to the worker pool, and (for the poller that owns the listening sockets) accepts new connections. The number of pollers is controlled by PollersPerChild.
• A shared pool of worker threads (ThreadsPerChild) that run the actual connection and request processing pushed to them. Workers never poll.
• A supervisor (the child's main thread) that watches MaxConnectionsPerChild and the pipe-of-death / generation, signals the pollers to wind down, and then joins them on exit.

A connection is sharded to one poller at accept time (round-robin) and bound to it for its whole lifetime: it re-arms in, and times out on, that poller's pollset and timer ring. Using multiple pollers lifts the single-poll-thread throughput ceiling, so accept, event dispatch and timer expiry scale with PollersPerChild instead of being serialized on one thread.

While the parent process is usually started as root under Unix in order to bind to port 80, the child processes and threads are launched by the server as a less-privileged user. The User and Group directives are used to set the privileges of the Apache HTTP Server child processes. The child processes must be able to read all the content that will be served, but should have as few privileges beyond that as possible.

MaxConnectionsPerChild controls how frequently the server recycles processes by retiring old ones and launching new ones.

Asynchronous connection handling ¶

motorz reports itself as an asynchronous MPM. When a worker finishes the active phase of a connection (for example, an HTTP keep-alive connection between requests, or a connection waiting on further I/O), it hands the socket back to its poller rather than holding a worker thread idle. The poller waits for the next event on that socket, bounded by the configured Timeout, and re-dispatches the connection to a worker only when there is work to do. This frees worker threads from idle keep-alive connections and is what allows efficient HTTP/2 handling, where the master connection is handed back to the MPM between requests.

Lingering close is also non-blocking: instead of blocking a worker for the duration of the lingering-close timeout, the draining socket is handed back to the poll loop with a bounded linger timeout, so the worker is returned to the pool immediately.

Modules that take a connection fully asynchronous (suspending it and resuming it later) are supported; a suspended connection is parked and re-armed on its owning poller when resumed.

Admission control ¶

To keep a child safe under overload, motorz applies listener backpressure. When the worker pool saturates, the poller that owns the listening sockets removes them from its pollset and stops accepting; it re-adds them once the backlog drains. This keeps the work queue and per-connection memory bounded rather than growing without limit. The decision is based on the worker pool's idle, pending and active-thread counts, with hysteresis to avoid flapping the listeners on and off.

Relationship to other MPMs ¶

motorz uses prefork for process management and an APR thread pool for workers, with pollers dispatching work to that pool. This is distinct from event's listener/worker/fdqueue design, in which the worker threads themselves re-arm a shared, thread-safe pollset.

Whether additional pollers help depends on the workload. If the worker threads are the CPU bottleneck—typical for real request processing—the poller threads are not the limiting factor, and a PollersPerChild beyond one or two yields little. The multiple-poller design removes motorz's structural single-thread ceiling, but per-host throughput is still governed by worker CPU.

StartServers       2
ThreadsPerChild   64
ThreadLimit       64
PollersPerChild    2