Live data from Hacker News

Benchmarking Codswallop: Node.js vs. PHP

philsturgeon.co.uk

51–60 of 85 posts

Re: Benchmarking Codswallop: Node.js vs. PHP

#51
post #16

Earlier quoted context omitted.

Default is 5. Should be just fine if you don't have a specific use case that would require higher limits. If so, just crank it up, should be safe unless you assign Infinity or something like that and push it too much (then you have another problem though). We use 15 in production where our server parses a lot of external web pages.

The new default in master is Infinity. (Also, there's opt-in KeepAlive that actually keeps sockets alive even if there are no pending requests.) The ulimit will prevent you from opening up too many anyway. The HTTP Client is not the correct place to implement job control and queueing with such a low limit by default.

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

Re: Benchmarking Codswallop: Node.js vs. PHP

#53
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…

They mention this in the update:

> Update: A few people have mentioned that Node by default will use maxConnections of 5, but setting it higher would make NodeJS run much quicker. As I said, im sure NodeJS could go faster - I would never make assumptions about something I don't know much about - and the numbers reflect that suggestions. Removing the blocking PHP approach (because obviously it's slow as shit) and running just the other three scripts looks like this:

Re: Benchmarking Codswallop: Node.js vs. PHP

#54

Earlier quoted context omitted.

Any decent compile-time optimizer will transform your first snippet into the second one (or better). Some languages preclude that optimization at compile time, but I presume that a JIT would also have little problem performing that optimization. That is, one could argue that a good language is one that lets developers ignore trivial changes like this without hurting performance.

I don't see how that would work. I'd say that the two snippets describe different intentions and using one when you want the other is a case of not saying what you mean. A function call in a loop condition might have side effects or do something very unorthodox.

I guess this is a problem with trivial examples.

Pulling redundant work out of loops is a category of optimization that is widely used. In many cases, the optimizer can detect a lack of side effects on $list inside the loop body and perform the above optimization.

Re: Benchmarking Codswallop: Node.js vs. PHP

#55
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…

I think the only valid point here is your 3rd one. 1. You have to be kidding, right? PHP's popularity is precisely because of this. 2. getcomposer.org 4. json_decode/json_encode have been a part of PHP since PHP 5.2 (2006) 5. That's not a benefit.

No, it's popularity is because it was the simplest a long time ago, and it's supported on lots of virtual boxes by default.

Composer is terrible compared to NPM.

Re: Benchmarking Codswallop: Node.js vs. PHP

#56
post #35
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…

All your points are good apart from 4, don't the native json_encode() / json_decode() functions do what you need?

Actually, only 3 is good. The rest are incorrect, entirely, and 5 is debatable as to whether that's a good thing.

Re: Benchmarking Codswallop: Node.js vs. PHP

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

I've had the opposite experience! Given a choice, I'd avoid either, though. Scala spoils me.

Re: Benchmarking Codswallop: Node.js vs. PHP

#59
post #32

The "Thoughts" section was the most informative part of the benchmark which underscores the way I, when I was working with PHP, operated. When I started with PHP(2005), the frameworks were terrible, I would cobble together many random coding examples from stuff I found on the web and just make my own Framework up. I don't think PHP from a performance standpoint is any better or worse, but the default examples that yo…

React was originally called Node.PHP or something similar, if I recall correctly!

Re: Benchmarking Codswallop: Node.js vs. PHP

#60
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 quite like https://npmjs.org/package/sax

What is it you think is missing XML-wise in Node.js?

Post reply on HN