Java I/O vs. Java new I/O (NIO) с Linux NPTL

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

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

И по более крупному вопросу:

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

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

Ответ 1

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

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

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

Кроме того, см. слайды презентации Paul Tyma: Старый путь снова новый. Основываясь на его работе в Google, конкретные цифры говорят о том, что синхронный потоковый ввод-вывод довольно масштабируемо в Linux и считают, что "NIO быстрее" - это миф, который был прав на некоторое время, но больше не существует. Некоторый хороший дополнительный комментарий здесь, на Comet Daily. Он цитирует следующее (анекдотическое, до сих пор нет четкой ссылки на тесты и т.д.) На NPTL:

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

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

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

См. также связанный с SO.

Ответ 2

Ссылки, которые могут оказаться полезными:

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

Некоторые хорошие проверенные веб-фреймы NIO под JVM:

Ответ 3

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

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

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

Ответ 4

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