session send queue overflow! MaxWaitMessages限制问题

[ridgew]

我前段时间关注作者的BeetleX组件很久了，因为使用了Bumblebee做netcore的网关转发，特别看重网关配置的管理插件Configuration；同时也发现作者相关的性能呢测试对比，加上开源就没有再自造轮子。昨天产品做集成测试发现压力还不到几百个网关转发请求，就连续出现“session send queue overflow!”的错误，然后中止了连接。

不知道如何调整，还是不敢轻易使用该组件啊

[beetlex-io]

这个设计的目的防止client不停地发送TCP请求，但没有及时接收服务端回发的TCP数据时，这些消息会落到队列中，当队列里的消息超过MaxWaitMessages则服务端会主动关闭连接。

[ridgew]

这个设计的目的防止client不停地发送TCP请求，但没有及时接收服务端回发的TCP数据时，这些消息会落到队列中，当队列里的消息超过MaxWaitMessages则服务端会主动关闭连接。

其实作为HTTP网关，这里的设计需要考虑客户端http请求的不友好连接状态，服务端如果输出HTTP头是Keep-Alive:true;但轻量级HTTP客户端如使用WebClient发送Http做简单的HTTP请求，都是使用之后就断开了，并没有友好的遵循HTTP RFC2616里的定义实现。现代的浏览器倒是对TCP Socket相对友好些，一般开发者就不管这些了，我认为这里是新建的连接加上没关闭的旧连接，所以一会就不够用了。相比基于libUV的其他服务端，组件里除了使用了异步的SocketArguments对象，没再发现其他改进性能的地方。作者是否有考虑基于libUV，disruptor这类重构该通信组件？

[ridgew]

如何有效的规避这些不规范的http连接呢，只改大默认的参数50肯定不是可行的方法。

[beetlex-io]

MaxWaitMessages是针对单会话的不会影响全局，所以不规范的http连接不太关心。
不过碰到非Keep-Alive:true的情况，则需要考虑maxconnections这个限制，毕竟client close后server可能并不能及时释放（留存时长也不定），这个时候需要给合MaxConnections和SessionTimeOut(单位秒)来解决

[beetlex-io]

性能上的优化暂时没有考虑，如果要优化可能需要重新设计，但我感觉在网络这一块依赖于.net的话已经没有多大的空间，techempower的多项测试在基础方面已经超过asp core的基础通讯模块。

[yuzd]

@ridgew 你是怎么调整的 有找到方案吗

[ridgew]

@ridgew 你是怎么调整的 有找到方案吗
暂时放弃，改用nginx了。