Java NIO хорош для низкой задержки или высокой пропускной способности?

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

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

Однако я не вижу, как неблокирующий ввод-вывод напрямую приносит пользу приложению с низкой задержкой.

Я предполагаю, что «асинхронное поведение — отличный способ избежать конфликтов». Если это так, низкая конкуренция означает низкую задержку. Следовательно, NIO может помочь с низкой задержкой. Имеет ли это смысл?


java throughput nonblocking low-latency nio
person de.coding.myth    schedule 19.01.2014    source источник
comment
Ваш пост состоит в основном из несоответствий. Здесь трудно найти вопрос, на который можно ответить.   -  person user207421    schedule 21.01.2014
comment
@EJP, если непонятно, прошу прощения. Я просто хочу знать, может ли использование NIO принести пользу приложению с низкой задержкой. Если да, то как?   -  person de.coding.myth    schedule 21.01.2014
comment
Я был бы удивлен. Блокируя ввод-вывод и потоки, вы получаете любой механизм планирования, который реализует операционная система, и можете поспорить, что он очень точно настроен. С NIO вы предоставляете свое собственное планирование в виде линейного сканирования готовых клавиш выбора, и вы также можете тратить время между выборами, если вы не очень осторожны.   -  person user207421    schedule 22.01.2014
comment
Низкая задержка и высокая пропускная способность в большинстве случаев являются противоречащими друг другу требованиями. Вы можете либо оптимизировать использование полосы пропускания (например, подключение к сокету), что, в свою очередь, ухудшит задержку (поскольку все ожидающие данные должны быть переданы до того, как пройдет определенный фрагмент данных) или задержку (в этом случае вы хотите ограничить объем данных). отправлено, чтобы убедиться, что оно проходит быстро). Выбрать свой яд.   -  person Durandal    schedule 11.02.2014

Ответы (2)


arrow_upward
2
arrow_downward

«Асинхронное поведение — отличный способ избежать конфликтов». - только при использовании одного потока. Если много потоков, конкуренция неизбежна. Вы должны использовать multithreading (с NIO или без него), чтобы получить высокую пропускную способность и/или низкую задержку.

NIO только помогает поддерживать небольшое количество потоков (около числа доступных процессоров) и, таким образом, экономит память (каждый поток потребляет много памяти) и допускает огромное количество одновременных подключений, но обычно имеет худшую производительность, чем блокирующий ввод-вывод.

person Alexei Kaigorodov    schedule 11.02.2014

arrow_upward
1
arrow_downward

Все зависит от... :)

  • Если у вас есть количество одновременных потоков ‹= количеству ядер ЦП, то низкую задержку вы можете получить, используя блокировку IO/NIO. Обычно пропускная способность несколько хуже при блокировке IO/NIO. См. например: http://vanillajava.blogspot.ru/2011/08/comparing-java-7-async-nio-with-nio.html

  • Если у вас большое количество потоков, модель «поток на соединение» становится менее предпочтительной, чем асинхронный NIO. В основном потому, что вы оплачиваете стоимость переключения контекста, которая может быть не такой уж и маленькой (время на вызов системного планировщика, больше промахов кеша и т. д.). См., например: http://www.cs.rochester.edu/u/cli/research/switch.pdf И больше потоков = больше общая стоимость :) Здесь нам нужен асинхронный NIO как для задержки, так и для пропускной способности.

person AnatolyG    schedule 04.03.2014