Live data from Hacker News

Benchmarking Codswallop: Node.js vs. PHP

philsturgeon.co.uk

41–50 of 85 posts

Re: Benchmarking Codswallop: Node.js vs. PHP

#41
post #22
post #19

Long term php guy (I maintained APC for years, slowly given up now), so I've worked a lot with ~2k/3k request-per-second PHP websites. The real trick here is async processing. A lot of the slow bits of PHP code is people not writing async data patterns. If you use synchronous calls in PHP - mc::get or mysql or curl calls, then PHP absolutely sucks in performance. Nodejs automatically trains you around this with a mas…

What are best practices for writing async code in PHP?

A lot of extensions expose async modes, use them.

On the extension APIs

curl-multi - http://php.net/manual/en/function.curl-multi-select.php

memcached-getdelayed - http://us2.php.net/manual/en/memcached.getdelayed.php

mysqli-reap_async - http://us2.php.net/manual/en/mysqli.reap-async-query.php

postgres-send_query - http://www.php.net/manual/en/function.pg-send-query.php

gearman doBackground - http://www.php.net/manual/en/gearmanclient.dobackground.php

Something like gearman queues basically take the asynchronous processing out of the web layer into a different daemon. There were things like S3 uploads and fb API calls which were shoved into gearman tasks instead of holding up the web page.

Some of the stuff is very design oriented, for instance in most of my memcache code, there are no mc-lock calls at all - all of them are mc-cas calls. A lot of the atomicity is done by using add/delete/cas which involve no sleep timeouts. A bit of it was done using atomic append, increment and decrement as well.

SQL queries are another place where PHP doing actual work sucks for the web apps. A bunch of the mysql/postgresql functionality within a lock is actually moved onto stored procedures, instead of being driven by PHP.

https://github.com/zynga/zperfmon/blob/master/server/schemas...

So the code above is horribly written because you can't parameterize table names or column names in PL/SQL. But that essentially cuts down the involvement PHP has with the backend's locked sections.

Also a lot of the stats data was flooded onto apache log files instead of being written out from the PHP code directly using an fwrite.

https://github.com/zynga/zperfmon/blob/master/client/zperfmo...

This uses apache_note() function in PHP to log stuff after the request is done & the connections are closed. That gets into the log files as %(You can see there that every single access log has an associated user, the HMAC of the request and peak memory usage. All collected at zero latency to the actual HTTP call.

The thing to avoid though is pcntl - it absolutely messes up all of apache/fastcgi process management code.

This is not all of what I've done. I am sorry to say some of my best work in this hasn't been open-sourced & has perhaps been killed since I left Zynga.

PHP backends I built using these methods were handling approx ~6-7 million users a day on 9 web servers (well, we kept 16 running - 8 on each UPS).

Ah, fun times indeed - too bad I didn't make any real money out of all that.

Re: Benchmarking Codswallop: Node.js vs. PHP

#42
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'm not 100% on whether this is serious or not, but what the hell:

1. My recent installs of node have required compiling from source to get anything remotely up-to-date, however there are packages for both,

2. Composer with the Packagist registry is comparable here - you might be thinking of PEAR.

3. JS certainly has much better async support - it being JavaScript after all.

4. PHP has JSON encoding/decoding bundled, no third party lib required.

5. For better or worse

Re: Benchmarking Codswallop: Node.js vs. PHP

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

Re: Benchmarking Codswallop: Node.js vs. PHP

#44
post #8

Benchmarking is very hard because even the same language could show different results. For example: for($i = 0; $i vs $count = count($list); for($i = 0; $i Most of the time benchmarks prove how capable a programmer is, not the speed of the language used.

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.

Re: Benchmarking Codswallop: Node.js vs. PHP

#45
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?

This is already why the author did though; the original benchmark that he replied to used Cheerio vs. phpQuery, but he rationalized that that was a losing battle anyways, and decided to test Cheerio vs. ReactPHP -- which requires a non-standard PHP extension called libevent.

Re: Benchmarking Codswallop: Node.js vs. PHP

#46
post #14
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.

It's fixed in master already. Test with the latest 0.11 to verify.

Re: Benchmarking Codswallop: Node.js vs. PHP

#47
post #16

Earlier quoted context omitted.

I didn't know about this maxSockets limitation. Is this something safe to raise?

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.

Re: Benchmarking Codswallop: Node.js vs. PHP

#48
post #17

Earlier quoted context omitted.

I didn't know about this maxSockets limitation. Is this something safe to raise?

It's pretty much always safe to set to Infinity or to turn the agent off. This is an anti-feature.

I'd call it a bug. It's fixed in master.

Re: Benchmarking Codswallop: Node.js vs. PHP

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

Proof: https://pbs.twimg.com/media/BY4jok7IEAADGmE.png:large

Re: Benchmarking Codswallop: Node.js vs. PHP

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

Post reply on HN