It's not really a node vs php comparison, it's a node vs apache/php/unknown config comparison. HHVM can be 40-80 times faster than php for some benchmarks. Maybe try that?
HHVM still isn't perfectly compatible with PHP. I think the I recently experimented with migrating a fairly complex WordPress site to HHVM (since it claims 100% WordPress compatibility), and I found that some queries would return different results or silently fail under HHVM. So I think not comparing bleeding-edge stuff like that seems fair. It'll probably be relevant in the not-too-distant future, though.
(For anyone wondering about performance, it served pages about twice as fast on average as PHP-FPM 5.4.4 on the same box, and with drastically lower memory usage in all cases. Didn't delve too much deeper into that, though, since the page not rendering correctly was a showstopper.)
nginx + FastCGI would probably put PHP on a more level playing field.
The test isn't completely invalid, but there is a lot more going on than what is described. It's a bit misleading to say that the server blocks waiting for file_get_contents. Actually, only the thread running the PHP script blocks. Other threads/processes can run. This experiment isn't quite a test of blocking versus non-blocking I/O. It's more a comparison of a heavy apache + PHP stack versus a lightweight, single-function node.js http server, which also probably benefits from non-blocking I/O. But non-blocking I/O is only one of many things that make the node script faster.
>Actually, only the thread running the PHP script blocks. Other threads/processes can run.
Yup. But imagine a situation that suddenly around 10000 requests have arrived at your server and sitting on the queue. Now that "one php thread" suddenly becomes a life-saver.
Indeed. That's what node.js is for. I was just nitpicking the article's explanation.
It would be interesting to see a breakdown of what makes the apache+PHP solution so slow. apache probably eats a lot of time by itself.
Are you using an opcode cache for PHP, like APC? The PHP script is being executed repeatedly, possibly being read, parsed and translated into bytecode each iteration. The Javascript gets compiled once into native code by v8 and just loops.
The opcache is enabled and so is apc (though I don't think caching would matter much in this case).
As for apache eating time, nginx might run a bit faster than apache, but without a proper async I/O model built into the language itself (such as functional javascript), it would still be a band-aid solution.
True. I don't expect that nginx would make them equal. But it would be interesting to gather more evidence to support the hypothesis that async I/O is the difference.
Comments
It's not really a node vs php comparison, it's a node vs apache/php/unknown config comparison. HHVM can be 40-80 times faster than php for some benchmarks. Maybe try that?
HHVM still isn't perfectly compatible with PHP. I think the I recently experimented with migrating a fairly complex WordPress site to HHVM (since it claims 100% WordPress compatibility), and I found that some queries would return different results or silently fail under HHVM. So I think not comparing bleeding-edge stuff like that seems fair. It'll probably be relevant in the not-too-distant future, though.
(For anyone wondering about performance, it served pages about twice as fast on average as PHP-FPM 5.4.4 on the same box, and with drastically lower memory usage in all cases. Didn't delve too much deeper into that, though, since the page not rendering correctly was a showstopper.)
nginx + FastCGI would probably put PHP on a more level playing field.
The test isn't completely invalid, but there is a lot more going on than what is described. It's a bit misleading to say that the server blocks waiting for file_get_contents. Actually, only the thread running the PHP script blocks. Other threads/processes can run. This experiment isn't quite a test of blocking versus non-blocking I/O. It's more a comparison of a heavy apache + PHP stack versus a lightweight, single-function node.js http server, which also probably benefits from non-blocking I/O. But non-blocking I/O is only one of many things that make the node script faster.
Yup. But imagine a situation that suddenly around 10000 requests have arrived at your server and sitting on the queue. Now that "one php thread" suddenly becomes a life-saver.
Indeed. That's what node.js is for. I was just nitpicking the article's explanation.
It would be interesting to see a breakdown of what makes the apache+PHP solution so slow. apache probably eats a lot of time by itself.
Are you using an opcode cache for PHP, like APC? The PHP script is being executed repeatedly, possibly being read, parsed and translated into bytecode each iteration. The Javascript gets compiled once into native code by v8 and just loops.
The opcache is enabled and so is apc (though I don't think caching would matter much in this case).
As for apache eating time, nginx might run a bit faster than apache, but without a proper async I/O model built into the language itself (such as functional javascript), it would still be a band-aid solution.
True. I don't expect that nginx would make them equal. But it would be interesting to gather more evidence to support the hypothesis that async I/O is the difference.