4 ms·

I think that their benchmark isn't pushing the server hard enough (and having one "hey" requesting system may not be enough either?). And that if it were, you'd

I think that their benchmark isn't pushing the server hard enough (and having one "hey" requesting system may not be enough either?). And that if it were, you'd actually see the benefit of using fewer blocking OS threads. If you look at the Plaintext TechEmpower benchmark [1], for instance, the "echo-prefork" Go benchmark hits 3.6M requests per second. fasthttp hits 2.8M. On a less powerful cloud server, fasthttp hits 850000 and echo-prefork hits 742000 (yes, fasthttp is faster on a slower system...the fun of benchmarks). Not sure how fast your machine is, but I'm sticking with Go for my performance-critical code. As a parallel comment points out, Go is also fast no matter what code you're running, and Go's optimizations are throughout the stack, including some pretty extreme garbage collection optimizations, so when you have a complex, long-running server, GC won't be killing latency at a crucial time. [1] https://www.techempower.com/benchmarks/#section=data-r13&hw=ph&test=plaintext https://www.techempower.com/benchmarks/#section=data-r13&hw=...

floatboth 10y ago
I measured single thread because the author measured single thread.
- SomeCallMeTim 10y ago
  I missed that fact. In that case, the author is measuring something that's completely useless. The entire advantage of Go is that it has really good multithreaded asynchronous behavior. A benchmark that's measuring single thread performance of a task that's optimized to do well in a single thread (i.e., it doesn't actually do anything other than return static text) is entirely worthless. If you're going to be returning static text, may as well compare to Nginx, which I'm certain can return static text even faster. If you're going to be doing processing in Python, then do at least something. And run in multiple threads, since that's Go's native environment. Rating: PANTS ON FIRE. [1] [1] Not your comparison, but the original author's performance claims.
  - floatboth 10y ago
    The author doesn't care about the advantage of Go, he cares about fair comparison to his project, which is single-threaded Python.

floatboth 10y ago

I measured single thread because the author measured single thread.

SomeCallMeTim 10y ago
I missed that fact. In that case, the author is measuring something that's completely useless. The entire advantage of Go is that it has really good multithreaded asynchronous behavior. A benchmark that's measuring single thread performance of a task that's optimized to do well in a single thread (i.e., it doesn't actually do anything other than return static text) is entirely worthless. If you're going to be returning static text, may as well compare to Nginx, which I'm certain can return static text even faster. If you're going to be doing processing in Python, then do at least something. And run in multiple threads, since that's Go's native environment. Rating: PANTS ON FIRE. [1] [1] Not your comparison, but the original author's performance claims.
- floatboth 10y ago
  The author doesn't care about the advantage of Go, he cares about fair comparison to his project, which is single-threaded Python.