| 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=<# of logical CPU cores>. 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. |
I did use GOMAXPROCS with the number of logical cores that I have, and I did test the node cluster with the same number.