Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

To boldly go where Node man has gone before

blog.jgc.org

Post reply on HN
Print view View original

121–124 of 124 posts

Re: To boldly go where Node man has gone before

#121

Post by supersillyus »

reissbaker wrote: post #110
robertpateii wrote: post #88

This test shows Node handling 100 requests simultaneously just as easily as handling them separately. However Go's memory usage increases by about 5X. So what happens when you reach 1000 simultaneous requests? Which will perform better then? I think this is called "selection bias."

Not only that, but Node actually got faster as simultaneous connections increased while keeping a completely stable memory footprint. The benchmark showed the opposite of what the author claimed -- Node scaled effortlessly. Its performance was completely stable and predictable under load, whereas Go's wasn't. Not to knock Go -- it's a beautiful language, and absolutely faster than Javascript for most purposes (and wi…

FYI, the original article has been updated with graphs showing reqs/sec, virtual, and real memory for both using 100, 500, and 1000 simultaneous requests. Aside from virtual memory (do we care about that?) it seems to show Go as continuing to perform better.

Re: To boldly go where Node man has gone before

#122

Post by robertpateii »

supersillyus wrote: post #121
reissbaker wrote: post #110

Earlier quoted context omitted.

Not only that, but Node actually got faster as simultaneous connections increased while keeping a completely stable memory footprint. The benchmark showed the opposite of what the author claimed -- Node scaled effortlessly. Its performance was completely stable and predictable under load, whereas Go's wasn't. Not to knock Go -- it's a beautiful language, and absolutely faster than Javascript for most purposes (and wi…

FYI, the original article has been updated with graphs showing reqs/sec, virtual, and real memory for both using 100, 500, and 1000 simultaneous requests. Aside from virtual memory (do we care about that?) it seems to show Go as continuing to perform better.

Ah, great. That's a good update. Go does end up responding well at 1000 concurrent requests for real memory. But a spike in virtual memory means it's paging all that extra data, right? Doesn't that normally slow things down? what's interesting is Go still maintains a similar requests per second.

of course, for a front end guy, Node is still the most exciting thing on the block simply because it is server-side javascript. The fact that it's not much worse than the latest greatest compiled language is pretty exciting to me.

Re: To boldly go where Node man has gone before

#123

Post by m0shen »

m0shen wrote: post #61
peterwwillis wrote: post #35

Earlier quoted context omitted.

You might like Perl too. Edit: haha I love how people downvote this like i'm being sarcastic. Down with Perl, that horrible language with a community and modules 100x larger than Node!

I don't understand the attitudes either. While I enjoy writing Javascript for Node, when other Node users tell me they hate Perl, I can do nothing but give them a blank stare. So you want an environment that is easy to program in a functional style with closures and first class functions. Has a large ecosystem, including hundreds (thousands?) of packages to do asynchronous IO. Is easily extensible and can fall back o…

That should read: YAPC::NA

Re: To boldly go where Node man has gone before

#124

Post by supersillyus »

robertpateii wrote: post #122
supersillyus wrote: post #121

Earlier quoted context omitted.

FYI, the original article has been updated with graphs showing reqs/sec, virtual, and real memory for both using 100, 500, and 1000 simultaneous requests. Aside from virtual memory (do we care about that?) it seems to show Go as continuing to perform better.

Ah, great. That's a good update. Go does end up responding well at 1000 concurrent requests for real memory. But a spike in virtual memory means it's paging all that extra data, right? Doesn't that normally slow things down? what's interesting is Go still maintains a similar requests per second. of course, for a front end guy, Node is still the most exciting thing on the block simply because it is server-side javascr…

I don't think the spike in VM means it's paging all that. That just means it has that address space reserved, not that it's using it. I'm not aware of any real cost to having a huge pile of address space reserved, aside from that some monitoring utilities will penalize you for it (unreasonably). So, no, I don't think it'll slow anything down by thrashing, unless the locality of the memory it is accessing is really bad, but I'm no expert on Linux virtual memory or how Go uses it.
Post reply on HN