Recently on the Fediverse, someone wondered if an out of the box build of Apache (with minimal tuning) could handle 10,000 simultaneous HTTP requests (the old famous 'C10K' target, which definitely was a challenge back in the days). We happen to have a web server that has hit 4,000 simultaneous requests (well, sort of, see later) with every indication that the people (well, programs) that were hitting it would have gone higher than 4,000 if the connection limit was higher. Since that high-water mark we've put an assortment of limits on the web server that cut the connections right down , but if I removed those connection limits in a spirit of experimentation perhaps we'd get to find out how high our Apache setup could go.
(I wouldn't normally experiment with a production service but we don't consider this particular service very important. If it falls over sufficiently often that people start keeping their own copies of the data instead of re-downloading it from us repeatedly, that's a feature.)
The specific configuration of this web server is Ubuntu 24.04 LTS with the standard Ubuntu Apache on a server with 16 GB of RAM, the event MPM , and non-standard settings of:
MaxRequestWorkers 11000 ServerLimit 768
(That's far more processes than we need, but HTTP requests linger around a lot on this server and I was aiming for overkill for a quick test.)
Apache (re)started fine with these settings and is running fine, but I can't say that it stands up to 10,000 connections, at least not yet, because contrary to the previous client behavior (where lots of simultaneous requests would flood in the moment they could), now the number of connections hovers around only 2,000 to 3,000, and sometimes dips lower for an extended time (where 'lower' here is still on the order of 1,500 connections). At one level it's good that people have stopped hammering on this server so much, but at another level it's slightly inconvenient that everyone is being reasonable at the very moment I'd be happy with a stress test.
Also, I have to correct my previous entry when I said we were limiting things to 4,000 connections. Actually, we were tracking and limiting the number of active workers (with a setting of 'MaxRequestWorkers 4000'), rather than the number of connections; I forgot or overlooked that the event MPM allows more connections than you have workers under the right circumstances. When we were hitting the worker limit, it appears that we peaked at around 5,300 simultaneous connections. Presumably the 1,300 or so extra connections were in some state that a worker could handle alongside its other activity.
(The graph I was reading reported the number of workers because that's normally what's important for us; among other things, if Apache runs out of workers it stop answering new requests (including requests to scrape its server status ).)
One little lesson I take from this learning experience is that the question of "can Apache handle 10,000 connections" is potentially a little under-specified. At least with the event MPM , there's a potentially big difference between 10,000 active workers and 10,000 connections, a significant number of which aren't taking up a worker. How many such non-worker connections you have may depend on what sort of thing you're serving and how you expect HTTP clients to behave when talking to you (and I suspect this server is on the high side, since people are downloading large files from it).
PS: Since I looked at this in our metrics system , most of the time this particular server has only a "modest" difference between busy workers and current connections with a few hundred more connections. But every so often the difference briefly peaked at a bit over 4,000 of them, perhaps due to Apache shutting down and restarting (or just reloading itself).