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

Benchmarking Go vs. Node vs. Elixir

stressgrid.com

Post reply on HN
Print view View original

11–20 of 33 posts

Re: Benchmarking Go vs. Node vs. Elixir

#11

Post by schrodinger »

trp1 wrote: post #10
kt315_ wrote: post #8

Earlier quoted context omitted.

Author here. Planning to run the same test using cluster module with one worker per CPU. What would be the most performant way to serve HTTP in Go?

Well I believe few people use the built in http module in go. Not sure if you're testing would allow for 3rd party frameworks but the Iris framework loves to claim fastest go web server. Gorilla or gin are also popular. As for the structure of it you would like have everything split out into goroutines with a worker pool of goroutines ready to ferry the data from request to backend and back to client.

Why would you not use the standard library’s http package. I would!

Re: Benchmarking Go vs. Node vs. Elixir

#12

Post by schrodinger »

wiennat wrote: post #7
markus_v wrote: post #5

Not sure but it kind of seems like they are running only one (single-threaded) Node process on multicore CPUs.

This immediately comes into my mind when I see the charts. It is also interesting to see that only one Node process can barely serve 10k connections. ---- After I check the source at [0]. They use a simple http module to serve the requests while they use `http.ListenAndServe` which spawns go routines, hence more CPU utilization. [0] https://gitlab.com/stressgrid/dummies

That’s the idiomatic way to handle requests in Go. What’s the problem?

Re: Benchmarking Go vs. Node vs. Elixir

#13

Post by deepsun »

kt315_ wrote: post #8
wiennat wrote: post #7

Earlier quoted context omitted.

This immediately comes into my mind when I see the charts. It is also interesting to see that only one Node process can barely serve 10k connections. ---- After I check the source at [0]. They use a simple http module to serve the requests while they use `http.ListenAndServe` which spawns go routines, hence more CPU utilization. [0] https://gitlab.com/stressgrid/dummies

Author here. Planning to run the same test using cluster module with one worker per CPU. What would be the most performant way to serve HTTP in Go?

Check out https://github.com/valyala/fasthttp

Re: Benchmarking Go vs. Node vs. Elixir

#15

Post by wiennat »

schrodinger wrote: post #12
wiennat wrote: post #7

Earlier quoted context omitted.

This immediately comes into my mind when I see the charts. It is also interesting to see that only one Node process can barely serve 10k connections. ---- After I check the source at [0]. They use a simple http module to serve the requests while they use `http.ListenAndServe` which spawns go routines, hence more CPU utilization. [0] https://gitlab.com/stressgrid/dummies

That’s the idiomatic way to handle requests in Go. What’s the problem?

I don't have any problem with their Go implementation. Instead, it is very impressive to me who has little knowledge in Go.

I just want to point out that Node runs with a single thread so it does not max out CPU utilization. It would be nice if the author does the benchmark again with multiple processes of node js.

Re: Benchmarking Go vs. Node vs. Elixir

#16

Post by HiFaraz »

wiennat wrote: post #7
markus_v wrote: post #5

Not sure but it kind of seems like they are running only one (single-threaded) Node process on multicore CPUs.

This immediately comes into my mind when I see the charts. It is also interesting to see that only one Node process can barely serve 10k connections. ---- After I check the source at [0]. They use a simple http module to serve the requests while they use `http.ListenAndServe` which spawns go routines, hence more CPU utilization. [0] https://gitlab.com/stressgrid/dummies

It's an unfair comparison then if they don't even use Node.js to its full potential. Apple to oranges comparison.

Re: Benchmarking Go vs. Node vs. Elixir

#17

Post by theamk »

markus_v wrote: post #5

Not sure but it kind of seems like they are running only one (single-threaded) Node process on multicore CPUs.

Maybe they were simulating some sort of messaging server, or a shared cache, or something else which does not translate well to multiple process model?
Post reply on HN