谁是最快的Go Web框架?, 这是我去年发布的Go web 框架的评测。现在一年过去了，有些框架因为缺乏维护而被放弃了，又有新的轮子被创造出来，既有的轮子也在不停的演化升级，来去之间，Go的版本也已经升级的1.8了。 青年节前， kirillDanshin提了一个issue,希望能更新最新的测试结果，现在这篇文章就记录了最新的测试结果。
测试环境
- CPU: Intel(R) Xeon(R) CPU E5-2630 v3 @ 2.40GHz, 32 cores
- Memory: 32G
- Go: 1.8.0
- OS: CentOS 7 / 3.10.0-229.el7.x86_64
所有的评测的 web 框架都已经更新到 2017-04-01 的最新版本。
说明
Julien Schmidt实现的 go-http-routing-benchmark 是对 router的一个评测，但是作为完整的web框架，从接收用户请求到发送给客户端／浏览器，中间会经过多个组件的处理， router的性能影响到底在整体的web请求处理中影像多大呢？看测试结果。
本项目的代码在 go-web-framework-benchmark, 你可以查看，也欢迎提 pull request。
测试中的 gear 测试代码有问题，没有加上router中间件， 你可以在这次测试中忽略它的benchmark。参看 # 33
模拟业务不同的处理时间框架的性能
使用 5000 个客户端模拟请求，比较各web框架在不同的处理时间下的性能。
1、0ms
0ms模拟理想的业务处理。在这种处理时间下， 每个请求基本只耗费小于1毫秒的处理时间，这是理想的极端的情况，比如访问内存中缓存的对象就返回。
2、10ms
10ms模拟比较好的业务处理。在这种情况下，服务器只需在极短的情况下(10ms)处理完请求，如果业务不是太复杂，没有访问本地磁盘、数据库或者其它远程服务的情况下，比较符合这种测试。
3、100ms
100ms模拟一般的业务处理。一般接收请求后，可能访问本地磁盘上的文件、数据库或者调用一个或多个远程服务，在这种情况下，完成一次请求可能要花费较少的时间。
pipelining
这个测试是模拟在 pipelining 情况下 web 框架的表现。
HTTP管线化（HTTP pipelining）是将多个HTTP请求（request）整批提交的技术，而在发送过程中不需先等待服务端的回应。
请求结果管线化使得 HTML 网页加载时间动态提升，特别是在具体有高延迟的连接环境下，如卫星上网。在宽带连接中，加速不是那么显著的，因为需要服务器端应用 HTTP/1.1 协议:服务器端必须按照客户端的请求顺序恢复请求，这样整个连接还是先进先出的，对头阻塞（HOL blocking）可能会发生，造成延迟。未来的 HTTP/2.0 或者SPDY中的异步操作将会解决这个问题。因为它可能将多个 HTTP 请求填充在一个TCP数据包内，HTTP 管线化需要在网络上传输较少的 TCP 数据包，减少了网络负载。
下图是使用 5000 客户端 测试不同的处理时间的性能比较图。
并发
下面这组测试是在业务处理时间限定在30ms的情况下， 使用100、1000、5000的并发client的吞吐情况。
1、100并发
2、1000并发
3、5000并发
总结
Go Web框架目前已经非常多了，不断的有人造轮子，这是Go Web的设计简单易扩展有关。如果我觉得官方的路由不方便，我就可以很容易的再造一个轮子，这也是go web 框架／router泛滥的缘故， 以至于有人呼吁不要再早轮子了。
从目前既有的web框架看，根据框架的低层看，可以分为两类。一类是基于官方 net/http标准库开发的web框架，一类是基于fasthttp开发的标准库框架。很明显基于fasthttp有更好的性能，但是这类框架也有它们的缺点，不完全支持HTTP协议，比如不支持HEAD，不支持 HTTP2， 各有优缺点，如何选择交给使用者，结合自己实际的情况来选择。比如Echo框架，在最新版中就把对fasthttp的支持去掉了。
另外，julienschmidt的httprouter有着良好的性能，这也是很几个web框架的路由器使用它的原因。
为什么没有关注量很高iris？这是一个复杂而又有争议的问题，参照issue #29、issue #16， 暂时把iris去掉了。
测试代码和最新结果都在 go-web-framework-benchmark
有疑问加站长微信联系（非本文作者）
