undefined | Better HN

0 pointstiffanyh4y ago0 comments

What is the "spin your cpus" setting exactly you're referring too? Would be good to share for other to know.

Also, note that your link shared from stressgrid was published BEFORE the benchmarks links I shared from stressgrid. As such, wouldn't those benchmarks take into account your explanation?

0 comments

3 comments · 1 top-level

dnautics4y ago· 2 in thread

busy wait spins your cpus.

I don't know for sure, but the benchmarks you linked do some more RCA, which involves looking into why cowboy2 is not great (tl;dr HTTP2 support is hard)

also, here is how stressgrid can POC (possibly too dangerous for prod?) to 100k cps (which is on par with what Go can do in the article you linked), you could recompile kernel and configure ranch differently, would probably need to be proven out more:

https://stressgrid.com/blog/100k_cps_with_elixir/

tiffanyhOP4y ago

Your comment:

> "the stressgrid benchmarks look bad because they forgot to turn off the "spin your cpus" setting"

stressgrid blog post:

> "When running HTTP workloads with Cowboy on dedicated hardware, it would make sense to leave the default—busy waiting enabled—in place. When running BEAM on an OS kernel shared with other software, it makes sense to turn off busy waiting, to avoid stealing time from non-BEAM processes."

stressgrid seems to recommend the opposite of what you mention, taken from the blog post you shared [0].

Am I misunderstanding?

[0] https://stressgrid.com/blog/beam_cpu_usage/

dnautics4y ago

You are. I'm saying turn it off unless you're on legacy hardware that is known to need it (most people are in the cloud). Unless it's already off by default (I don't know off the top of my head)

The perf looks bad because they are also looking at CPU usage.

Getting to 100k rps is unrelated to busy wait.

1 more reply

j / k navigate · click thread line to collapse