In Apache httpd running mpm_event, how do MaxRequestWorkers, ServerLimit and ThreadsPerChild relate, and what happens if you set MaxRequestWorkers higher than ServerLimit multiplied by ThreadsPerChild?

## The four numbers Under a threaded MPM, Apache's concurrency is not one dial but a small system of them: - `ThreadsPerChild` — request-handling threads inside each child process. Fixed for the life of a child. - `ServerLimit` — the hard upper bound on the number of child processes the parent may ever create. - `ThreadLimit` — the hard upper bound on what `ThreadsPerChild` may be set to. - `MaxRequestWorkers` — the total number of worker threads that may be serving requests at once, across all children. This is the number that actually caps simultaneous request processing. ```apacheconf <IfModule mpm_event_module> StartServers 4 MinSpareThreads 75 MaxSpareThreads 250 ThreadsPerChild 25 ServerLimit 16 MaxRequestWorkers 400 MaxConnectionsPerChild 0 </IfModule> ``` Here `16 × 25 = 400`, so `MaxRequestWorkers 400` is exactly reachable. That consistency is the point of the block. ## What goes wrong when the arithmetic does not hold Set `MaxRequestWorkers 1000` while leaving `ServerLimit 16` and `ThreadsPerChild 25` and httpd does not refuse to start. It writes a warning to the error log along the lines of *MaxRequestWorkers of 1000 exceeds ServerLimit value of 16 servers, decreasing MaxRequestWorkers to 400 — to increase, please see the ServerLimit directive*, and then serves traffic with an effective ceiling of 400. The configuration file says 1000, the running server means 400, and unless someone reads the log at startup nobody notices until the day traffic reaches 400 and requests begin queueing. The reason is structural rather than arbitrary: worker threads only exist inside children, the parent will not create more children than `ServerLimit`, and each child has exactly `ThreadsPerChild` of them. `ServerLimit × ThreadsPerChild` is therefore the physical maximum number of worker threads that can exist, and `MaxRequestWorkers` cannot exceed a quantity that cannot be built. The same shape applies to `ThreadLimit`: raising `ThreadsPerChild` above `ThreadLimit` is capped in the same way. And under `mpm_prefork` the product collapses, because a child has one thread — there `MaxRequestWorkers` simply cannot exceed `ServerLimit`, and the two are usually set to the same value. ## Why the limits exist separately at all `ServerLimit` and `ThreadLimit` exist because they size shared structures the parent allocates once at startup — most visibly the scoreboard that tracks every worker slot. That is why they can only be changed by a full stop and start: a graceful restart keeps the parent process alive and cannot resize what it already allocated. Raising them far beyond what you need is not free, since the parent reserves for the maximum. So the intended discipline is: choose the concurrency you actually want, set `MaxRequestWorkers` to it, then set `ServerLimit` to `MaxRequestWorkers / ThreadsPerChild` rounded up — not to some very large number so that you never have to think about it. ## Which number should move When you decide you need more concurrency, you have two ways to get it, and they are not equivalent. Raising `ThreadsPerChild` gives each child more threads: fewer processes, less per-process overhead, but a larger blast radius because a crash takes all threads in that child down with it. Raising `ServerLimit` gives you more children: more isolation, more process overhead. Most tuning guidance keeps `ThreadsPerChild` at a moderate value (25 is a common default) and moves `ServerLimit`, so that no single child holds too much of your capacity. `StartServers`, `MinSpareThreads` and `MaxSpareThreads` are a different category entirely — they do not change the ceiling, only how eagerly the parent forks toward it and how much idle capacity it keeps in reserve. A server that is slow to absorb a traffic spike usually needs a higher `MinSpareThreads`, not a higher `MaxRequestWorkers`. ## The name `MaxRequestWorkers` was called `MaxClients` in older versions and the old name still works as an alias, which is why so much surviving documentation and so many copied config snippets use it. If you see `MaxClients` in a modern config, it is the same dial under its old name — and it is a useful signal that the block was copied from advice written for a different era, and possibly for a different MPM.