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

Go as an alternative to Node.js for very fast servers

bbs.studygolang.com

Post reply on HN
Print view View original

51–60 of 168 posts

Re: Go as an alternative to Node.js for very fast servers

#51

Post by rartichoke »

redneckbeard wrote: post #39
rartichoke wrote: post #35

That test is rigged to be a best case scenario for Go. How often do you send 1MB responses down to the client? If you send 3KB responses then you would see both setups are much closer in performance. Factor in some actual I/O and the difference will be even less. Then you'll eventually realize using either one makes little difference when it comes to performance. This is why micro benchmarks are pure jokes. A real wo…

Original author of the post in question here. Please note that the microbench was "rigged" by the author of Node when he was first presenting it several years ago (spelled out in the article). If you need a tl;dr, it's this: I don't care for JavaScript as a language. Many make the argument that JavaScript should be adopted widely server-side because of its speed. I assert that languages should be evaluated not only f…

The development speed isn't very good with Go because you have to re-invent almost everything yourself because the web libs are seriously years behind other platforms.

The default template language is also really archaic and no one has created a solid alternative yet that's actually well tested and used by the masses.

It might have good execution speed and the language itself might be nice but the only thing that matters is going from point A to point B. Go will not get you there faster than other languages and the execution speed is a non-issue for pretty much every platform (even rails) if you use tools available to you to their fullest.

P.S., I compared Go to Node almost a year ago and even wrote a mini framework for Go to resemble a smaller version of Express. I eventually just said fk it and stopped because the gains were not even close to being worth it.

Re: Go as an alternative to Node.js for very fast servers

#52

Post by Jhsto »

616c wrote: post #3

So beyond the ironic comment mentioned before with the Golang Hello world tutorial using Chinese, what is the real reason behind the Chinese following behind Go? It seems like this site confirm there must be a pretty dedicated Golang following, but I cannot figure out for the life of me why. Does anyone actually know?

If you meant the Hello World example, it is probably because the board game Go originates from China: http://en.wikipedia.org/wiki/Go_(game)

Re: Go as an alternative to Node.js for very fast servers

#53

Post by masklinn »

mratzloff wrote: post #32
agentultra wrote: post #30

Earlier quoted context omitted.

My only gripe is its intended use as a systems programming language. The runtime kind of makes it a silo; ie: hard to bind other languages to it through an FFI. Of course if I am mistaken or there's something being done to address such a scenario then I will be much happier seeing more and more infrastructure code shipping in Go.

Go has the same FFI language that most languages do: C. http://golang.org/cmd/cgo/

Wrong way around. By "bind languages to it" agentultra talks about using Go from other languages, not using C from Go.

Re: Go as an alternative to Node.js for very fast servers

#56

Post by dccoolgai »

rartichoke wrote: post #35

That test is rigged to be a best case scenario for Go. How often do you send 1MB responses down to the client? If you send 3KB responses then you would see both setups are much closer in performance. Factor in some actual I/O and the difference will be even less. Then you'll eventually realize using either one makes little difference when it comes to performance. This is why micro benchmarks are pure jokes. A real wo…

Right...and you have the benefits of npm with node. AFAIK, there is nothing comparable with Go... and frankly, even the Go code in that terse example takes more lines and isn't as readable (IMHO) as the Node server...

Re: Go as an alternative to Node.js for very fast servers

#57

Post by redneckbeard »

rartichoke wrote: post #51
redneckbeard wrote: post #39

Earlier quoted context omitted.

Original author of the post in question here. Please note that the microbench was "rigged" by the author of Node when he was first presenting it several years ago (spelled out in the article). If you need a tl;dr, it's this: I don't care for JavaScript as a language. Many make the argument that JavaScript should be adopted widely server-side because of its speed. I assert that languages should be evaluated not only f…

The development speed isn't very good with Go because you have to re-invent almost everything yourself because the web libs are seriously years behind other platforms. The default template language is also really archaic and no one has created a solid alternative yet that's actually well tested and used by the masses. It might have good execution speed and the language itself might be nice but the only thing that mat…

My understanding is that many people try Go and decide they don't like it, as you did; at the same time, many have experiences that are similar to mine and they embrace it. To each his own.

The word "rigged" in your original comment implied dishonesty on my part. I just wanted to clarify that the JS code used in the microbench was Ryan Dahl's, and mine was just a port to Go. I was merely giving Go the same task that he did.

Re: Go as an alternative to Node.js for very fast servers

#58

Post by voidlogic »

AndyKelley wrote: post #43
voidlogic wrote: post #41

Earlier quoted context omitted.

>I dunno what you're complaining about. I'm complaining because you and other people will go on to: 1. Use a version of Go in your development that is slower (as has much worse memory characteristics) and lacks new features. 2. End up running all your programs on single core until you understand GOMAXPROCS 3. Use ab to bench real things which is bad So "my complaining" is trying to help you.

Can you help me by telling my why the way I used GOMAXPROCS is wrong, and how to use it correctly?

Not so much wrong as my impression was you didn't understand it. If that is not the case I apologize.

For example you said: GOMAXPROCS left default. I don't know how you set your environment vars, are they unset so default = 1? You didn't mention in your post that GOMAXPROCS=1/single node worker test cases are really toy test cases (useful only for benchmarking). So if you know everything below, then great! Maybe other people can learn:

GOMAXPROC is the number of OS level threads that the Go runtime is multiplexing Go tasks (goroutines) over.

So if GOMAXPROCS = 1, When one goroutine blocks, another will run, BUT, you will never use more than one OS thread and thus you will never use more than one logical core.

Setting GOMAXPROCS correctly is per application. For example GOMAXPROCS=1 might be right for a commandline tool or a program that was designed to have multiple instances started on the same machine. That being said, a vast majority of the time any high load application I have written is best with GOMAXPROCS=. So Go always has concurrency, but GOMAXPROCS gives it parallelism. GOMAXPROCS > 1 also will allow the garbage collector to have more parallelism too.

So if we are talking about a benchmark like this, ideally we want to process requests made in parallel in a parallel fashion. A clear sign is that if you use Node.js worker cluster you should probably test with Go at the same number.

All this being said, depending on your CPUs implementation details, you would sometimes be better off setting both your node worker count and GOMAXPROC to the number of physical rather than logical cores. Sometimes simultaneous multi-threading (SMT, aka hyperthreading) actually creates more overhead than any concurrency gains it offers.

In short when testing something like this I would always test. 1. n = 1 (with a disclaimer note) 2. n = physical CPU count 3. n = logical CPU count Where n is the number of GOMAXPROCS/node worker threads.

Re: Go as an alternative to Node.js for very fast servers

#59

Post by voidlogic »

bhauer wrote: post #44
voidlogic wrote: post #41

Earlier quoted context omitted.

>I dunno what you're complaining about. I'm complaining because you and other people will go on to: 1. Use a version of Go in your development that is slower (as has much worse memory characteristics) and lacks new features. 2. End up running all your programs on single core until you understand GOMAXPROCS 3. Use ab to bench real things which is bad So "my complaining" is trying to help you.

I agree with Voidlogic here. Perhaps his tone was a little confrontational, but his intentions were good. :) Go 1.1 > Go 1.0.2 wrk > ab In particular, ab should be avoided whenever possible. Apache Bench (ab) remains a single-threaded tool, meaning that for high-performance servers in particular, your exercise will run into the limits of Apache Bench before the limits of the server(s) being tested. The LigHTTP team h…

> Perhaps his tone was a little confrontational

Sorry, that was not intended.

>but his intentions were good. :)

They really were...

Post reply on HN