试试我这个： 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 调度浪费太大，异步框架还是有很大意义的

@wslzy007 只是为了压测做的那种特别简单的 http 解析没什么意义，比如一些网络库加的那个 http echo 压测，只解析了这个测试用的特定的 http 请求，这个写起来也简单，解析到\r\n\r\n 直接回包就行了，但是对于商业项目毫无帮助，用这种压测跟别人完整功能的 http 框架对比性能也没有任何意义。只是对比网络库的话，可以跟其他网络库比吞吐量之类的就可以了，有兴趣可以参考这里：
https://github.com/lesismal/go_network_benchmark

我对 http 的支持可能需要较长时间，暂时规划几步走：
1. http 1x parser 基础功能，为了省体力，考虑直接参考 go 标准库重写解析，尽量兼容标准库，这样的话，wrap 个中间层、其他基于标准库的框架 /router 方案 就能改用 nbio 了
2. tls，现在已经魔改 1.6 标准库的 tls 支持了 nbio 的 non-bloking，但是标准库原来的 tls 代码写得有点性能不友好，很浪费，我还是打算以后有档期了全重写一份，但是目前可以用，暂时不从头搞、太耗体力了
3. websocket 支持
4. http 2

每一项都需要较多时间，慢慢搞

@fucUup 网络框架这一层处理数据收发。rpc 请求的限制，你在 rpc 框架收发数据的层完全可以自己限制。
兄弟，分层的理念你可以再加深下理解，不同的层处理自己的事情，从内核到应用，或者网络协议栈不同的层，都是各自处理自己层内的事情，该留给更高层去处理的留给更高层去处理，否则就拿你 rpc 4M 的来举例，如果网络库这一层写死了限制 4 M，你在其基础之上实现的 rpc 框架舒服了，但是其他人在其基础之上实现的其他业务可能需要大于 4M，那怎么办？所以，下层在自己层内资源可控的前提下提供上层所需的扩展机制、接口，而不是下层直接做这些限制

@fucUup 兄弟，你上面问的是为什么你们谷狗用 ET 而我的用 LT，那我不给你讲原理和实现原因，该怎么回答你？难道因为你们某个项目用了 ET 所以就应该用 ET ？那我是不是可以回答因为 redis 用了 LT 所以用 LT ？

工程质量，谷狗项目用啥并不是工程质量的唯一标准。另外，这里说网络库，网络库跟 MapReduce 这两者本来就是处于基础设施的不同层次，网络仓库作为数据传输的基础设施，MapReduce 是在网络或者其他整合生产消费的数据层之上的层，更多的是需要对数据生产消费的整合和加工，跟网络库本身没有可比性