Benchmarking Go vs. Node vs. Elixir
stressgrid.com
Benchmarking Go vs. Node vs. Elixir
1–10 of 33 posts
Re: Benchmarking Go vs. Node vs. Elixir
#2Surprising that BEAM is such a CPU hog!
Re: Benchmarking Go vs. Node vs. Elixir
#3Wonder how much the anonymous function in the node handler affected it.
Not sure what `body` not having `var` in front (so it gets put on global) would do either.
Re: Benchmarking Go vs. Node vs. Elixir
#4Tldr?
Re: Benchmarking Go vs. Node vs. Elixir
#5Not sure but it kind of seems like they are running only one (single-threaded) Node process on multicore CPUs.
Re: Benchmarking Go vs. Node vs. Elixir
#6Tldr?
Node bad, Elixir good but spikey on the CPU, Go best.
Re: Benchmarking Go vs. Node vs. Elixir
#7Not 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.
Re: Benchmarking Go vs. Node vs. Elixir
#8Not 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
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?
Re: Benchmarking Go vs. Node vs. Elixir
#9Surprising that BEAM is such a CPU hog!
BEAM has some heuristics where it can switch to a busy wait in some cases in an attempt to reduce latency. This is tunable with the +sbwt argument to erl; but the default means it's hard to use the system CPU % as a load indicator.
Re: Benchmarking Go vs. Node vs. Elixir
#10Earlier 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?
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.