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

Question

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

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

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

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

Answer 1

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

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

Answer 2

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

• Если у вас есть несколько одновременных потоков < = число процессорных ядер, то малое время задержки вы получаете может использовать блокирующие 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 И больше threads = более общая цена :) Здесь нам нужен async NIO для латентности и пропускной способности.