Hi Ewan,
I’ve answered similar questions regarding the way connections are handled in a dynamic language / FastCGI context.
- PHP-fpm creating too many connections
- Aerospike server got very high CPU usage when using with the php-client
- Connections stuck in CLOSE_WAIT
- The Client Creates 17 Threads for Each PHP Process
FPM tuning is something straight out of the late 90s, back when PHP leaked memory and the php_mod process inside Apache would bloat to a dangerous level. PHP has been very stable on memory for a long time, and the idea of killing the process after only 500 requests is a head scratcher. You’re potentially going to be doing thousands of requests per-second, why would you choose to kill and fork a new process after so few requests?
It’s not just the overhead of the PHP process forking by FPM. There’s also an overhead to initializing the Aerospike client. It connects to the first node it can in a list of hostnames, and from that seed node it:
- Learns the IP addresses of the other nodes.
- Establishes connections to the service port (3000) on each of those nodes.
- Grabs the partition map.
- Starts a cluster tending thread which periodically (by default every 1s) checks on the cluster.
For this reason, we recommend using persistent connections when you’re in any multi-process context (FPM, Apache prefork, etc). The Aerospike object is stored in the process scope and does not get destroyed at the end of the request (PHP_RSHUTDOWN). Next request executing the same code will attempt to reuse this object. To amortize the overhead of initializing the client you should raise the max_requests as high as you can. Track the PHP processes for memory bloat, and keep raising the value, the higher the better. If you notice a memory leak please report it as a bug on the aerospike/aerospike-client-php repo on GitHub.