HTTP throughput regression from Go 1.7.5 to 1.8
As I&#x27;ve mentioned before [1], as the number starts getting too large, &quot;requests per second&quot; isn&#x27;t a useful way of measuring the performance of a webserver, you&#x27;re really more interested in &quot;seconds per request overhead&quot;. The former makes this sound horrible and leads to headlines that make it sound like the entire web stack has lost 20% of its performance, which is terrible. The latter shows that the &quot;request overhead&quot; has gone from ~100us per request to ~120us or so, which is a lot more informative and tends to lead to better understanding what the situation is.<p>This is not meant as an attack or a defense of Go. The facts are what the facts are. The point here is to suggest that people use terminology that is more informative and easier to understand. There are people for whom 20us per request extra is a sufficiently nasty issue that they will not upgrade. There are also a lot of people who are literally multiple orders of magnitude away from that even remotely mattering because their requests tend to take 120ms anyhow. Using &quot;seconds per request overhead&quot; both makes it easier to understand both the real performance impact with real times, and makes it easier to understand that we&#x27;re just talking about the base overhead per request rather than the speed of the entire request.<p>It might also discourage some of our, ah, more junior developers from being too focused on this metric. Why would I want to use a webserver that can only do 100,000 requests per second when I can use this one over here that can do 1,000,000 requests per second? If you look at it from the point of view that we&#x27;re speaking about the difference between 10 microseconds and 1 microsecond, it becomes easier to see that if my requests are going to take 10 <i>milliseconds</i> on average, this is not a relevant stat to be worried about when choosing my webserver, and I should examine just the other differences instead, which may be a great deal more relevant to my use cases.<p>Edit: Literally while I was typing this up I see at least three comments already complaining about this regression. My question to you, my <i>honest</i> question to you (because some of you may well be able to answer &quot;yes&quot;, especially with some of the tasks Go gets used for), is: Are you <i>really</i> going to have a problem with this? Does the rest of your request <i>really</i> run in <i>microseconds</i>? It&#x27;s actually pretty challenging in the web world to run in microseconds. It can be done, but a lot of the basic things you want to do end up like &quot;hit a database&quot; generally end up involving milliseconds, i.e., &quot;thousands of microseconds&quot;.<p>[1]: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=11187264" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=11187264</a>