PHP vs. Node.js: The REAL statistics | Hacker News Reader

PHP vs. Node.js: The REAL statistics

prahladyeri.com

14 pointsprahladyeri24 comments

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

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

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.

I think D lang's vibe.d can take that performance crown with good documentation and some more libraries.

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

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

@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

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.

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.

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.

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

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.

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.

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

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

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

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.

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/ reply if anyone knows something better than that one

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/

Reply on news.ycombinator.com