Benchmarking Codswallop: Node.js vs. PHP • Hacker News Board

Re: Benchmarking Codswallop: Node.js vs. PHP

#81

Post by esailija » Wed, Nov 13, 2013, 9:30 AM UTC

humanrebar wrote: post #54

likeclockwork wrote: post #44

Earlier quoted context omitted.

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.

The canonical PHP implementation is a simple interpreter that cannot even dream of such optimizations. Hell, it uses unions to handle dynamic typing and hash tables to represent objects.

The implementation by facebook (HipHop) might have such an optimization though.

Re: Benchmarking Codswallop: Node.js vs. PHP

#82

Post by filipedeschamps » Wed, Nov 13, 2013, 10:03 AM UTC

ilaksh wrote: post #80

filipedeschamps wrote: post #72

Earlier quoted context omitted.

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.

Currently, we are with a C# application and in the process to migrate to Node.js. I wan't to prove that Node.js can handle huge concurrency, so I wan't to benchmark the highest possible numbers I can. We are currently usign AWS to load balace.

And it's being a great exercise anyway.

We are using Redis for session store. Do you thing raising this parameter can influence on Redis performance? Because in the Redis server, the service is only using 5% in process, when Node.js is 99%.

Re: Benchmarking Codswallop: Node.js vs. PHP

#83

Post by dspillett » Wed, Nov 13, 2013, 10:37 AM UTC

STRML wrote: post #14

eknkc wrote: 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…

This is the "insane default" that substack goes on a rant about in the hyperquest README: https://github.com/substack/hyperquest#rant There is a default connection pool of 5 requests. If you have 5 or more extant http requests, any additional requests will HANG for NO GOOD REASON. This one trips up people on #node.js constantly and hopefully will be removed very soon.

Unless this is what has changed I'd say the default is sane and has a good reason. The doc (http://nodejs.org/docs/latest/api/http.html#http_agent_maxso...) states:

> agent.maxSockets: By default set to 5. Determines how many concurrent sockets the agent can have open per host.

This stops you accidentally overloading a single host that you are scraping. It would not (assuming it works as described) affect your app if you are making requests to many hosts to collate data. Many applications (scrapers like httrack for instance) implement similar limits by default. If you are piling requests onto a single host but you either know the host is happy for you to do that (i.e. it is your own service or you have a relevant agreement) or have put measures in place yourself to not overload the target then by all means increase the connection limit.

Re: Benchmarking Codswallop: Node.js vs. PHP

#84

Post by STRML » Wed, Nov 13, 2013, 10:55 AM UTC

dspillett wrote: post #83

STRML wrote: post #14

Earlier quoted context omitted.

This is the "insane default" that substack goes on a rant about in the hyperquest README: https://github.com/substack/hyperquest#rant There is a default connection pool of 5 requests. If you have 5 or more extant http requests, any additional requests will HANG for NO GOOD REASON. This one trips up people on #node.js constantly and hopefully will be removed very soon.

Unless this is what has changed I'd say the default is sane and has a good reason. The doc ( http://nodejs.org/docs/latest/api/http.html#http_agent_maxso... ) states: > agent.maxSockets: By default set to 5. Determines how many concurrent sockets the agent can have open per host. This stops you accidentally overloading a single host that you are scraping. It would not (assuming it works as described) affect your app…

You're close, but the rub is, every single http request uses the same agent (globalAgent), unless specifically passed an individual http agent or "{agent: false}" in configuration. So it is effectively a global connection pool. This has caused all kinds of performance issues in production applications. It can be easily shut off but it is easy to miss in the docs. The default of 5 has met its demise in 0.11 - the new default is Infinity.

Re: Benchmarking Codswallop: Node.js vs. PHP

#85

Post by philstu » Thu, Nov 14, 2013, 6:08 AM UTC

dspillett wrote: post #75

CJefferson wrote: post #12

Earlier quoted context omitted.

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 benchmar…

Hold on, why was my response badly researched?

The point was that NodeJS and PHP were pretty close, and I posted (before the update) that I'm sure Node could go quicker.

You run either of them in suicide mode to RUN ALL THE CONNECTIONS and you'll get a speed up. The point is that NodeJS is not magically 4 or 5 times faster than PHP, they're about the same when you the packages you use support the async approach. This update proves they're exactly the same, but similarity is all I was going for.