It's currently very hard to digest any information from this. Some bar-charts would be helpful.
Or just sorting the results by performance, rather than alphabetically.
Show HN: Go HTTP Request Router Benchmark
11–20 of 21 posts
Re: Show HN: Go HTTP Request Router Benchmark
#12I am so glad to see the benchmarks' source code here. So often these "performance" blog posts get written in a completely unreproducible way. A core element of the scientific method is that others can reproduce your experiment to validate or disprove your results.
Re: Show HN: Go HTTP Request Router Benchmark
#13What about Negroni ?
Re: Show HN: Go HTTP Request Router Benchmark
#14Would be great to see a benchmark of how much time is actually spent in routing compared to all the other disciplines involved in responding to a HTTP request. For any interesting application, I suspect routing will be the least of your troubles in regards to performance.
For most web-apps this is definitely true. But an efficient router doesn't hurt either. If the router scales well, the routing part will never become your bottleneck. If the router is also memory efficient, it can reduce the amount of time the Garbage Collector needs.
The point was that the routing part is highly unlikely to become your bottleneck in any case.
Re: Show HN: Go HTTP Request Router Benchmark
#15So the one you recommend is the one you wrote yourself?
I'd recommend Goji to most users. The one I wrote has better performance, but also less features.
I use the standard one for quick/low performance, things, but Julien's HttpRouter for high performance needs. I've never needed any of the advanced features that the other routers provide- but do care very much about performance.
Re: Show HN: Go HTTP Request Router Benchmark
#16What about Negroni ?
Negroni doesn't have a router built in, and these benchmarks are only looking at the router components.
Re: Show HN: Go HTTP Request Router Benchmark
#17Thanks for the benchmark, I didn't know half these projects existed.
One thing that affects Gorilla mux is that this test is putting all the routes at the top-level instead of constructing subroutes based on the logical route hierarchies.
Certainly the fact that HttpRouter constructs that prefix tree for you is a huge feature, and the speed is impressive, but it's not a typical/canonical usage of Gorilla mux.
I don't know if that's the case with the other routers or not.
Re: Show HN: Go HTTP Request Router Benchmark
#18Thanks for the benchmark, I didn't know half these projects existed. One thing that affects Gorilla mux is that this test is putting all the routes at the top-level instead of constructing subroutes based on the logical route hierarchies. Certainly the fact that HttpRouter constructs that prefix tree for you is a huge feature, and the speed is impressive, but it's not a typical/canonical usage of Gorilla mux. I don't…
Contributions are welcome ;)
Re: Show HN: Go HTTP Request Router Benchmark
#19It's currently very hard to digest any information from this. Some bar-charts would be helpful.
I put together a quick-and-dirty excel plot of the data: http://imgur.com/uyFkjSB
It's plotting the relative speedup of each router's benchmark vs the slowest benchmark on that dataset. (For example, Beego's performance on the GithubStatic dataset was 12 times faster than the slowest GithubStatic dataset performance)
Fastest overall routers are sorted left to right. Keep in mind that the vertical scale is logarithmic, so implementations on the left are more than 100 times faster than those on the far right.
Re: Show HN: Go HTTP Request Router Benchmark
#20Thanks for the benchmark, I didn't know half these projects existed. One thing that affects Gorilla mux is that this test is putting all the routes at the top-level instead of constructing subroutes based on the logical route hierarchies. Certainly the fact that HttpRouter constructs that prefix tree for you is a huge feature, and the speed is impressive, but it's not a typical/canonical usage of Gorilla mux. I don't…
Contributions are welcome ;)
Yeah yeah yeah ;)