顺便推下自己项目：
https://v2ex.com/t/761727
https://v2ex.com/t/734682

accessLog = Counter{data: make(map[string]int)}
先改成
accessLog = &Counter{data: make(map[string]int)}
否则可能 panic

key 的问题，Counter 的 func 都把 key 先 trim 一下

@Lpl
另外，9 楼 3 条没一个是对的

也不知道楼上有几位都是啥情况，老夫如此热情，连句话都不回，是因为看不懂吗。。。

试试我这个： https://www.v2ex.com/t/734682

纯为了支持 json-iter 来占个楼 ^_^

@FucUrFrd *nix 进城内文件描述符的特点、产生与回收再利用可以看一下，数组对比下 map/rbt 的时间复杂度以及除了时间复杂度，那个复杂度的每次操作本身是包括哪些操作，都可以看下。

既然无国界，就不要上纲上线的

@FucUrFrd 如果跟太大陆了就跟 github 无国界冲突，那好多用英语的，太欧美了，其他非英语国家地区的人怎么办？这么讲的话，github 不能用地球国家的语言了

@FucUrFrd
1. NIUBILITY 即使太大陆了，也跟 github 无国界不冲突吧？难道 github 无国界所以就不能有大陆相关的了？你的逻辑思维有些乱，建议加强训练一下
2. 这个地方数组比 map/rbt 好，如果看不懂说明基础有点弱，多读好书补补

@lesismal 业务层的程序员小伙伴们完全可以继续用同步逻辑写代码，单就 http server 来讲，应用层是不受影响的

后续要做的 Upgrader 之类的，也是框架胶水层 wrap 一下，应用层的逻辑其实都可以不受影响。

BTW，websocket 实现得差不多了，争取下周放出来

@abersheeran 其实类似兄弟你喜欢有栈协程的问题，我在主帖 “两点澄清”部分有解释，只是大部分人 Get 不到这些点，心酸，:joy:

除了 golang 、erlang，其他那些手动档的协程其实都是垃圾，并没有减轻代码逻辑复杂度的人脑解析负担，甚至比回调更让人恶心。。。

@wslzy007 http 1.x 已经支持，详情请看我上面几楼的回复

@ERR @byte10 为了省去虚拟网络或者 docker 或者多台机器之类的部署环境的麻烦，1m 连接测试的代码是开了多个监听端口，因为即使只是 1 个端口，实际处理接受连接和数据读写的 poller 还是那些个 epoll fd 协程，所以开多个端口对性能影响不大，但是测试起来就方便多了，如果想只用一个端口，代码稍微改下或者各位用自己的 cleint 代码并部署就行了

@byte10 nbio http 如果想支持 fasthttp 这种也不难，参考默认的支持标准库的 Processor 实现一份 Processor 就行了，不过我暂时没当期在 nbio 自带一份实现给它，以后闲了考虑给它写个

@lesismal 修正：虚拟机是 6c12t 的

@byte10 请看我上一楼的回复，有兴趣的话来跑下 1m 测试，老夫这一两周撸的 http parser 和 nbio 基础之上的 http server，并且兼容标准库的 http.Handler，所以除了 fasthttp 那种没使用标准库的，其他的 gin 、iris 、echo 、beego 等各种，都能比较容易地使用 nbio http 作为网络层，实现内存的巨大节约。不同的业务类型对性能和资源的考量不一样，响应速度和内存可能不能兼得，老夫也正考虑研究下 golang 里更高性能的协程池是否能搞定，如果能搞定，那就可以兼得了

后续还考虑支持 websocket 、http 2.0，但是每一项也都是个大活，http 1.x 已经基本完成，还剩下边边角角的细节优化项和测试，也是要耗费老夫不少时间，慢慢搞，老夫一定要让 golang 更强

@ERRASYNCTYPE golang 标准库每个连接一个协程，当前版本一个协程栈应该是 8k，连接数多了内存消耗就巨大了。其他语言多数是异步底层，每个连接不需要固定分配这么大的内存。连接数少的时候 golang 内存浪费不明显，连接数多的时候，会很明显

另外，最近一周多我又撸了份 http 1.x 的 parser，封装了 http server，在 nbio 基础上可以跑 http server 了，兼容标准库 http.Request，百万连接测试请看这里：

https://github.com/lesismal/nbio/tree/master/examples/http/1m

我单虚拟机做这种测试，虚拟机是 6C8T 的，因为客户端服务器都在这个虚拟机，所以没测百万那么多，50w 连接数，2k qps 的情况，server 端 cpu 平均 100%以内（ load 小于 1，不到单核），client 请求是多协程并发一直进行的不是平均的所有 server 端有偶发尖刺到百分之几百算正常，内存占用 400-500M
连接数更多、qps 更高内存会消耗更多些，但是跟其他语言异步底层相比，内存已经很省了，并且，50w 连接数，这种简单的 echo 测试，也随便能跑到 qps 5w+，定制少用协程的话可以跑 10w+。

另外，nbio http 从数据的 read 到 parse 到 handle request，这三个流程之间的协程使用都是可定制的，如果是做 nginx 类似的网关代理这种基础设施、不需要数据库等耗时操作，完全可以直接在 read/poller 协程内进行 parse 和 handle request，最大程度减少跨协程数据传递和调度的成本，细节我会在以后的帖子中慢慢整理，最近都忙于编码，还有很多细节或者性能优化可以做

希望能让 go 支持更广泛的业务，否则单就高阶的高并发，还真难干得过 java netty 或者其他异步方案

@newmlp 百万连接不是什么难事，难的是大量连接下的高请求量、吞吐量。真实的商业项目也很少真正单机搞百万连接的，避免万一故障。
但是不同框架对高连接数的优化，不只是为了达到百万连接数的目的，而是在这个基础上对整个系统各项资源消耗和指标的优化，对于 golang，同步模式的大量协程带来的内存和 cpu 调度浪费太大，异步框架还是有很大意义的