3 ms·

Looking at the benchmark (https://gist.github.com/azer/5955772 https://gist.github.com/azer/5955772), which measure suggests that its slower than nginx? I was l

by joebo 13y ago

Looking at the benchmark (https://gist.github.com/azer/5955772 https://gist.github.com/azer/5955772), which measure suggests that its slower than nginx? I was looking at the transaction rate and the longest transaction. For reverse proxying, it seems to be as fast as nginx. For static file serving, it appears to be slightly slower. Between the two use cases, it seems like it's a negligible difference.

justinsb 13y ago
I would like to know how the benchmarks are generated, but my point is that it wasn't slower-enough to ignore it, and that's amazing considering how much micro-optimization has gone into nginx and how much easier the Go version is to write. The Go version may in fact be faster, but I don't think that's necessarily fair either: if the Go version adds features to be more comparable to nginx it would definitely slow down.
- rdtsc 13y ago
  > The Go version may in fact be faster, but I don't think that's necessarily fair either: if the Go version adds features to be more comparable to nginx it would definitely slow down. Good point. That is often how alternative parallel implementations are started. A small example is written. Benchmarks are published. The new project is hailed as better than predecessor. Many jump ship. Request for features comes in. New features starts to slow down the product. Someone new comes, writes a simple benchmark and so on.
rdtsc 13y ago
With benchmarks like this it worth asking 3 questions: * Are they relevant. Does this represent the expected production workload. You could find this is 10x better than nginx at some feature but that feature is just not interesting to you then benchmarks are not that interesting * Does the speed difference matter? Does it matter if the page loads 1ms faster when it was only 20ms before. * Does it scale. This kind of relates to first question but it looks at abnormal amounts of traffic (Slashdot effects). Either from an attack or just becoming popular too quickly. If simply adds a server with more CPUs would that let Go server scale better than nginx? It might even though nginx could probably process sequential requests faster.

by joebo 13y ago

justinsb 13y ago

I would like to know how the benchmarks are generated, but my point is that it wasn't slower-enough to ignore it, and that's amazing considering how much micro-optimization has gone into nginx and how much easier the Go version is to write. The Go version may in fact be faster, but I don't think that's necessarily fair either: if the Go version adds features to be more comparable to nginx it would definitely slow down.

rdtsc 13y ago
> The Go version may in fact be faster, but I don't think that's necessarily fair either: if the Go version adds features to be more comparable to nginx it would definitely slow down. Good point. That is often how alternative parallel implementations are started. A small example is written. Benchmarks are published. The new project is hailed as better than predecessor. Many jump ship. Request for features comes in. New features starts to slow down the product. Someone new comes, writes a simple benchmark and so on.

rdtsc 13y ago

With benchmarks like this it worth asking 3 questions: * Are they relevant. Does this represent the expected production workload. You could find this is 10x better than nginx at some feature but that feature is just not interesting to you then benchmarks are not that interesting * Does the speed difference matter? Does it matter if the page loads 1ms faster when it was only 20ms before. * Does it scale. This kind of relates to first question but it looks at abnormal amounts of traffic (Slashdot effects). Either from an attack or just becoming popular too quickly. If simply adds a server with more CPUs would that let Go server scale better than nginx? It might even though nginx could probably process sequential requests faster.