提问：请问nbio和gws哪个更侧重对低延迟做优化呢

[szmcdull]

看测试数据好像都差不多

[lxzan]

nbio_blocking模式和gws的延迟和吞吐相差不大, 看你更喜欢用哪个了

[lesismal]

使用标准库阻塞接口的Conn情况下（nbio对应的是blocking、std），头部的几个性能差距不大，包括最流行的gorilla和fork的几个。因为差不多、受到压测时段系统整体情况差异的影响，所以没有哪个固定第一，但我们几个跑过很多轮，gws和quickws排第一的时候多些，quickws做得晚也没怎么推所以star不多、但质量也够好。
nbio最近优化了buffer减少了小对象分配和gc压力、最新版本可能会提高一点点，但我还没重新跑过，估计即使有提高应该也不会太多。

相比于最流行的gorilla，gws和nbio更容易使用些，不需要用户自己去额外封装读写，直接就可以设置处理message，写也可以使用自带的异步方式（gws WriteAsync系列，nbio使用NewUpgrader()创建的upgrader默认配置是标准库Conn异步写、nbio epoll管理的conn本身也是非阻塞），异步写可以避免广播逻辑中单个或者少量Conn阻塞导致循环中的所有Conn都需要等待。

nbio最初的设计是为了解决海量连接数场景的压力问题。golang标准库Conn需要为每个Conn至少使用一个协程处理读，内存和GC压力都比较大，服务不稳定，容易STW。如果你的业务连接数量较大并且想节约硬件成本，可以用nbio IOModMixed/IOModNonBlocking，避免海量连接使用标准库的阻塞接口的Conn的开销。

[szmcdull]

非常感谢，我的场景连接数量不会太多，顶多几百，主要是用在高频交易场景，对延迟非常敏感😂
对于接口，我倒是有一个用例，就是希望能知道剩余还有多少数据没读完，因为有时候行情数据太多，如果处理不来其实可以跳过中间过时的行情直接处理最新的，而一般的回调接口比较难做到这点，只能全部把回调传过来的数据复制自己的缓冲区，再另外的协程去过滤处理，这无疑多了一些异步通知甚至内存分配的开销，额外增加了延迟😂

[lxzan]

非常感谢，我的场景连接数量不会太多，顶多几百，主要是用在高频交易场景，对延迟非常敏感😂 对于接口，我倒是有一个用例，就是希望能知道剩余还有多少数据没读完，因为有时候行情数据太多，如果处理不来其实可以跳过中间过时的行情直接处理最新的，而一般的回调接口比较难做到这点，只能全部把回调传过来的数据复制自己的缓冲区，再另外的协程去过滤处理，这无疑多了一些异步通知甚至内存分配的开销，额外增加了延迟😂

自己写个队列, 消息积压太多就抛弃队头一些数据

[lesismal]

可以用 LRU，设置个最大 size，自动丢弃旧的就行了

[lesismal]

如果多个连接的数据要排队异步处理，环形队列也行，滚动更新、丢弃旧的

而一般的回调接口比较难做到这点，只能全部把回调传过来的数据复制自己的缓冲区，再另外的协程去过滤处理，这无疑多了一些异步通知甚至内存分配的开销，额外增加了延迟

如果单个连接不是大量高频消息并且需要串行处理，那可以避免异步的buffer拷贝和逃逸之类的

gws和gorilla这些都可以自己处理读、读到一个decode一个处理一个、然后下一个，不用丢给异步的。
@lxzan gws的message回调是不是异步来着、或者是不是可以设置同步还是异步来着，我不记得了

nbio如果是blocking mod的连接、OnMessage仍然是读协程里、回调的时候不是异步，直接处理buffer、decode和逻辑

[lxzan]

@lesismal 默认一个协程处理消息回调，可以配置多个

[szmcdull]

LRU是有锁的吧。ws推送过来的是json，推送太快的时候解json有点跟不上，如果跟recv同一个线程就会阻塞recv，tcp那层会缩小window并通知服务端慢点发送，如果慢太多，那服务端就会发送超时就直接就给我reset了
有的场景可以用环形队列直接丢弃最老的，但有的不行(至少得解了json才能知道能不能丢)估计就得多线程解json了，或者针对特定的json消息格式看能不能优化到跟得上

[lesismal]

LRU是有锁的吧。ws推送过来的是json，推送太快的时候解json有点跟不上，如果跟recv同一个线程就会阻塞recv，tcp那层会缩小window并通知服务端慢点发送，如果慢太多，那服务端就会发送超时就直接就给我reset了 有的场景可以用环形队列直接丢弃最老的，但有的不行(至少得解了json才能知道能不能丢)估计就得多线程解json了，或者针对特定的json消息格式看能不能优化到跟得上

不同结构或者模式的优点可能不会兼得，我们不知道你门业务的具体情况，这个需要你自己来选择用哪种、对比不同方式调优和取舍

[lxzan]

LRU是有锁的吧。ws推送过来的是json，推送太快的时候解json有点跟不上，如果跟recv同一个线程就会阻塞recv，tcp那层会缩小window并通知服务端慢点发送，如果慢太多，那服务端就会发送超时就直接就给我reset了 有的场景可以用环形队列直接丢弃最老的，但有的不行(至少得解了json才能知道能不能丢)估计就得多线程解json了，或者针对特定的json消息格式看能不能优化到跟得上

有个库可以部分解析JSON, 性能会好很多

先检查下是否需要抛弃消息

[szmcdull]

LRU是有锁的吧。ws推送过来的是json，推送太快的时候解json有点跟不上，如果跟recv同一个线程就会阻塞recv，tcp那层会缩小window并通知服务端慢点发送，如果慢太多，那服务端就会发送超时就直接就给我reset了 有的场景可以用环形队列直接丢弃最老的，但有的不行(至少得解了json才能知道能不能丢)估计就得多线程解json了，或者针对特定的json消息格式看能不能优化到跟得上

有个库可以部分解析JSON, 性能会好很多

先检查下是否需要抛弃消息

已经是用gjson了