Apache HTTPD / Representation, proxying, and capacity / Lesson 12

MPM capacity and timeout budgets

Reason about concurrency, waiting, resource cost, and request phases without copying universal worker settings.

About 4 min readContent reviewed 2026-10-28

On this page

Lesson goals

Compare prefork, worker, and event at the correct conceptual level.
Separate request limits, connection behavior, backend capacity, and timeout scopes.

The execution model determines what a slot means

prefork uses a process-oriented non-threaded request model, while worker uses multiple processes with threads and event handles some connection states asynchronously under its documented design. Actual behavior depends on platform, filters, protocols, and modules. A thread-unsafe integration can constrain MPM choice. Do not replace an MPM merely because a blog calls another faster. Parcel’s workload, application integration, memory, file descriptors, backend limits, and operational compatibility need review. This course selects, starts, or reconfigures no MPM.

A request ceiling is not a throughput guarantee

MaxRequestWorkers and related MPM directives constrain request-serving concurrency under their documented semantics and limits. Process and thread settings interact; they are not independent knobs to maximize. Persistent connections, asynchronous states, TLS, filters, and protocol-specific work can make connection count differ from active request workers. Backend capacity can be the actual bottleneck even when Apache has spare slots. A higher configured ceiling can increase queueing, memory pressure, or upstream overload rather than improve user latency.

Declare assumptions before calculating

The JSON below is a hypothetical threaded-slot calculation input, not Apache configuration or measured capacity. It assumes four processes and twenty-five relevant request threads each only for a simple multiplication. It excludes hard limits, spare-thread behavior, async connections, protocol-specific concurrency, shared resources, and application cost. No suggested worker value follows from it. A real capacity review needs observed workload and the actual installed MPM, not an attractive round number transferred from a teaching example.

json A synthetic capacity-assumption record

{"model":"threaded-request-slots-only","processes":4,"threads_per_process":25,"excludes":["memory","backend-limit","async-connections","protocol-specific-work"]}

The values are invented model inputs, not recommended directives or a snapshot of any server. No resource or setting is inspected or changed.

Different phases need different deadlines

Connection establishment, request reading, keep-alive waiting, proxy I/O, and application work have different timeout controls and supported modules. A long backend response does not justify weakening slow-request reading protections, and a short keep-alive wait does not bound every application operation. Identify the failing phase and desired cancellation semantics. Retrying a non-idempotent backend request after a timeout can duplicate business effects. Use bounded owner-reviewed budgets and preserve unknown completion rather than treating a client timeout as proof nothing happened.

Calculate slots and a limited queueing estimate

The complete local program below multiplies the declared thread counts and computes average in-flight work from a stable hypothetical arrival rate and mean time using a simple queueing identity. It is not a benchmark, load test, memory model, or Apache scheduler. Steady-state averages do not capture burst tails or failure behavior. A real review must validate assumptions and service constraints. Use calculations to identify questions, then compare meaningful authorized evidence while preserving error, latency, stability, and trust requirements.

python A synthetic slot and in-flight calculation

processes = 4
threads_per_process = 25
arrival_per_second = 20
mean_seconds = 0.5
print(processes * threads_per_process)
print(f"{arrival_per_second * mean_seconds:.1f}")

Expected output

100
10.0

The result is one hundred model slots and ten average in-flight operations under the stated steady assumptions. No traffic, load, process, thread, timeout, or performance measurement occurs.

Common errors and fixes

MaxRequestWorkers is described as guaranteed requests per second.

Why it happens: Concurrency was confused with throughput and service time.
How to fix it: Relate capacity to actual workload, duration, and backend limits.
Prevent it next time: Keep units and assumptions explicit in capacity reviews.

All timeout values are increased for one slow response.

Why it happens: Different protocol and application phases were collapsed.
How to fix it: Identify the delayed phase and review its bounded contract.
Prevent it next time: Evaluate request reading, idle waiting, backend work, and retries separately.

A larger worker ceiling overloads the backend.

Why it happens: Frontend capacity was changed without end-to-end limits.
How to fix it: Review bottlenecks, queueing, and downstream capability with owners.
Prevent it next time: Use stability and resource guardrails alongside latency.

Check your understanding

1. Does the model’s one hundred slots prove one hundred requests per second?

Show worked solution

No. Slots describe a limited concurrency model. Throughput depends on service time, workload, resource availability, protocols, and downstream constraints. The separate ten-operation average is also a hypothetical steady-state calculation, not observed capacity.

2. Why is a client timeout not sufficient reason to retry a purchase request?