I was under the impression that PHP's stateless nature, with a whole new instance of everything coming into being for each request, somewhat sidesteps the capacity for problematic memory leaks that could otherwise exist for processes that remain alive between requests.
A couple issues here.
1. Even if the PHP process exits after each request, memory leaks during the request are still an issue. If I'm looping through 1,000 elements of an array and leaking memory each time, I could end up with a peak memory usage of 100MB when 1MB would've sufficed. That forces me to scale vertically when I might not otherwise need to.
2. Most mature applications have worker processes that may be longer-lived than serving an HTTP request. If PHP leaks memory, it's less suited to those tasks. Maybe you write those in Go instead, but then you have to ask yourself why you didn't just write the whole application in Go.
2. There's a large amount of PHP libraries built to do exactly what you're describing. Long lived PHP processes are live in production across the world.
Straight up misinformation.
> This is likely user error due to a poor understanding of how PHP memory management works.
This is not what the comment I responding to was talking about. They were talking about memory leaks that were not in userspace. PHP's bug tracker has 943 bugs related to memory leaks[1]. That has nothing to do with understanding "how PHP memory management works".
> Unless you're using poorly written extensions then memory management in PHP is quite straightforward.
How exactly do you know whether an extension is poorly written? In many cases, it doesn't matter because there's exactly one extension that does what you need.
You could also be using poorly-written libraries.
> There's a large amount of PHP libraries built to do exactly what you're describing. Long lived PHP processes are live in production across the world.
I know. I use some, and I have several long-lived PHP processes running right now.
If a memory leak is in PHP itself, no library can fix it.
> Straight up misinformation.
Disagreeing with someone (or not understanding them) doesn't mean they're spreading misinformation.
My point was that memory leaks in the PHP virtual machine are still a problem even if PHP usually runs statelessly. Do you disagree?
1. https://bugs.php.net/search.php?search_for=leak&boolean=0&li...
*not to take sole credit. I created RPC framework and initial API, and oversaw a small team of very talented engineers who added a significant chunk of the functionality powering Grooveshark over the years
I usually have to resort to queues, which just adds complexity where I typically don't want it.
I do assume it's not the case, but one of the footguns with PHP is that assigning around large variables/arrays and triggering the copy-on-write can end building up the amount of duplicates of that data being kept alive. Pass by reference, unsets, generators and the like aren't used super often due to a lot of runs being small stateless requests, but sometimes they may be needed.
Ultimately I’ve had less issues with Python for this type of workload and is eventually where we moved.