мы используем Netty3.2.1 в нашей игровой компании для управления соединением между клиентом и сервером. Наша цель - улучшить
- Способен обрабатывать такие сценарии, как сбои в сети, и должен иметь возможность восстанавливаться после этого как можно скорее.
- Увеличьте количество подключений, которые может обрабатывать один сервер, без отключения существующих подключенных сокетов.
Сценарий кратковременных сообщений В среде реального времени существует вероятность сбоев из-за сбоя поставщика услуг Интернета, поэтому все существующие клиентские (наши клиенты запускают повторное подключение после разрыва существующих подключений) соединения будут прерваны и повторно подключатся одновременно. Например, если сервер подключен к 25000 клиентам, все 25000 клиентов пытаются подключиться к серверу одновременно во время сообщения, что оказывает огромное давление на сервер. Поскольку в более старых версиях Netty не предусмотрена функция включения / отключения OP_ACCEPT, мы начали регулировать соединения сверх лимита в 100 одновременных подключений ssl-рукопожатий. Мы приостанавливаем поток босса на секунду, когда предел превышен. Мы еще не готовы использовать бета-версию Netty 4.0, которая предоставляет эту функцию.
Другой сценарий, который мы наблюдали во время нашего стресс-тестирования, заключался в том, что если на сервере огромное количество входящих подключений, требуется много времени для принятия всех входящих подключений и стабилизации (около 30 минут для 25 тысяч подключений, все 25 тысяч пытаются подключиться. в то же время) . Но если мы увеличим нагрузку медленно, netty сможет легко принимать все соединения за очень короткое время (около 3-5 минут). Мы хотим построить систему таким образом, чтобы она была устойчивой для обработки сценариев с ошибками.
- Я добавил несколько журналов в существующий Netty Jar, и похоже, что метод read () не работает, когда клиенты отключаются во время огромной нагрузки.
- Использование Netty3.6 Final jar, не сильно помогло
- Поможет ли использование обработчика выполнения?
- Отключение регулирования привело к исключению OOM на сервере.
Пожалуйста, предложите любые возможные подходы к решению этой проблемы. Есть ли другие способы дросселировать соединения?
сведения о настройке и конфигурации
Клиенты - инфраструктура JMeter - загрузка машин 2 ГБ - 50000 клиентов, количество сообщений в секунду - 12000 сообщений в секунду. Сообщение приветствует клиента и разделяет приветствие в виде строк. ulimit на всех машинах - 1,00,000
Сервер - 12 основных, HT и 48 ГБ рабочих потоков RAM - 50 (в два раза больше ядер с HT, и количество ядер становится 24). Все внутренние буферы TCP на Linux-машинах настроены для работы с пиковыми нагрузками. пределы.
У нашего обработчика конвейера есть следующие обработчики
- pipeline.addLast (sslHadler) - Встроенный обработчик Netty
- pipeline.addLast (messageEncoder) - просто кодирует и декодирует байты и преобразует их по мере необходимости в кадры сообщения.
- pipeline.addLast (messageDecoder)
- pipeline.addLast (Businesshandler)
