Apache MPM Worker Calculator

In the past I felt as though I was guessing when sizing Apache. Pick something that seemed like it might be enough (MaxRequestWorkers) and then wait for a traffic spike. When the traffic hit, you’d watch memory get swapped or see a flood of 503 errors denying requests. You could tweak one variable at a time. It worked back in the day but it’s slow and risky.

Understanding the interactions between memory, processes, and threads is what moddern tuning is all about. That’s where the heart of Apache configuration lies: balancing its two competing needs; concurrency and resources. Each open connection take up a worker slot; each slot use memory. Too many? Out of ram. Too few? Dropping connections.

How to Set Up Apache Server Settings Correctly

Enter the number cruncher. Input your server specs into the calculator above and it’ll do the math for you. Those numbers won’t matter until you understand them. They are the difference between fragility and stability. This isn’t a limit you’re setting, this is the shape you’re giving to your capacity.

That’s when you run out of memory. This usually happens because each of your Apache child process uses some space, and each of those threads in that process use more, which is heavily impacted by average amount of memory each thread consumes. The thread memory input is really important here. A static file server may not eat much memory at all per thread. But a PHP app on the other hand that’s either being proxied or run as mod_php can be eating quite a lot per connection. Underestimate this number and you’ll have a perfectly reasonable-looking number of workers…until the world comes crashing down around your ears.

Also keep in mind you’re going to want some memory reserved for whatever database engines is co-located on the same hardware, plus memory for the operating system itself. Run out of memory for the OS and it’ll start swapping and thrashing. This will kill your performance sooner then a low worker count ever would.

How you think about idle connections differs based off concurrency model. One process per connection is pretty straightforward, but it’s also heavyweight (prefork). Multiple requests per process are lighter weight (worker MPM uses threads) and allows for more concurrent requests. Even more lightweight is event MPM, which handles keepalive connections asynchronously so an idle client doesn’t block a worker thread forever. For sites where many browsers hang around after initially loading the main page, this can make a big difference.

You may find yourself thinking “oh I have tons of room; I set my keepalive timeout at 10 minutes”. You haven’t planned for idle clients that leave their sockets open and half your workers is doing nothing but sitting there waiting for them.

There’s also an important (but softer) limit: the CPUs available to you. Sure, you could keep throwing RAM at Apache until the cows come home. But no matter how many threads you spin up, response times will suffer if your server doesn’t have a fast-enough processor to serialize those requests in a timely manner. That’s where the calculator comes into play, it helps account for both the number of cores available as well as expected request rate and average processing time per request. Because it’s not about maxing out CPU use; it’s about making sure that the queue empties faster than it fills up. Having some headroom keeps latencies low during even brief bursts of traffic, and there are always these bursts on any real website.

Other directives such as ThreadsPerChild and ServerLimit is confusing for admins because they appear abstract. This continues until you hit the ceiling. ServerLimit refers to the max number of child processes Apache will spawn. You want it to be big enough to fit in the number of workers you want/need divided by the number of threads per child. If you set ServerLimit low and then increase MaxRequestWorkers, apache just totally disregards your new value and stops at the old one. A waste of troubleshooting time if you ask me. Just another config trap.

The page has a good reference table laying it all out, so now you know how these knobs relate to each other before you restart the service. It’s predictable, not perfect. You don’t care if it hits its peak performance sometimes if it falls over later. You’d prefer a system whose behavior under load is consistent.

If you can measure actual thread memory usage and estimate active connection percentage, you’re moving beyond guesswork into engineering. The calculator gives you a structure. Understanding how traffic flows through your stack helps you verify everything is working correctly. Make sure you size for the peaks. Leave some breathing room for background noise. Keep an eye on what happens when things gets busy. That discipline makes a weak server into a reliable platform.