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
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.