I'm hosting a non-profit community wiki for the upcoming video game Baldur's Gate 3. Since it looks like the game is likely to have millions of players, we started worrying about server capacity.
I'm on Apache 2.4.57 (latest stable), using the following mpm_event.conf right now, subject to further change:
ServerLimit 8
StartServers 2
ThreadLimit 32
ThreadsPerChild 32
MaxRequestWorkers 256
MinSpareThreads 32
MaxSpareThreads 128
MaxConnectionsPerChild 0
So, Apache should at any point have a maximum of 256 worker threads. Together with 8 main threads per MPM process and one root main process, that gives us a grant total of 265. (Maybe a couple more for other reasons, but the maximum should be in that ballpark anyway.)
Yet when I stimulate maximum load (ab -n 1500 -c 500 <url>) and see the status page served by mod_status indicate a full 256 workers, the command pgrep -wc apache returns a whopping 632.
I've also used the commands pgrep -wal apache | wc -l and ps -eL | grep -c apache with pretty much equivalent results, so I think my apache thread counting method should be accurate?
What could be the explanation of this?
The maximum number of threads on my system is limited by my "VPS" (not a real VPS, but rather a cheap container) to a total of 1100, so it's very important for me to know how many threads Apache will really be creating with a given configuration.
Could this have something to do with PHP FPM? My FPM's pool.d/www.conf currently contains the following (has not yet been tweaked to match the mpm_event settings):
pm = dynamic
pm.max_children = 5
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 3
Even if each worker had an additional thread related to PHP, that would give us 512 threads, plus the few others mentioned earlier (MPM main threads + root process thread) for a total of 521, thus still leaving 112 threads unaccounted for.
The PHP version is 8.1.2-1ubuntu2.13.
