Show HN: Go HTTP Request Router Benchmark(github.com)
github.com
Show HN: Go HTTP Request Router Benchmark
https://github.com/julienschmidt/go-http-routing-benchmark
7 comments
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.
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.
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.
Would 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.
I 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.
So 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.
Slightly off topic: Would httprouter + negroni be a reasonable replacement for Goji?
Goji does very well given it includes a request context implementation as well. I've been porting over an existing net/http + gorilla/mux app and like its design.
I don't mind someone recommending their own work when the rationale is backed by hard data.
Thanks 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.
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.
What about Revel framework?
Revel is a bit too magic. It is hard to benchmark the routing alone.
What about Negroni ?
Negroni doesn't have a router built in, and these benchmarks are only looking at the router components.