
PHP vs. Node.js: The REAL statistics - prahladyeri
http://www.prahladyeri.com/2014/06/php-vs-node-js-real-statistics/
======
TimWolla
> PHP might be still having the “king of web” status, but with node.js in the
> town, I don’t see that status staying for very long!

I doubt that. PHP will stay because of Path dependency, most webhosters
provide PHP, because software is written in PHP. Software is written in PHP,
because it is most widely supported. I like node better, though.

~~~
mtdewcmu
PHP is a lot easier to use. Which is pretty much why it's already king.

------
daveslash
_The truth is out. node.js was faster than PHP by more 14 times! These results
are astonishing. It simply means that node.js IS going to be THE de-facto
standard for writing performance driven apps in the upcoming future, there is
no doubt about it!_

While I enjoyed the benchmark test, I believe the conclusion that this is
going to be de-facto as a result of it's high performance is a bit premature.
There are so many factors (both right and wrong) that contribute to the
widespread adoption to a language/framework/technology, performance often
being less important than you'd at first think.

EDIT: I'm not suggestion node will or will not be a de-facto. I'm suggesting
that the factors contributing to a languages widespread adoption are varied
and complex.

~~~
prahladyeri
>>I'm suggesting that the factors contributing to a languages widespread
adoption are varied and complex.

Yup, thats true, and being performance oriented isn't the only selling-point
for node.js. The fact that all node apps are single-threaded (and thus
conserve cpu capacity), combined with the functional-programming approach of
javascript (which makes things like async I/O easier, don't hurt either.

~~~
sportanova
I wouldn't say that single-threaded is a good thing, or that JavaScript is a
functional language

~~~
prahladyeri
@sportanova - If callbacks are available for everything, then what is th need
for multi-threading. You can handle everything in your own thread. When
required, runtime will give you a callback.

JavaScript indeed has functional programming features. See:
[https://en.wikipedia.org/wiki/Javascript](https://en.wikipedia.org/wiki/Javascript)

~~~
sportanova
1) While it's possible to take advantage of multiple cores with Node, it's
easier to do it with a system that supports multi-threading out of the box.
Node's event loop model (and interface, in the form of callbacks) works well
for IO intensive purposes, but hardly obviates the use of multi-threading
(especially when some CPU intensive processing comes into play). 2) I think
functional programming languages are best viewed on a spectrum, and Javascript
falls pretty low on the spectrum. Higher than Java, but far behind Scala and
way, way behind Haskell. It has closures and higher order functions, but so
does Java 8, and I wouldn't call Java a functional language. Off the top of my
head it's missing immutability, referential transparency, pattern matching,
lazy evaluation, tail recursion, and monadic structures. Just because a
language has or is missing a few of these doesn't mean it is / isn't
functional, but relatively speaking, Javascript is pretty low on the spectrum.

------
ksherlock
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?

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

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

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

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

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

------
ttty
Some time ago at school the teacher asked to make a crawler so, as always I do
it in node.js and mongodb. The site to crawl has around 80K pages and 300
records on each page. My script crawled and saved all that data (80K * 300) in
less than 1 hour with around 100 concurrent requests. The other students that
wrote in ruby, python and php took days to do the same thing. Also they had to
do by parts because if they requested all by once their pc would crash because
of memory.

Also I didn’t need any test because since the first time I ran node.js it was
instant fast, not like php, ruby or python.

~~~
prahladyeri
Yup. And thats only because of precious CPU time saved by doing async I/O
which the functional paradigm of JavaScript supports so well.

~~~
frowaway001
I really can't figure out whether you two guys are trolling. Thinking about
it, I actually hope so, because everything else would be embarrassing.

------
keithnoizu
If you're really worried about performance just look at chicago boss or raw
Yaws with Erlang and or Elixir.

The real question for most projects should be which is faster to develop with
and has a better ecosystem.

------
hamburglar
Wow, is this a parody? The lack of rockstar ninja references is confusing me.

"Hey guys, I was wondering if node really is faster than PHP, so I checked. It
is! End of story."

------
gexla
As long as there is software built in PHP which are used by huge numbers of
people (Wordpress, Drupal, etc) then it will continue to be important to huge
numbers of people.

For many of the people using these tools, the benchmarks don't matter. Most
people do okay with their Wordpress or Drupal sites. Application developers
understand that the limitations of attempting to use a CMS as a platform and
they have wide choices (not just PHP or Node.)

------
codygman
Just for fun, here's an unoptimized and un-async'd haskell version I threw
together:

[http://lpaste.net/105557](http://lpaste.net/105557)

It takes about a second. I expected it to be faster than node and php, but it
being this much faster makes me think I got something wrong. The files
generated aren't all the same.

------
pmelnichuk
The really approximated excluding concrete version information and using only
read and write to disk commands statistics*

Personally i prefer
[http://www.techempower.com/benchmarks/](http://www.techempower.com/benchmarks/)
reply if anyone knows something better than that one

------
Bostwick
I'd like to see the author make an attempt with the React library [1] in PHP
as well. You don't have to abandon your language of choice to gain the ability
to do asynchronous I/O.

[1] [http://reactphp.org/](http://reactphp.org/)

