[jsherer]

Genuinely curious, are there any cases of production Go environments where routing is the bottleneck of their HTTP services? I'd think any kind of data access in the service would be the bottleneck, not routing.

[VanillaCafe]

The way I look at it is composing benchmarks to estimate the upper bound on the number of pages that can be served per second.

So for GITHUBALL for instance:

* BenchmarkHttpRouter_GithubAll at 66732 ns/op serves at most 15k pages/second/server, versus say

* BenchmarkGoji_GithubAll at 752515 ns/op serves at most 1.3k pages/second/server

Or for GPLUSALL

* BenchmarkHttpRouter_GPlusAll at 3258 ns/op serves at most 310k pages/second/server, versus

* BenchmarkGoji_GPlusAll at 15260 ns/op serves at most 66k pages/second/server

[elmin]

This is my question as well. With the exception of some very specialized applications, I can't see why any of this would have a significant impact on the real world performance of actual services.

[elithrar]

Extremely few. 99%+ of your bottleneck will be in template rendering or DB access. Routing is so fast as to not matter for even "large" web applications.

[rdtsc]

Can imagine it might be it is used as a proxy/gateway to set of servers that then do data access.