>> PHP basically runs as CGI. Every time a page is hit, PHP recompiles the whole thing before executing it. Even dev servers for Python toy frameworks don’t act like this.
> Person writing this is not very experienced, because this hasn't been the norm for a long time.
I’m genuinely curious—what is the norm here now? I see a lot of PHP code, and 90% of it is just setting up the environment from the ground up, while only 10% is the real processing. The good side is being stateless, but the performance penalty is enormous. I still see a lot of file caching (please make this dir 777 for production) to mitigate some of it, but Redis has become remarkably visible over the last years.
Not being a PHP expert, I really need some best practices to point devs to.
Nobody runs PHP in CGI mode, either they go with libapache2_mod_php, where Apache itself does the work or PHP-FPM with Nginx.
Either way you are not going to pay for the PHP process startup cost.
PHP can also cache the interpretations of files so you avoid that cost as well.
And frameworks usually have their own usually file-based caching mechanism.
At the end of the day it's still going to have some costs compared to a single application server model, but for most web apps it's not going to matter, however it greatly simplifies the programming model.
Sure, it’s not pure CGI, just CGI on steroids. But frankly, it hasn’t gone too far. I’ve seen a lot of WordPress plugins with spaghetti code being called on every invoked endpoint. File caching is evil—many PHP devs love using the filesystem to store things, which is pretty nasty under K8s.
But it’s not the language itself, as I was advised. True asynchronous handlers are possible, which is promising.
> Sure, it’s not pure CGI, just CGI on steroids. But frankly, it hasn’t gone too far.
It doesn't need to go far, because it's selling point is that it's easy to learn and use.
The way I see PHP is not as a competitor to Java, .Net, NodeJS or Rust, instead I see it as a platform for non-advanced developers to be able to be able to create things and actually have the whole thing be cheap and sustainable.
> But it’s not the language itself, as I was advised. True asynchronous handlers are possible, which is promising.
The whole point of PHP is that it's single threaded, blocking and from the developer's point of view: your program starts at the request and terminates when the HTTP request is complete, this is what makes it simple to comprehend, if you want async, I would tell you to use something like Node instead.
> File caching is evil—many PHP devs love using the filesystem to store things, which is pretty nasty under K8s.
It's usually just an annoyance or just something you need to configure or just brute force it with a shared mount.
> I’ve seen a lot of WordPress plugins with spaghetti code being called on every invoked endpoint.
That's not really the problem of the language itself, the language doesn't force you to run anything on every request.
If you are concerned about request startup times (which is not the problem in most cases, cause db io is usually the bottleneck) you can look up the following swoole, octane, hyperf, frankenphp. Haven't used all of them in production but had good experience with swoole.
> Person writing this is not very experienced, because this hasn't been the norm for a long time.
I’m genuinely curious—what is the norm here now? I see a lot of PHP code, and 90% of it is just setting up the environment from the ground up, while only 10% is the real processing. The good side is being stateless, but the performance penalty is enormous. I still see a lot of file caching (please make this dir 777 for production) to mitigate some of it, but Redis has become remarkably visible over the last years.
Not being a PHP expert, I really need some best practices to point devs to.