PHP Scaling Notes

PHP Scaling Notes
* Keeping latency down is #1 priority when using PHP.
   * Lots of workers = thread swapping will tank CPU.
   * 100-200 workers = they will all fill up and CPU will be unused.
* Ideally you just want to keep most requests UNDER 1 Second.
   * Best under 0.1 Second. You start to hit Sqlite cap at that point.
   * “Jobs” would just be a cron that runs in the background one at a time.
   * Every page that goes over this latency will become a bottleneck.
* Most efficient by far for low-blocking is one big static FPM process.
   * Adjusting static pm.max_children is superior to multiple VM’s.
   * The best strategy is to max out green bars in htop by adjusting max_children based on average request time. 
   * 100 is ideal for sub-0.1 second requests.
   * 100-500 is ideal for 0.1 second requests.
   * 500-1000 is ideal for typical 1 second requests.
   * Diminishing returns above 1500 (thread swapping death).
   * You will top out at 500-1000 if your requests take 1 second.
      * 1000-2000 if your requests take 0.5 seconds.
* 🟣 Multiple VM strategy works well for highly blocking PHP requests (>5 Seconds).
   * 🔴 Still, you’re going to be capped around 300-400 R/S on an 8 core machine.
* 🔴 CGroups / SystemD: Was not able to get to act like a VM. ): Tried a bunch of settings.
* 🔴 nice, renice, etc. No luck at all.
* 🔴 Multiple php-fpm instances do not help.

On the bright side, PHP when properly configured with caddy or nginx won't drop connections under severe load, it will just queue the requests and be slow.

This is not a bad feature as many "all in one process" async technologies will just crash.