Is HTTP routing a common performance bottleneck?

<p>There are many HTTP routers competing on routing performance. Has anyone here actually measured their app and found HTTP routing was their performance bottleneck? To me, it seems like low priority optimisation target...</p> <hr/>**评论：**<br/><br/>dgryski: <pre><p>I have never seen routing show up in my profiles.</p></pre>bkeroack: <pre><p>Writing a router is relatively easy and seems to be a popular first project for new Gophers. I wouldn&#39;t read much into it.</p></pre>Mteigers: <pre><p>Depends on the router you&#39;re using. One of our massive 10k+ LOC API servers that serves 10&#39;s of thousands of requests per day uses Martini as the framework, which relies heavily on reflect and other dependency injection. </p> <p>When doing a heap profile we see that as much as 20% is used in Reflect calls, specifically Martinis dependency injection and router. </p></pre>itsmontoya: <pre><p>Any reason you guys aren&#39;t using a more performant router?</p></pre>Mteigers: <pre><p>We&#39;re too entrenched with Martini. We tried once to make the switch but with the dependency injection nothing was standard. </p></pre>Jamo008: <pre><p>Martini is probably near the bottom of the performance leaderboards yet even serving 100k requests per day is still only ~1 request per second (100000/24/60/60 = 1.15) which should be easily achieved. Again - saying router performance doesn&#39;t really impact the performance of your average app.</p></pre>blackjackjester: <pre><p>Lucky is the engineer whose server requests occur evenly throughout the day.</p></pre>schumacherfm: <pre><p>No, but look for global mutexes for map access</p></pre>lasizoillo: <pre><p>As noob I&#39;m surprised that a map that you write once and is read the next times create contention. Is not <a href="https://golang.org/pkg/sync/#RWMutex" rel="nofollow">RWLock</a> for this kinds of things?</p></pre>schumacherfm: <pre><p>Yes, no, depends.</p> <p>Run besides your Tests a parallel Benchmark function. This gives you more insight than any guessing. Try with sync.Mutex and sync.RWMutex and even such a thing: <a href="https://github.com/coocood/freecache/blob/master/cache.go#L12" rel="nofollow">https://github.com/coocood/freecache/blob/master/cache.go#L12</a> distributed locks.</p></pre>MrSaints: <pre><p>No - the bottleneck often comes elsewhere, e.g. database, background jobs, heck, even stats collection, and log reporting...</p> <p>The Go community is just obsessed with optimisation, not that it&#39;s necessarily a bad thing.</p></pre>bketelsen: <pre><p>no. And all of these routers with their benchmarks are just a little bit silly.</p></pre>