But php is going to have some inherent latency starting up a process for each request and an overhead of spinning up a new process for every request. If you need speed you shouldn't use any of three languages you just mentioned though. These days I think it's easier to find nodeJS developers. You can take a frontend developer and teach them nodeJS very quickly also. It's arguably just as easy to proxy from nginx as it is to setup a PHP sapi
It's not that bad anymore. We do have fcgi, fpm, and also
user space caches like apcu. You would have to try pretty hard to find a default set up that resulted in process per request these days.
It scales very well on a single host. Which has limits, but limits that exceed some percentile that most projects need. And things like redis take it even further. If you're pushing the limits of php, you probably have a nice-to-have problem tied to lots of incoming revenue. Similar to FB and HHVM.
I agree there's a scaling issue, but nobody is doing process per request anymore. Process pooling is a decade old or more.
Some people now boot an OS to serve each request, and reinstall the OS to deploy new changes. It's funny, even the objections to PHP haven't kept up with the trendy software practices.
I guess the objection to "spinning up a process" is actually a problem with slow PHP initialisation, though? A dinky server can spin up many thousands of processes a second. I'm pretty sure OS process overhead is nothing compared to whatever PHP or Rails or whatever else puts into your critical path, but the language/library/parsing requirements could kill you. (Though people still make this objection to CGI itself, not just PHP...)
The php "maybe process per request, if I'm being dumb, but probably not", vs AWS lambda "business as usual, here is a whole new os instance" is pretty amusing.
Lambda surely doesn't actually boot a new OS for every single request. I thought it stuck around for a set amount of time and you could even ping it to keep it warm?
There are interesting projects such as https://github.com/php-pm/php-pm which sets up a pool of 'warmed' workers to speed this up; I've never used that particular project in production but the approach seems reasonable, many of us are probably already handling background jobs using a similar architecture.
I'm using php-fpm with all production services since 2012 (mainly with nginx, but also with apache), never experienced any problems, so I'd highly recommend trying it out.
php-pm is very different to fpm, imagine running a heavy framework like laravel where it can take 100 ms to bootstrap a request; why not use a worker pool and delegate the request to it? that's php-pm.
