Перевожу ряд сервисов с обычного IO на NIO, вроде жалуются, что потребление CPU на некоторых паттернах использования возрастает раза в 2 (((

Почитал статьи, в ряде тестов в Inet'е (одно соединение, один клиент), NIO дает только 70-80 % throught input по сравнению с обычными соккетами.

Такая проблема реально существует, если да, кто как ее решает?

Смысл поднимать котяру, когда используется Simple Framework http://www.simpleframework.org/ и Apache HTTP Components https://hc.apache.org

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

Если говорить о ресурсах, то расход процессора в блокирующем режиме даже на 1000 потоков составляет единицы процентов, в то время как в режиме NIO расход процессора составляет 20-30%.....

Интересно откуда это утверждение взялось.
1) Куда тратится время
2) Как это померить


У меня на "синтетическом тесте" по профайлеру, все "стоит колом" на ConcurrentLinkedQueue который используется в приложении для пересылки данных от рабочих потоков в соответствующий HttpAsyncResponseProducer + на копирование туда-сюда-обратно в процессе этой передачи ((( Например Apache HTTP Componets NIO Core в классе IndentityEncoder имеет свой буфер, без предоставления методов им управления, т.ч. и тут можно наткнуться на двойную (тройную, четверную и так далее) буферизацию.

Везде пишут красивые слова про ByteBuffer и про желательность отсутствия двойной буферизации, но в реальной жизни, Java-стиль программирования и API очень располагает копировать туда-сюда ((( и часто вообще не понятно, как сделать без копирования и/или без лишних new'ов ((( Простейший пример - преобразование (вывод) String в ByteBuffer, вроде задача стандартная, но каких либо высокопроизводительных/удобный методов ее сделать без создания лишних объектов и без копирования - совсем не тривиально ((( IMHO & AFAIK


Коллеги уверяют, что на проде, все "стоит колом" на IOControl.suspendOutput, IOControl.requestOutput - где там стоять, мне не понятно и локально в профайлере я вообще данные вызовов почти не вижу, они мгновенно выполняются (((

Basil A. SidorovНаиболее вероятный вариант - разная нагрузка на разном железе. Скорее всего, что у прода на порядок больше ядер и памяти.
нагрузка не просто разная. Ее вообще нет ((( Реальные данные идут от коммерческих поставщиков, обрабатываются, отдаются далее. Машинки тоже разные.

Есть "заглушки" для unit-тестов, функционального тестирования. Есть мною написанная некая "синтетика" которая дает примерно похожий характер нагрузки (на максимуму).

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

Т..ч. сечас система живет в "подвешенном" виде, часть сервисов переведено на NIO, а часть осталась в старой версии. Что, понятно, есть плохо (((

Куда девается процессор - для меня загадка. Что вижу в профайлере, куча времени уходит на синхронизации и Atomic'и + куча времени на копирование туда-обратно.

Basil A. SidorovLeonid Kudryavtsevчасто вообще не понятно, как сделать без копирования и/или без лишних new'ов ((( Простейший пример - преобразование (вывод) String в ByteBuffer, вроде задача стандартная, но каких либо высокопроизводительных/удобный методов ее сделать без создания лишних объектов и без копирования - совсем не тривиальноНасколько я помню документацию, если делать ByteBuffer над byte[], то поверх тогоже самого byte[] можно делать и другие представления, включая и CharBuffer и StringBuffer

Идею про StringBuffer не понял(((

Но дальше ООП и Java.....

Есть класс CharsetEncoder который, теоретически, выполняет преобразование из char в byte, он же используется и в OutputStreamWritter и String.toBytes

НО:
1. В вызовах reset, encode, flush - IMHO без полбутылки не разберешься. Вроде в OutputStreamWritter они вообще не парятся и flush никогда не вызывают ))).
2. Ему на входе нужен CharBuffer (можно использовать реализацию StringCharBuffer). Объясните мне, на#$% !!! б#$% !!! API обязательно требуют new для оборачивания String в StringCharBuffer. Я понимаю, что new в Java считается "обычной" операцией, но б#$%!!! у меня короткие строки и сотни тысяч вызовов в секунду!!! На@#$ все классы в Java стали делать immutable?
3. Моя реализация через String -> CharBuffer.wrap(CharSequence) / StringCharBuffer/ -> encode в предварительно выделенный ByteBuffer - работает примерно так же и даже медленнее, чем банальное String.toBytes(), ByteBuffer.wrap ((( Хотя, вроде, String.toBytes работает через тот же CharsetEncoder (((

В общем, одно Шаманство, а счастья нет.

Теоретически, если наплевать на кодировки ))) можно просто отсекать старший байт и складывать в ByteBuffer. Но это как-то совсем топорно.

Leonid KudryavtsevТеоретически, если наплевать на кодировки ))) можно просто отсекать старший байт и складывать в ByteBuffer. Но это как-то совсем топорно

Ну и не нужно. Т.к., например UTF-8 Encoder для <128 символов ровно так и поступает в самых первых строках encodeArrayLoop /private/

Почему же он ссука... умудряется работать заметно медленнее /Oracle JVM 1.8.0_101/, чем String.toBytes, который, якобы ровно через него и работает (судя по декомпилированному коду) (((

Уроды. Нагородили ООП, а пишут умные статьи про то, что нужно избегать двойной буфферизации. И как ее избегать?

http://psy-lob-saw.blogspot.ru/2012/12/encode-utf-8-string-to-bytebuffer-faster.html

Красивые циферки, показывающие всю степень п...ца и шаманства. В общем, требуется бубен и море алкоголя. Вещи типа "One oddity I stumbled on while researching the topic was the fact that using String.getBytes(Charset) is actually slower then using the Charset name." просто фирменный ахтунг ООП !!!

Эффект объясняется очень просто ))) При toBytes( "имя кодировки" ) encoder кэшируется в ThreadLocal и при вызовах с одним параметром - производительность хорошая. При toBytes( Charset ) - encoder каждый раз создается новый. У меня получается, что загрузка CPU при отдачи данных до 2-3 раз меньше. /пакеты по 64 байта/

Пытаюсь прикрутить CharsetEncoder.... безуспешно. На просто тесте (вызов в цикле), скорость чуть хуже, чем у String.toBytes() /10%/. Вставляю в реальный Producer - скорость отдачи данных хуже на 3 (ТРИ!) порядка (ТЫСЯЧА раз). В чем дело, пока понять не могу.

Basil A. SidorovНадо реальную систему профилировать: четыре ядра и HT совсем не тоже самое, что четыре сокета, по восемь ядер в каждом и дохрена кэшей третьего уровня. Два (четыре) гигабитных интерфейса это тоже совсем другая предложенная нагрузка.

До этого пока не дошел. Он же "реальная система", на него сотня тысяч юзеров завязано. Боязно как-то.

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

По крайне мере, даже если ничего не улучшится, то появилось представление, что понаписано в системе и что понаписано в Apache HTTP Components. Профайлить без малейшего представления о системе - тоже задача веселая )))

Basil A. SidorovАсинхронный ввод-вывод хорош, если у вас много долгоживущих и сравнительно малоактивных подключений.
Протокол, который вы на NIO переписали - HTTP или что-то самопальное?
Много долгоживущих соединений. Самопальное HTTP, но в данном случае, соединение устанавливается, не разрывается и данные отдаются по мере появления.

Когда они __совсем__ малоактивны - все хорошо. Но если сервис более менее активен (сотни килобайт в сек. трафик) визуально CPU жрется в два раза больше, чем было до этого.

Как я понимаю, раньше не нравился показатель "кол-во потоков ожидающих исполнения", сейчас с ним все хорошо ))), но зато потребление CPU полезло вверх.

Раньше было http://www.simpleframework.org/
Сейчас https://hc.apache.org/

Basil A. SidorovP.S. А что копирование? Сделали xxxBuffer поверх byte[] и отдаём нужный кусок в нужном виде без всякого копирования.

У меня на входе String.

Удивляет, что нет нормального способа закодировать String в ByteBuffer без промежуточного алоцирования. Т.к. самый быстрый способ String.getBytes() , как понятно, создаст промежуточный byte[]

Все остальные пляски с бубном, как-то сильно шамански и медленнее.

Такие данные простым read/write обрабатываются без всяких бубнов - контейнер сам применит нужную магию. А разные варианты заклинаний делаются простым изменением типа коннекторов сервлет-контейнера.

Там НЕ получил запрос, отдал данные.

А получил запрос, отдаем-отдаем-отдаем помаленьку, маленькими порциями (как появились у поставщика) в тот же самый socket/channel/htttp-соединение

Basil A. SidorovP.S. В общем, я остаюсь при своём мнении - не то оптимизируется и не там.

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

Basil A. SidorovНе надо изобретать велосипед, появившийся в 3.1 спецификации сервлетов: асинхронный отклик и контейнер сам будет "отбирать" поток исполнения, если "прям щас" нет данных для ServletOutput.
И, опять-таки, сделает это, как минимум, не хуже вас.
Частично солидарен.

Изначально удивился, зачем свой велосипед для HTTP написали.

А какой легковесный и быстрый контейнер можете посоветовать? Желательно, что бы интегрировался в приложение.

Basil A. SidorovНе надо изобретать велосипед, появившийся в 3.1 спецификации сервлетов: асинхронный отклик и контейнер сам будет "отбирать" поток исполнения, если "прям щас" нет данных для ServletOutput.

Почитал первое попавшиеся

https://ynovikov.wordpress.com/tag/асинхронный-сервлет/

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

Это вообще писец. Если уж сейчас процессор сжирается, что будет, когда после каждой посылки нужно будет "установить соединение заново"