httprouter与 fasthttp 的性能对比
关于协议:
本打算接入层使用gRPC,虽然基于HTTP 2.0 效率比较高，而且使用protobuf 能进行高效的序列化。但是本次系统需要和
JAVA进行对接，考虑到gRPC对JAVA的支持性不是很好，资源并不多，可能在踩坑上花过多的时间，所以综合考虑还是使用restful 进行对接
后续如果有机会还是会考虑使用gRPC。所以下面对几个go的http框架进行简单的对比
测试工具：
ApacheBench
参数：
ab -n 6000 -c 300 http://url:port
可能机器原因只能给到这么大的参数了
测试环境：
型号：imac macos 10.13
内存：8
cpu核心数：4
为了模拟网络请求处理时间，所以在处理的Handle function 中加入了 time.Sleep(200 *time.Millisecond)
测试对象：
httprouter:本打算使用gin 框架进行测试，但是fasthttp是一个http的包 使用 gin使用的httprouter
进行测试，优势在于实现了restful 风格的地址，使用前缀树实现了路由查找，使用了go 的标准包 http包 开启一个服务
fasthttp:优势在于自己实现了http服务，内部大量的池化，并不是每个请求都和http包一样开启一个goroutine，
同是也使用[]byte 操作去 代替string 操作，减少了内存的分配。
测试数据：
1、fasthttp
Server Software: fasthttp
Server Hostname: 127.0.0.1
Server Port: 8083
Document Path: /index
Document Length: 3 bytes
Concurrency Level: 300
Time taken for tests: 4.371 seconds
Complete requests: 6000
Failed requests: 0
Total transferred: 936000 bytes
HTML transferred: 18000 bytes
Requests per second: 1372.81 [#/sec] (mean)
Time per request: 218.530 [ms] (mean)
Time per request: 0.728 [ms] (mean, across all concurrent requests)
Transfer rate: 209.14 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 6 4.5 7 26
Processing: 200 209 5.2 208 223
Waiting: 200 206 4.1 206 221
Total: 201 215 8.5 217 246
Percentage of the requests served within a certain time (ms)
50% 217
66% 221
75% 222
80% 223
90% 225
95% 227
98% 231
99% 235
100% 246 (longest request)
2、httprouter
Server Software:
Server Hostname: 127.0.0.1
Server Port: 8081
Document Path: /index
Document Length: 9 bytes
Concurrency Level: 300
Time taken for tests: 4.343 seconds
Complete requests: 6000
Failed requests: 0
Total transferred: 750000 bytes
HTML transferred: 54000 bytes
Requests per second: 1381.60 [#/sec] (mean)
Time per request: 217.140 [ms] (mean)
Time per request: 0.724 [ms] (mean, across all concurrent requests)
Transfer rate: 168.65 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 5 4.1 4 19
Processing: 200 209 6.0 207 227
Waiting: 200 206 3.9 205 227
Total: 201 214 9.4 211 243
Percentage of the requests served within a certain time (ms)
50% 211
66% 220
75% 223
80% 224
90% 227
95% 229
98% 233
99% 236
100% 243 (longest request)
httprouter 并发情况下内存的使用情况:
初始化
ID COMMAND %CPU TIME #TH #WQ #POR MEM PURG CMPR PGRP PPID STATE BOOSTS
20746 httprouter 0.0 00:00.01 7 0 25 1720K 0B 0B 20746 1532 sleeping *0[1]
ab -n 6000 -c 100 http://127.0.0.1:8081/index
PID COMMAND %CPU TIME #TH #WQ #POR MEM PURG CMPR PGRP PPID STATE BOOSTS
20746 httprouter 0.0 00:02.05 20 0 38 7400K 0B 0B 20746 1532 sleeping *0[1]
ab -n 6000 -c 200 http://127.0.0.1:8081/index
ID COMMAND %CPU TIME #TH #WQ #POR MEM PURG CMPRS PGRP PPID STATE
20746 httprouter 0.0 00:04.14 20 0 38 9508K 0B 880K 20746 1532 sleeping
ab -n 6000 -c 300 http://127.0.0.1:8081/index
PID COMMAND %CPU TIME #TH #WQ #POR MEM PURG CMPRS PGRP PPID STATE
20746 httprouter 0.0 00:05.51 82 0 100 13M 0B 856K 20746 1532 sleeping
fasthttp 并发情况下内存的使用情况：
初始化
PID COMMAND %CPU TIME #TH #WQ #POR MEM PURG CMPR PGRP PPID STATE BOOSTS
20455 fasthttp 0.0 00:00.01 7 0 25 1704K 0B 0B 20455 1532 sleeping *0[1]
ab -n 6000 -c 100 http://127.0.0.1:8080/index
PID COMMAND %CPU TIME #TH #WQ #POR MEM PURG CMPR PGRP PPID STATE BOOSTS
20455 fasthttp 1.9 00:01.61 29 0 47+ 5964K+ 0B 0B 20455 1532 sleeping *0[1]
ab -n 6000 -c 200 http://127.0.0.1:8080/index
PID COMMAND %CPU TIME #TH #WQ #POR MEM PURG CMPR PGRP PPID STATE BOOSTS
20455 fasthttp 0.0 00:02.99 29 0 47 7136K 0B 0B 20455 1532 sleeping *0[1]
ab -n 6000 -c 300 http://127.0.0.1:8080/index
PID COMMAND %CPU TIME #TH #WQ #POR MEM PURG CMPR PGRP PPID STATE BOOSTS
20455 fasthttp 0.0 00:04.18 49 0 67 8508K 0B 0B 20455 1532 sleeping *0[1]
可能是因为程序只是简单的返回了 hello world ! 所以内存增长的并不明显，
但是httprouter 在并发到300的时候 内存飙升（一开始以为自己弄错了，测了几次还是这样的数据）可能是http没有做任何优化的原因
fasthttp做了优化，并发越大的情况下越能体现优势，所以个人更倾向于fasthttp