Я в процессе выбора сетевой библиотеки реализую систему клиент/сервер, которая не может сэкономить микросекунду. Он будет осуществлять собственный протокол для отправки и получения сообщений. Я ищу хорошую инфраструктуру NIO, которая позволит мне легко развить сервер и клиент, не беспокоясь о деталях селектора низкого уровня. Все рекомендуют мне Netty, но я бы хотел поэкспериментировать с двумя или тремя другими альтернативами, прежде чем совершать свою команду с помощью фреймворка. Единственное, что мне не понравилось в Netty, - это то, как он обрабатывает ByteBuffers с его собственной реализацией ByteBuf и подсчетом ссылок. Может ли кто-нибудь поделиться своими мыслями и альтернативами?
Каковы альтернативы Netty для высокопроизводительных сетей?
Ответ 1
Мы разработали сетевую библиотеку NIO, которая работает менее чем через 2 микросекунды по шлейфу без создания мусора для GC. Как отметил Питер Лори, родной селектор JDK производит много мусора, но мы устранили все эти утечки мусора, внедряя наш собственный селектор epoll. Занятый ожидание селекторной нити отлично подходит для латентности, но должен быть баланс, чтобы не сжигать чип или не потреблять много энергии. Наша реализация селектора использует низкоуровневые трюки для реализации своего рода энергосберегающего режима, который заботится об этом балансе.
Помимо CoralReactor, вы также можете взглянуть на Grizzly и Mina, но мы еще не играли с этими фреймворками.
Для некоторых тестов производительности Netty TCP вы можете посмотреть здесь.
Ответ 2
Это предполагает, что вы действительно хотите сэкономить каждую микросекунду. Большинство приложений не имеют таких строгих требований.
Если вы хотите сэкономить микросекунды, вам нужно использовать неблокирующую NIO для потоков на выделенном процессоре. Это не хорошо масштабируется, так как вам нужно иметь много ЦП, но минимизирует задержку для обработки ввода-вывода. Я предлагаю вам также связать изолированные процессоры, чтобы минимизировать дрожание.
Вам следует избегать использования селекторов, поскольку они блокируют и/или создают немало мусора, добавляя к паузам GC.
Также, чтобы минимизировать задержку, вы захотите использовать сетевой адаптер с низкой задержкой, такой как Solarflare.
Вы захотите использовать push-парсер, чтобы длинные сообщения можно было декодировать/анализировать при загрузке. т.е. вы не захотите ждать, пока все сообщения будут получены, прежде чем начать.
Использование этих трюков в комбинации может сэкономить 10 - 30 микросекунд на каждом запросе или входящем событии.
Netty является лучшим решением для масштабируемости, то есть с более высокой пропускной способностью сети, но с небольшими затратами на задержку, как и большинство платформ, основанных на поддержке веб-сервисов, где допустимы задержки в миллисекунды.
Ответ 3
Если вы используете хотя бы несколько Scala, Spray, это отличная альтернатива Netty. В долгосрочной перспективе платформа воспроизведения, например, намеревается перейти от Netty к Spray. Spray предлагает различные уровни абстракций TCP. Это:
- Уровень фрагмента
- Уровень запроса (HttpRequest/HttpResponse)
- Уровень объектов с маршаллированием
Чем глубже вы копаетесь в стек, тем больше необработанной информации. В API уровня фрагментов вы приближаетесь к оригинальным байт-буферам. Я никогда не использовал этот низкий уровень абстракции, но я слышал хорошие вещи.
Спрей строит поверх Akka IO, который снова построен поверх Java NIO. Вся функциональность обтекает абстракции Actor, что упрощает создание параллельных приложений с использованием Spray. Я думаю, что чат-сервер будет идеальным вариантом использования. Поскольку Akka предлагает Java API, вы должны использовать Spray с использованием этого API. Однако вам, вероятно, потребуется время от времени читать некоторые источники Scala. В конце концов, Спрей полностью сольется с Аккой.
Изменить: Цитата с сайта Spray: "Спрей больше не поддерживается и заменен на Akka HTTP. Playframework начала экспериментальную поддержку Akka HTTP Server, начиная с Play 2.4.X. Play 2.6.X, полностью переносится на серверный сервер сервера Akka.