ring buffer在高在线量场景可能导致高内存占用 about gev HOT 4 CLOSED

另外，异步库与标准库单纯对比吞吐量，其实实际意义也不大，因为标准库方式的包体解析逻辑可能更简单，并且异步库解析完整包后通常需要跨协程传递再由其他逻辑协程池处理，时空亲和性、调度亲和性、生命周期等各种实际情况加起来。

7层业务下、普通在线量比如不同硬件规格10-100k这种量级，异步库未必比标准库有相应性能的优势

from gev.

虽然我读懂了，但是还是建议你发表这种见解时组织一下语言。

from gev.

虽然我读懂了，但是还是建议你发表这种见解时组织一下语言。

单就内容本身，已经表达的够清楚了，问题本身稍微有点复杂，即使再加上1、2、3、表格，一般的逻辑程序员也看不懂。这个只是给 Allenxuxu 交流、建议的，目测应该能看懂的

from gev.

虽然我读懂了，但是还是建议你发表这种见解时组织一下语言。

我在 nbio 里做了很多功能支持和细节优化，tls/http/websocket，both server and client side，http的标准库兼容，websocket的全量测试，但这些都不是最难的。
最难的是把这个几个层的内存优化打通。不能简单使用2^N的内存池，因为异步流解析涉及half-packet，而且需要应用层协成池，所以buffer是需要跨协成传递的，buffer生命周期不确定，不能像使用net.Conn的方案那样简单地为每个连接复用同一个buffer（阻塞读一个、处理一个、然后再读下一轮读和处理）。
整体来说，去年优化内存这块花费了我最多的时间，其次是魔改标准库的tls支持异步流解析。

从某些使用方式的角度讲，异步库使用2^N的内存池在parser解析的过程中可能会有更多性能浪费，或者用ring buffer作为读或者写的cache与连接绑定、在连接数很大的时候会造成巨大内存消耗、甚至节省的协程数量的资源都无法弥补回来

这次还是没组织语言，能看懂就行吧，这些都是实现过程中总结的，我还希望在有可能的地方继续提升自己的库，所以希望跟大伙多多交流

from gev.