lesismal
commented
2 years ago nbio支持EPOLLET，也支持 g.OnRead 设置用户自己处理读事件，这样就相当于只传递事件给应用层、应用层可以自己在事件到来时去协程池取一个协程进行实际的读写。 如果是异步读，应该使用 EPOLLET + g.OnRead，因为如果用 EPOLLLT 并且跨协程读，读还没开始就可能下一轮 epoll loop 了、会有较多的重复触发。
我之前在nbhttp里试过这种，但是压测数据并没有提升。因为除了epoll loop里的事件，还涉及读buffer，现在的是每个epoll loop对应一个buffer，如果是 epoll loop 只传递事件、另外的协成池去处理实际的读，协程池里的每个协程仍然需要对应一个固定的buffer。对于nbhttp，使用的协成池里的协程是： https://github.com/lesismal/nbio/blob/master/taskpool/mixedpool.go 这个pool benchmark似乎比 panjf2000/ants 要好一点，相比直接go也可以控制size，但缺点是不容易每个协程对应一个buffer，其实是可以再对应一个sync.Pool buffer，但还涉及到协程池最大并发时的buffer数量要多，比如协程池size 2w，最大就能对应成2w个buffe，这也会消耗更多内存，因为相比于标准库，nbio主要优势是内存占用、gc之类的，所以nbhttp并没有为了更好点的性能尝试去把这块放开一些内存使用
但是其他自定制协议，是可以这样做的，毕竟协程池的那点数量个buffer相比于海量并发时每个连接一个协程，已经节省了大量的内存了
irying
我今天用这个仓库跑了下300跟1000连接的压测，数据如下：
300连接的时候
1000连接的时候
对比发现异步库跟原生Go net，在高分位时延这块，比如TP99跟TP999,，异步库是大大落后于Go net。 分析异步库的事件处理机制，我猜想原因大概是： 异步库处理读写事件循环时，是遍历所有事件，逐个去处理对应的fd，比如读取完当前fd上的数据再处理下一个fd。 这样导致越往后遍历的fd，响应越慢，比如nbio这里
而Go net是获取有读写事件的协程列表，逐个唤醒，让具体协程去处理读写事件，也就是只负责唤醒。
我的疑问这里有没有优化空间来减少高分位的时延，目前我能想到的是利用ringbuffer来实现引用读，减少遍历里边的Read耗时。