4 ms·

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?

by kt315_ 8y ago

trp1 8y ago
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.
- schrodinger 8y ago
  Why would you not use the standard library’s http package. I would!
- fileeditview 8y ago
  There are so many options to choose from. But don't use Iris. See https://www.reddit.com/r/golang/comments/57w79c/why_you_really_should_stop_using_iris/ https://www.reddit.com/r/golang/comments/57w79c/why_you_real...
deepsun 8y ago
Check out https://github.com/valyala/fasthttp https://github.com/valyala/fasthttp
Thaxll 8y ago
FastHTTP is the fastest server for Go, it's going to crush Elixir by something like 10x, it's really fast like the fastest c++ / rust libraries.
octetcloud 8y ago
I'd avoid the cluster module, its not the recommended way to scale Node.js. It exists mostly as a way to make naive Node.js benchmarks perform better in multi-CPU comparison testing... like yours! :-) Many cloud providers charge per-CPU, so node's "mostly not threaded approach" is reasonable, IMO and that of many other users. Node is scaled by spinning up more instances, each instance being one of the cheapest "one CPU" variety. I'd be more interested in seeing a version of your benchmark that limited each of the language instances to a single CPU, and/or that spun up multiple node instances equivalent to one multi-cpu instance of go/elixir --- this latter may sound weird, but its a "cost equivalent" comparison, which is ultimately what's important: transactions served per $$.
- kt315_ 8y ago
  One of the benchmark goals was to test "scheduling" efficiency of each runtime. In other words to show how well it scales given many-core instance, which often is more economical in transaction/$$ sense. Question: how using cluster module is different from spinning up multiple node instances?

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?

by kt315_ 8y ago

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?

trp1 8y ago

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.

schrodinger 8y ago
Why would you not use the standard library’s http package. I would!
fileeditview 8y ago
There are so many options to choose from. But don't use Iris. See https://www.reddit.com/r/golang/comments/57w79c/why_you_really_should_stop_using_iris/ https://www.reddit.com/r/golang/comments/57w79c/why_you_real...

deepsun 8y ago

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

Thaxll 8y ago

FastHTTP is the fastest server for Go, it's going to crush Elixir by something like 10x, it's really fast like the fastest c++ / rust libraries.

octetcloud 8y ago

I'd avoid the cluster module, its not the recommended way to scale Node.js. It exists mostly as a way to make naive Node.js benchmarks perform better in multi-CPU comparison testing... like yours! :-) Many cloud providers charge per-CPU, so node's "mostly not threaded approach" is reasonable, IMO and that of many other users. Node is scaled by spinning up more instances, each instance being one of the cheapest "one CPU" variety. I'd be more interested in seeing a version of your benchmark that limited each of the language instances to a single CPU, and/or that spun up multiple node instances equivalent to one multi-cpu instance of go/elixir --- this latter may sound weird, but its a "cost equivalent" comparison, which is ultimately what's important: transactions served per $$.

kt315_ 8y ago
One of the benchmark goals was to test "scheduling" efficiency of each runtime. In other words to show how well it scales given many-core instance, which often is more economical in transaction/$$ sense. Question: how using cluster module is different from spinning up multiple node instances?