【发布时间】：2013-03-23 12:37:19
【问题描述】：
我们在游戏公司中使用 Netty3.2.1 来管理客户端和服务器之间的连接。我们的目标是改进
- 能够处理网络中断等突发事件，并且必须能够尽快从中恢复。
- 在不丢弃现有连接套接字的情况下增加单个服务器可以处理的连接数。
Blip 场景 在实时环境中，由于 ISP 故障，可能会出现 blip，因此所有现有客户端（我们的客户端在现有连接中断后触发重新连接）连接将同时中断并重新连接。例如，如果一个服务器连接了 25000 个客户端，所有 25000 个客户端在 blip 期间尝试同时连接回服务器，这给服务器带来了巨大的压力。由于 Netty 旧版本不提供启用/禁用 OP_ACCEPT 的功能，我们开始限制超过 100 个并发连接 ssl 握手限制的连接。当超过限制时，我们暂停老板线程几秒钟。我们还没有准备好使用提供该功能的 Netty 4.0 Beta 版本。
我们在压力测试期间观察到的其他情况是，如果服务器上有大量传入连接，则接受所有传入连接并稳定下来确实需要很多时间（25 K 连接大约 30 分钟，全部 25 K尝试同时连接）。但是如果我们慢慢增加负载，netty 能够在非常短的时间内（大约 3 到 5 分钟）轻松地接受所有连接。我们希望构建系统，以便能够灵活地处理突发事件。
- 我在现有的 Netty Jar 中添加了一些日志，当客户端在巨大负载期间断开连接时，它似乎在 read() 方法中失败。
- 使用Netty3.6 Final jar，没有多大帮助
- 是否会使用执行处理程序帮助？
- 禁用限制会导致服务器出现 OOM 异常。
请提出解决此问题的任何可能方法。 还有其他限制连接的方法吗？
设置细节和配置
客户端 - JMeter 框架 - 2 GB 机器 加载 - 50000 个客户端 每秒消息数 - 12000 条消息/秒。消息是客户端问候和服务器问候作为字符串。 所有机器上的 ulimit 为 1,00,000
服务器 - 12 核、HT 和 48 GB 内存 工作线程 - 50（两倍于 HT 的核心数，核心数变为 24） linux 机器的所有 TCP 内部缓冲区都配置为使用峰值限制。
我们的管道处理程序有以下处理程序
- pipeline.addLast(sslHadler) - 内置处理程序中的 Netty
- pipeline.addLast(messageEncoder) - 只是对字节进行编码和解码，并根据需要将它们转换为消息帧。
- pipeline.addLast(messageDecoder)
- pipeline.addLast(Businesshandler)
【问题讨论】：
标签： netty nio throttling