Java I / O против Java новый I / O (NIO) с Linux NPTL - PullRequest
21 голосов
/ 30 октября 2010

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

У меня сложилось смешанное впечатление об этом.Я читал о тестах, в которых обычный ввод-вывод с новой библиотекой NPTL в Linux превосходит NIO.

Каков реальный опыт настройки и использования новейшего NPTL для Linux с Java I/ вывод?Есть ли повышенная производительность?

А по большему объему вопрос:

Какое максимальное количество входов / выходов и блокирующих потоков (что мы настраиваем в пуле потоков Tomcat ) на стандартном компьютере серверного класса (Dell с четырехъядерным процессором), который мы ожидаем нормально работать (с библиотекой Linux NPTL?).Как это повлияет, если пул потоков станет действительно большим, скажем, более 1000 потоков?

Любые ссылки и указатели будут очень благодарны.

Ответы [ 3 ]

17 голосов
/ 30 октября 2010

Провокационные публикации в блоге, "Избегайте NIO, получите лучшую пропускную способность." Блог Пола Тима (2008) утверждает ~ 5000 потоков без каких-либо проблем; Я слышал, что люди утверждают больше:

  1. При включенном NPTL Sun и Blackwidow JVM 1.4.2 легко масштабируются до 5000+ потоки. Модель блокировки была последовательно на 25-35% быстрее, чем при использовании NIO селекторы. Много техник предложенный EmberIO люди были занятые - с использованием нескольких селекторов, делать несколько (2) читает, если первый читать возвращенный EAGAIN эквивалент в Джава. Тем не менее, мы не могли победить равнину поток на модель соединения с Linux NPTL.

Я думаю, что ключом здесь является измерение накладных расходов и производительности и переход к неблокирующему вводу / выводу только тогда, когда вы знаете, что вам нужно, и можете продемонстрировать улучшение. Дополнительные усилия по написанию и поддержке неблокирующего кода должны быть учтены в вашем решении. Мое мнение таково: , если ваше приложение может быть четко выражено с помощью синхронного / блокирующего ввода / вывода, выполните ТО . Если ваше приложение поддается неблокирующему вводу-выводу, и вы не будете просто заново изобретать блокирующий ввод-вывод в пространстве приложения, РАССМОТРИТЕ переходить на nio в зависимости от измеренных требований к производительности. Я удивляюсь, когда подсматриваю результаты поиска в Google по поводу того, как мало ресурсов на самом деле ссылаются на (недавние) числа !

Также см. Слайды презентации Пола Тима : Старый путь снова новый. Основываясь на его работе в Google, конкретные цифры говорят о том, что синхронный многопоточный ввод / вывод вполне масштабируем в Linux, и считают, что «NIO быстрее» - миф, который был верным некоторое время, но уже не так. Несколько хороших дополнительных комментариев здесь, на Comet Daily . Он цитирует следующий (анекдотический, все еще нет твердой ссылки на тесты и т. Д.) Результат по NPTL:

В тестах NPTL удалось запустить 100 000 нитей на IA-32 в два секунд. Для сравнения этот тест под ядро ​​без NPTL бы занято около 15 минут

Если вы действительно столкнулись с проблемами масштабируемости, вы можете настроить размер стека потоков , используя XX:ThreadStackSize. Поскольку вы упоминаете Tomcat, смотрите здесь .

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

См. Также , относящийся к SO .

4 голосов
/ 30 октября 2010

Полезные ссылки:

Вы также можете взглянуть на http://nodejs.org/, который не является технологией JVM, но прекрасно обрабатывает тысячи соединений (и,если я не ошибаюсь, использует NPTL за кулисами)

Некоторые хорошо зарекомендовавшие себя веб-платформы NIO под JVM:

1 голос
/ 23 ноября 2010

Саджид, я вижу, что вы делаете комету (длинный опрос).

Почти никто не говорит о проблеме исполнения пользовательского кода для событий Comet в NIO.Поток NIO, отправляющий события Comet, вызывает ваш код, если ваш код недостаточно хорош, вы блокируете этот критический поток, и другие соединения Comet ДОЛЖНЫ ЖДАТЬ, потому что поток NIO выполняет ту же работу, что и планировщик потока SO.Это не проблема в Comet с IO, потому что поток предназначен только для вашего события / задачи Comet, и планировщик может отказаться от вашего потока, когда захочет (не так просто с подходом NIO).

Единственная проблема, которую я вижу с «синхронной кометой» (основанной на IO), - это потребление памяти стеками потоков.

...