Java/Scala vs Linux для неблокирующих (http) io

Question

Итак, как сравнить объекты для использования Linux, родного для Java/Scala, для записи неблокирующих io? На момент написания статьи я просто изучал/играл с написанием Http-сервера. Так что извинитесь, если у меня есть некоторые основные пробелы в моих знаниях. В настоящее время все написано в Scala, используя поток io. Если я использую собственный код для системных вызовов, то, очевидно, мне нужно установить связь между собственным C/C++ и моим кодом Scala. Я уже делал немного JNI, и мне также интересно экспериментировать с запуском собственного кода в отдельном процессе.

Однако я хочу подчеркнуть мой вопрос не о Scala/Java родного интерфейсе, а чисто о преимуществах если использовать встроенную систему вызовов библиотеки через экосистему Scala/Java для Http порции. Если я использую native, я могу использовать обновленные ядра. В некотором роде этот вопрос касается обучения, будь то инвестировать свое время обучения в экосистему Linux или в систему Java/Scala io и без блокировки io. Я знаю, что есть переход на шунтирование TCP в пользовательское пространство, которое может предложить интересные возможности.

Первоначально я сфокусирован на сервере TCP/IP, что, без сомнения, является основным прецедентом, но также и другими io, такими как доступ к базе данных.

Редактировать Развернуть: Является ли java.nio полностью асинхронным или действительно использует форму опроса за кулисами? Можно ли получить полную асинхронность с использованием native или вы всегда зависите от какой-либо формы опроса? Является ли java.nio полностью использовать современные асинхронные io-установки ядра? Мой вопрос также стимулируется этой статьей: Streaming video on 10 Gigabit Ethernet and beyond ставит под вопрос использование обычных сокетов.

Answer 1

Это действительно зависит от ваших требований к проекту. Если у вас ограниченные ресурсы машины, либо потому, что вы начинаете с малого с ограниченным количеством лошадиных сил под капотом, либо потому, что вы получите очень большой размер, и вы не хотите, чтобы ваши расходы шли быстрее, чем ваш доход, то программирование ближе к оборудованию становится очень важным.

Стоимость программирования настолько близка к оборудованию, что существенно увеличивает затраты на разработку. Достигнуты успехи в поддержке этого уровня программирования: Seastar - это более новая библиотека, которая утверждает, что предлагает такую ​​возможность, которую вы просите.

С другой стороны, Scala с Akka IO чрезвычайно эффективна. Это позволяет вам писать сжатый код, который четко выполняет задание, которое вам нужно, не перебрасывая данные через границы.

Это действительно сводится к следующему: вы оптимизируете свой дизайн, прежде чем знаете реальные затраты на реализацию? См. this stackoverflow conversation.

Answer 2

Для обслуживания Http? Я бы сказал, что на самом деле нет никаких преимуществ.

С самого начала сеть была испечена в Java, она была первоначально предусмотрена для использования в приставках и встроенных устройствах. С более поздними поколениями у вас есть полная поддержка неблокирующего ввода-вывода через API NIO.

Все это будет делегировать любой IP-стек, предоставляемый вашим ядром, он отлично работает на ядрах с краю ядра.

Scala работает на вершине JVM и получает все это бесплатно.

Возможно, прецедент для выхода на собственный код с использованием сети - это если вы хотите играть с экспериментальными транспортными протоколами или использовать одну из сторонних реализаций SCTP для Windows. Ни одно из этого не относится к HTTP + TCP.