There are claims this is faster. It's not. I used it, together with other "alternative" runtimes which are just PHP command line interface long running scripts with some sort of task distribution balancer in front. Just like PHP-FPM is.
The apparent speedup comes from the fact it's not shared-nothing, meaning that objects from previous requests (and variables) are persisted and present in subsequent requests. This makes it work exactly like Node.js, removing the wonderful part of PHP which is that it automatically cleans up all the crap devs created and creates clean slate when next request is to be executed.
All of these "alternative" runtimes are false positives, because they're quick for first few requests but get slower and slower for the subsequent ones. Then, the workers are killed and restarted (precisely what PHP-FPM does too).
Since there's no new engine behind executing PHP, the only way FrankenPHP (and others) can yield any performance is when they're benchmarked against misconfigured PHP-FPM (opcache off, JIT off, persistent connections off).
It's not my cup of tea. I like that there are attempts at doing <something> but turning PHP execution model into Node.js execution model isn't the way to go.
I find it cheaper to throw a few bucks at stronger hardware compared to risking accurate execution to become flaky because shared-nothing is now unavailable.
It doesn't even depend. The underlying engine that executes opcodes is the same. Minimal speedup from not having to execute several "new objectname" commands isn't even a drop in the sea when it comes to what servers do.
I, for one, would love to be wrong about this and that FrankenPHP with all the other alternative runtimes actually brought benefits.
It absolutely does depend and "several new" might be "thousands new". It literally depends on what you're doing.
> The underlying engine that executes opcodes is the same.
Not exactly. FrankenPHP uses a ZTS build of PHP, which includes thread-support. Meaning you can actually spawn real-life threads in your PHP code with just a bit of work.
I've actually been working on a Parallel drop-in replacement that uses FrankenPHP/go instead of maintaining its own thread system.
It's obvious you have no idea what ZTS build of PHP does and you're just spewing nonsense at this point.
Creating a few thousand "new object" takes less than 5 msec. Test it. I have.
FrankenPHP uses a Go-based balancer that distributes requests to array of pre-started workers. Just like PHP-FPM does.
If you already used PHP's parallel extension, then you should at least know the difference between thread and process instead of typing buzzwords, thinking it makes you look cool if you use them :)
As a part-time contributor on FrankenPHP, from fixing bugs on PHP-src, and implementor of RFCs, I can assure you: I know what I'm talking about.
> Creating a few thousand "new object" takes less than 5 msec.
It depends on what you're doing in the constructor as to how long it takes.
> FrankenPHP uses a Go-based balancer that distributes requests to array of pre-started workers. Just like PHP-FPM does.
No, it doesn't work anything like FPM. Like, at all. There's basically nothing in common between FPM and FrankenPHP. (at least until I merge this next PR for non-worker requests that makes it work like FPM for non-worker requests)
The apparent speedup comes from the fact it's not shared-nothing, meaning that objects from previous requests (and variables) are persisted and present in subsequent requests. This makes it work exactly like Node.js, removing the wonderful part of PHP which is that it automatically cleans up all the crap devs created and creates clean slate when next request is to be executed.
All of these "alternative" runtimes are false positives, because they're quick for first few requests but get slower and slower for the subsequent ones. Then, the workers are killed and restarted (precisely what PHP-FPM does too).
Since there's no new engine behind executing PHP, the only way FrankenPHP (and others) can yield any performance is when they're benchmarked against misconfigured PHP-FPM (opcache off, JIT off, persistent connections off).
It's not my cup of tea. I like that there are attempts at doing <something> but turning PHP execution model into Node.js execution model isn't the way to go.
I find it cheaper to throw a few bucks at stronger hardware compared to risking accurate execution to become flaky because shared-nothing is now unavailable.