4 ms·
PHP 7 is probably going to be faster than Node.js and Python. Arguably, it is also more approachable to host it. Easier to find developers for it.
by amq 9y ago
PHP 7 is probably going to be faster than Node.js and Python. Arguably, it is also more approachable to host it. Easier to find developers for it.
- joshribakoff 9y agoBut 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
- tyingq 9y ago"spinning up a new process for every request" 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.
- repsilat 9y agoSome 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...)
- tyingq 9y agoThe 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. Buzzword bingo and all...
- andybak 9y agoLambda 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?
- andrewmackrodt 9y agoThere are interesting projects such as https://github.com/php-pm/php-pm 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.
- amq 9y agoI'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.
- andrewmackrodt 9y agophp-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.
- cutler 9y agoOn my 4-year-old MacBook Pro PHP 7.2 is 4 times as fast as Python 3.6 for parsing log files with a regex.