netty - 在blip场景中的Netty连接处理

我们在游戏公司中使用Netty3.2.1进行客户端和服务器之间的连接管理。我们的目标是提高

能够处理像网络中断这样的blip场景，并且必须能够尽快恢复。
增加单个服务器可以处理的连接数，而不删除现有的已连接套接字。

Blip Scenario 在实时环境中，由于ISP故障可能会出现暂停，因此所有现有客户端（我们的客户端在现有连接断开后触发重新连接）连接将同时断开并重新连接。例如，如果服务器连接到25000个客户端，则所有25000个客户端在blip期间尝试同时连接回服务器，这给服务器带来了巨大压力。由于Netty旧版本不提供启用/禁用 OP_ACCEPT 的功能，因此我们开始限制超过100个并发连接ssl握手限制的连接。当超过限制时，我们将boss线程暂停一秒。我们尚未准备好使用提供该功能的Netty 4.0 Beta版本。

我们在压力测试期间观察到的其他情况是，如果服务器上存在大量传入连接，则需要花费大量时间来接受所有传入连接并稳定（25 K连接约30分钟，全部25 K试图同时连接）。但是如果我们慢慢增加负载，netty能够在很短的时间内（大约3到5分钟）轻松接受所有连接。我们希望构建系统，以便我们能够灵活处理blip场景。

我在现有的Netty Jar中添加了一些日志，当客户端在大负载期间断开连接时，它似乎在read（）方法中失败。
使用Netty3.6 Final jar，没多大帮助
是否会使用执行处理程序帮助？
禁用限制会导致服务器上出现OOM异常。

请建议任何可能的方法来解决此问题。有没有其他方法来限制连接？

设置详细信息和配置

客户端 - JMeter框架 - 2 GB计算机加载 - 50000个客户端每秒没有消息 - 12000条消息/秒。消息是客户端hello，并且将hello切换为字符串。所有机器上的ulimit都是1,00,000

服务器 - 12 Core，HT和48 GB ram 工作线程 - 50（没有核心的两倍核心没有核心变成24） Linux机器的所有TCP内部缓冲区都配置为使用峰值限制。

我们的Pipeline处理程序具有以下处理程序

pipeline.addLast（sslHadler） - 内置处理程序中的Netty
pipeline.addLast（messageEncoder） - 只对字节进行编码和解码，并根据需要将它们转换为消息帧。
pipeline.addLast（messageDecoder）
pipeline.addLast（Businesshandler）

在blip场景中的Netty连接处理

1 个答案: