Live data from Hacker News

Benchmarking Codswallop: Node.js vs. PHP

philsturgeon.co.uk

71–80 of 85 posts

Re: Benchmarking Codswallop: Node.js vs. PHP

#71
post #39
post #23

Earlier quoted context omitted.

Node.js is also based around a subpar language, so it's not necessarily the main cause either.

One might argue that Javascript is considerably less sub-par than PHP, though; speaking purely from my own experience, I've found that writing Javascript involves a significantly lower probability of the language attempting, at random intervals, to shatter my kneecaps with a crowbar.

Both languages are painful, and both have a painful stdlib, but JavaScript's stdlib is much, much smaller, ergo less messy.

Re: Benchmarking Codswallop: Node.js vs. PHP

#72
post #67

Earlier quoted context omitted.

First things first, IsaacSchlueter in the thread, wow :) So, I'm stress testing our company Node app to find where we can go with it's performance. First problem was file descriptor, which I fixed with your "graceful-fs" module. But now, I'm reaching some "invisible" limit that I can't identify. My app doesn't return any error in the log. Does "maxSockets" will help to receive more requests also or is just to make re…

What performance problem with FD? How many requests exactly are you handling per second with what code or processing? Are you sure its not what he just mentioned, ulimit? The docs say client requests so yes its just to make them.

I'm handling from 4k to 10k simultaneous requests.

And about the client requests, hmm ok, no problem. I will keep looking. Thanks!

Re: Benchmarking Codswallop: Node.js vs. PHP

#73
post #5

Node benchmark is flawed though. Add something like require('http').globalAgent.maxSockets = 64; at the top of node script if you want a fair comparison with async php version. The bottleneck is bandwidth here. Not the runtime. On my laptop, original script from the author took 35 seconds to complete. With maxAgents = 64, it took 10 seconds. Edit: And who is downvoting this? I just provided actual numbers and a way t…

If we really want to get into benchmarks LuaJIT with multithreading is almost 2x faster then both, it took 21 seconds to complete on my computer. And I'm willing to bet that multithreaded C would be even faster.

However you want to know what this benchmark proves? Absolutely nothing as it has to query a website. So the response time of the website matters more then this test.

Re: Benchmarking Codswallop: Node.js vs. PHP

#74
post #34
post #28

I'm sick of all of these generic SPEED benchmarks. Let me tell you some BIGGEST & REAL benefits of NodeJS where PHP SUCKS. 1. Takes 1 minute to install on any platform (*nix, windows etc.) 2. A modern Package Manager (NPM) works seamlessly with all platforms. 3. All libraries started from 0 with async baked in from day 0. 4. No need to use any 3rd party JSON serialize/deserialize libs. 5. And above all, its Atwood's…

Yet there are no decent XML libraries for node.js. I'd trade decent JSON support for decent XML support every single day of the week. And Scala/Java/JVM have already solved the problems you mention above.

"I'd trade decent JSON support for decent XML support every single day of the week."

Just out of interest, why is that?

I work with JSON at least once a week, but it can be months between moments when I need to work with any XML.

Re: Benchmarking Codswallop: Node.js vs. PHP

#75
post #5

Node benchmark is flawed though. Add something like require('http').globalAgent.maxSockets = 64; at the top of node script if you want a fair comparison with async php version. The bottleneck is bandwidth here. Not the runtime. On my laptop, original script from the author took 35 seconds to complete. With maxAgents = 64, it took 10 seconds. Edit: And who is downvoting this? I just provided actual numbers and a way t…

It think the problem is you are feeding into the same loop. There are also probably ways of making the PHP script go faster still. Also, that seems like a bit of a magic flag to add / tune, why is that not the default, and would I have to keep tuning it for each of my apps?

The article starts the loop though. If tuning one setting is a black are that an inexperienced dev would miss (which it of course is, I don't disagree at all there), then drawing in a new library to work around the limits (in this circumstance) of file_get_contents() is very much so too.

Neither the original benchmark nor the response were well researched IMO. This is the Apache vs IIS wars again, where good benchmarks that reveal useful information were drowned out by the noise of a great any poorly executed (or sometimes completely biased and deliberately poorly constructed), with bad test resulting in a bad result for one side being followed by an equally bad test to try prove the opposite.

Re: Benchmarking Codswallop: Node.js vs. PHP

#76
post #28

I'm sick of all of these generic SPEED benchmarks. Let me tell you some BIGGEST & REAL benefits of NodeJS where PHP SUCKS. 1. Takes 1 minute to install on any platform (*nix, windows etc.) 2. A modern Package Manager (NPM) works seamlessly with all platforms. 3. All libraries started from 0 with async baked in from day 0. 4. No need to use any 3rd party JSON serialize/deserialize libs. 5. And above all, its Atwood's…

You seriously don't know what are you talking about.

Re: Benchmarking Codswallop: Node.js vs. PHP

#77
post #68

Doing async in PHP still feels like strapping a dildo to a horse and calling it an unicorn.

I'm a PHP user/fan and I find this as funny as it is true.

Waow i never tough that i would actually read the word "fan" along side php, it make my day.

Re: Benchmarking Codswallop: Node.js vs. PHP

#78
post #77
post #68

Earlier quoted context omitted.

I'm a PHP user/fan and I find this as funny as it is true.

Waow i never tough that i would actually read the word "fan" along side php, it make my day.

There are plenty (including myself), we just avoid stating it in public for fear of the instantly appearing anti-PHP trolls that lurk around every corner.

Re: Benchmarking Codswallop: Node.js vs. PHP

#79
post #43
post #28

I'm sick of all of these generic SPEED benchmarks. Let me tell you some BIGGEST & REAL benefits of NodeJS where PHP SUCKS. 1. Takes 1 minute to install on any platform (*nix, windows etc.) 2. A modern Package Manager (NPM) works seamlessly with all platforms. 3. All libraries started from 0 with async baked in from day 0. 4. No need to use any 3rd party JSON serialize/deserialize libs. 5. And above all, its Atwood's…

Not meaning to troll but: 1. apt-get install php5 ? Seriously, that's it. On the other hand, neither Debian stable nor Ubuntu LTS have any usable version of node in their package repository (Debian has nothing, Ubuntu has 0.6) 4. json_decode() ? 5. If Atwood's law ever becomes reality, it will be a consequence, not a source of benefit. (I don't use either Node or PHP as my main language)

I've developed software in Java,.NET, Php & NodeJS. I ll rate JVM higher than any other platform. But when it comes to simplicity, easy scalability, Node ranks way higher. Php isnt even closer at all.

NodeJS literally takes 5 minutes to get started writing scalable apps without even thinking about concurency at all.

Write a software in Php yourself and let people download and run themselves, there are endless pain. Actually Php sucks in many areas which I dont want to touch right now.

Re: Benchmarking Codswallop: Node.js vs. PHP

#80
post #67

Earlier quoted context omitted.

What performance problem with FD? How many requests exactly are you handling per second with what code or processing? Are you sure its not what he just mentioned, ulimit? The docs say client requests so yes its just to make them.

I'm handling from 4k to 10k simultaneous requests. And about the client requests, hmm ok, no problem. I will keep looking. Thanks!

Why do you need to handle 5k requests simultaneously? Maybe you mean per second? Maybe you can add a server and do round-robin DNS? Then you will he able to do double unless there is a database bottleneck or something. But you said concurrent which 4k really concurrent is asking a lot.
Post reply on HN