Libing Chen

@OlegDokuka do you have any demo for RSocket on QUIC? https://github.com/reactor/reactor-netty/releases/tag/v1.0.12

@OlegDokuka @violetagg How about a demo transport implementation for QUIC ? and @gabis-precog did an implementation with RSocket-PY https://github.com/rsocket/rsocket-py/blob/master/examples/server_quic.py

给我们一些时间测试一下，稍后给大家报告。 Netty在一定的硬件资源下能支持100万并发连接，但是还要快速响应，程度高的流量负载，这个需要一个可靠性测试，大家可以看一下这个文章： https://github.com/smallnest/C1000K-Servers https://colobu.com/2015/07/14/performance-comparison-of-7-websocket-frameworks/ ``` Netty, Go, Node.js, Undertow, Vert.x都能正常建立百万连接。 Jetty, Grizzly 和 Spray未能完成百万连接 Netty表现最好。内存占用非常的少， CPU使用率也不高。 尤其内存占用，远远小于其它框架 ``` 我们给出的这个单机数据，是之前内部基于Netty测试的经验值，可能还需要更新。 RSocket Broker目前设计是支持多租户的，我们也是希望支持更多的连接，但是受限于语言和框架，当然还有稳定性和功能等考虑，在PK支持做大连接数这个方面，我们可能不会刻意和其他语言对比连接数上的优势。 我们在做一个RSocket纯C的SDK，到时应该和业内的单机最大连接数系统应该都会一致的，但是使用C来实现Broker，这个可能相对比较难一些。 目前RSocket C SDK主要是为IoT设备接入提供支持的，当然RSocket Broker也会提供MQTT的gateway，也是基于Netty的MQTT开发的。

@YuanHuCoding 遇到Nettty高手啦。测试没有任何配置，能给一个Netty调优的建议吗？ 我添加到wiki中，也方便其他人了解具体的细节和Netty配置对线上产品的性能影响。 :)

@YuanHuCoding 我看到PR已经merge啦，如果使用这个特性，要做这么调整吗？

@YuanHuCoding 问一个 问题， io.netty.recycler.ratio 默认为8，如果是长连接场景，是不是设置为1后就进行全部回收啦？ 这种做法对RSocket更于好一些？

@YuanHuCoding 对于RSocket的使用情况来说，如机房内部，即便流量降低，这个长连接也不会断的，除非我们将这些服务器或者容器关闭啦。如果是IoT的场景，如手机长连接到云端，即便我们睡觉啦，但是这个连接还是不断的，这个可能和HTTP流量有些区别，如果是这个情况，我们评估一个最大连接数，如50万，那么io.netty.recycler.ratio为2是不是比较合理？ 高峰和低峰对RSocket的连接数影响并不大。 如果是这样的情况，我还需要主要什么吗？ 内存的情况，目前和你说的一样，目前使用的是PooledByteBufAllocator的direct Buffer，这个也是默认方式。 应用中我们做了一些元信息的bytebuf缓存，都是direct buffer。

备注一下： https://github.com/netty/netty/issues/10348 ``` The title doesn't look good to me. We built our Load Balancer on top of Netty and doing 10M connections is a piece of cake for us...

I created a Rocker demo with Spring Boot 2 https://github.com/linux-china/rocker-template-demo

服务粘性调这个确实比较麻烦。 目前还有一个特性，就是broker将一个服务的对应的服务器列表发送给客户端，客户端在构建服务时，随机指定某一server id，目前GSVRoutingMetadata的endpoint是支持id路由的，只需将endpoint的值设置为`id:1134` 这样，这样服务就是始终与某一provider通讯。 如果服务列表发生变化，客户端只需要重新指定一下 id 即可。 在broker中维护这一特性有些复杂，同时也会造成broker的复杂性，使用这样特性的应用并不多，可以考虑在客户端实现，可以创建另外一个 rsocket-sticky-session.jar ，来实现这一功能。 另外broker端，即便根据ID找不到service provider，同样可以选择其他的一个service provider，不会影响服务调用，只是路由到其他service provider啦。