I agree, the main problem with PHP in my experience so far has been that it's very memory-hungry and slow (even PHP7/8), especially when coupled with frameworks/ORM magic.
I remember after spending some time with Go, I got used to being able to process tens of thousands objects in memory in milliseconds. When I proposed to do the same in PHP, during architecture review, PHP devs thought I'm out of my mind because that would take like a gig of RAM (which would compete with other PHP processes on the server) and considerable amount of time. You have to use a lot of hacks to make it all fit in memory and be fast.
Our Symfony framework also initializes in like 300 ms on each request, while in Go it's below 10 ms. As every PHP process dies after serving a request, you have to reinitialize the whole dependency container on each request from scratch, and in large enterprise applications, that's a lot of dependencies.
FWIW: There are a bunch of ways to "do" php execution, and a lot of them are wrong. That's not exactly PHP's fault, just that there's been a lot of blind-leading-the-blind.
Assuming that you're not spinning up and tearing down a container for every request, you want to be sure you're running php with a php-fpm configuration (preferably talking over a unix socket) -- this is the fastcgi process manager, which maintains a pool of "hot" php interpreters for you that are immediately ready to execute code for an inbound request. This is usually good enough for most applications without going into the weeds on things like opcode caching, but that's all available as options too.
I'd be happy to help troubleshoot this with you if you're interested. I've also got a fully automated build script that works pretty well. You can find my contact info via the link in my profile. I promise it doesn't have to take anywhere near 300ms for php to reply to a request.
My experience is that Symfony, in its fat, batteries-included form, does take quite long time to initialize on cold caches. The first request can take hundreds of milliseconds but usually the very next request is in the normal 10ms range. This is especially noticeable on (cheap) shared hosting which has always been a common place to run PHP.
I've never found it to be a problem on a VPS but if you're developing on something slow like a Raspberry Pi I can see this happening regularly. If you're used to deploying stuff in containers and constantly throw out the cache the initialisation problem can happen very easily as well.
IIRC back in symfony 1 part of it was becasue symfony used the first request to write optimized versions of the code into a folder that I cannot remember the name of.
I think there was a way to do this up front in Symfony 1 and there might be some way to do this as part of a build and deploy step. Of course on applications with less traffic and less strict requirements just hooking something up to run a request immediately after deploy might work just as well, but if it runs across n small pods it might be a much better idea to do it on a beefy build machine instead of on n resource constrained pods causing slow loading for n customers.
That 300ms initialization time sounds like a cache-free execution (aka dev mode). I have symfony projects light on ORM usage (I dislike Doctrine from the bottom of my hearth, but what can you do it's the blessed symfony ORM) and after a cache warmup it handles requests under 100ms.
Yes, the frameworks have obscene (java-like) class dependencies that build up during initialization (I'd prefer if there'd be a lighter function based framework nowadays), however for someone that knows how to manage PHP on the server there are OPCache tweaks, preloading facilities which help improve the request initialization performane (these steps are also expanded on in the symfony docs).
The share-nothing arhitecture of each request is either a benefit or a downside, depending who you ask.
It does run with caches enabled, my memory is murky but I remember Go processing requests on an order of magnitude faster (10x). Maybe it's about dependencies reconnecting on each request, or the large amount of classes in the monolith? I remember marking dependencies as "lazy load" helps.
>there are OPCache tweaks, preloading facilities which help improve the request initialization performance
I remember we disabled some of the settings for preload because we hit a bug which manifested as a segfault due to PHP's shared memory space for preload getting corrupted under a high load.
In any case, everything is fast and usually doesn't require a lot of tuning in Go out of the box.
However, I do love PHP's shared nothing architecture for the reasons of memory isolation: we have thousands of B2B tenants and with PHP, I'm confident we won't accidentally spill one company's data into another company's account. Things like when ChatGPT exposed your conversations to random people because a bug in the Redis connection pool inside Python's shared memory space returned a connection for a different user, due to a race condition.
Well, that's the problem with all PHP frameworks: they're written in PHP! Yes, PHP has gotten faster thanks to OPCache and other tricks, but still, the less time your application spends executing PHP code, the faster it will be. And frameworks like Laravel just pile on additional PHP code to execute like there's no tomorrow. I mean, just look at the callstack when an exception happens...
I was running tens of thousands of jobs an hour with an asynchronous AWS SQS job dispatcher written in php that would launch php sub processes on the CLI. Super fast. Was able to get by with a very modest ec2 instance ($20/month) handling jobs for 300k users. Was auto scaling too.
PHP 8.x has a ton of performance improvements that make what you're saying sort of not relevant anymore. I prefer PHP over Python these days on the Linux CLI. The code is cleaner.
We do a lot of work with large datasets. PHP 7&8 are so much better than 5 in terms of memory usage for large datasets.
Its not magic though, and I'm not surprised a compiled executable is many times faster, especially for math heavy stuff. Slow is often "good enough" though and deploying is quite straight forward.
I’ve written PHP apps that process millions of entities without issue at my old job. We didn’t use an ORM or anything magic. At my current job, using an ORM, my code has twice as much memory yet I can only load a few thousand entities before OOMing.
If you’re willing to give up magic, it’s worth it.
What you are describing only happens in dev environment
The Symfony container does not rebuild in production and requests should easily be served within 5-10ms as well so you might want to check your deployment pipeline and that you correctly composer dump-env prod
The way developers are encouraged to structure PHP projects (mainly due to autoloader semantics) always felt more like Java or .NET to me than it did like python. The resource consumption comparison between a Symfony web app vs the same thing written in ASP.NET or Spring Boot has a pretty clear winner, and it's not PHP.
You're doing something terribly wrong. Sounds like caching isn't setup and your http -> php handler is cold booting the interpreter for every single request.
Check these Go vs. PHP benchmarks. PHP is quite fast and stands up nicely to the performance you get out of Go.
All i see is that the php fpm based frameworks (e.g. laravel) are 100x - 300x slower. And this is the best case scenario. When projects grow, php-fpm gets slower and slower. Which is not the case for go. Im not a go-fanboy, my entire carreer has been in PHP. Im just saying, PHP is one of the most terrible languages for web servers. And it's all php-fpm's fault. On top of that, the PHP community seems to promote OOP and SOLID which are the last design patterns you want to combine with php-fpm. There's a reason why facebook created their own PHP transpiler.
Isn't that synthetic benchmarks for toy projects? The amount of code which is run on every request grows with the size of the project in PHP/Symfony (which can take quite some time in a huge monolith), while in Go, everything is usually initialized once at startup.
I remember after spending some time with Go, I got used to being able to process tens of thousands objects in memory in milliseconds. When I proposed to do the same in PHP, during architecture review, PHP devs thought I'm out of my mind because that would take like a gig of RAM (which would compete with other PHP processes on the server) and considerable amount of time. You have to use a lot of hacks to make it all fit in memory and be fast.
Our Symfony framework also initializes in like 300 ms on each request, while in Go it's below 10 ms. As every PHP process dies after serving a request, you have to reinitialize the whole dependency container on each request from scratch, and in large enterprise applications, that's a lot of dependencies.