потому что надо уметь её готовить.

если база из коробки не может жить без падений, она не сдалась

Это выполнение драйверов в user-space и прямая работа с сетевой от 40 до 150Gbit на ноду.

Но это же все равно не джава

Какой хайлоад без джавы?

Отличный

5-6M RPS на 1 ноду

800 тактов проца на 1 http запрос :p

Надо на тебя кривду натравить

желательно в отдельном канале

Потереть за хайлоад

Тут просто с джавой 300K RPS - потолок... Для 1M уже надо Disruptor, GC выключать в JVM, Azul'ы пробовать...

В DPDK с коробки от 1М RPS для простых сервисов ...

Потому что происходит напрямую работа с железом.

В общем пока не придумали нормальный interop с сишкой в Java9 ... можно особо не надеятся на Java и хайлоады.

А называть 300К RPS хайлоадом как-то сложно... уже даже golang так умеет ...

Тут просто с джавой 300K RPS - потолок... Для 1M уже надо Disruptor, GC выключать в JVM, Azul'ы пробовать...

Омг, а зачем гц выключать?

Омг, а зачем гц выключать?

Задержки на сборку мусора большие, с Disruptor'ом можно сделать 0lock. Т.е. вся память приложения будет статической - один раз выделили и делаем realloc IO буферов и кольцевых буферов при backpressure. Потом вырубаем GC после прогрева машины.

Я как бы пользуюсь в проде дисраптором, но всё-равно не понимаю зачем отключать гц

lmax отключает у себя...

Azul Falcon может пропускать сборку мусора по тем же причинам.

В целом даже "пустой проход" gc по молодой выборке имеет довольно высокие накладные расходы, особенно если речь идёт о работе с большими страницами.

Я как бы пользуюсь в проде дисраптором, но всё-равно не понимаю зачем отключать гц

Им проще машинки перезагружать в конце business day

Им проще машинки перезагружать в конце business day

Стоит сначала ознакомиться с сабжем ...

Стоит сначала ознакомиться с сабжем ...

Я знаком с сабжем

Не заметно

IMAX делали свою сборку java без gc

Ага...

Много памяти на машинках, никакой распределенки, а в конце для тупо перегружали

... это было давно, сейчас нормально работает и без gc

Не заметно

Хорошо что вы здесь обязательно поправите

Просто на практике видел довольно много случаев HFT и RTB где в итоге вырубали GC.

Сейчас lmax вообще всё сделал на ПЛИСках и DPDK ... и это уже отдельная история.

В целом это как шутка про состояние продакшена без flame graph'ов. Мне будет сложно что либо объяснить без реальных примеров... ими не делюсь по понятным причинам.

lmax отключает у себя...

А логика такая: если LMAX у себя так делает, значит и всем нужно? Просто мы тоже биржевые данные перевариваем и на данный момент гц отнимает 5% цпу. Как бы не тот оверхед из-за которого стоит убиваться

А логика такая: если LMAX у себя так делает, значит и всем нужно? Просто мы тоже биржевые данные перевариваем и на данный момент гц отнимает 5% цпу. Как бы не тот оверхед из-за которого стоит убиваться

Речь идёт о highload - кому то 300К rps хватает, а у кого-то всё начинается с 1М

Просто сейчас бытует очень много предрассудков касательно сабжа и общих накладных расходов

В итоге масштабируют простой процессора в разных вариациях ...

И да, был доклад от Черёмина где он показал что вся прелесть дизраптора не в зеро гц

Кто-то упомянул Epsilon GC?

И да, был доклад от Черёмина где он показал что вся прелесть дизраптора не в зеро гц

Простая реализация wait-free подхода для низких задержек - это была основная цель...

Кто-то упомянул Epsilon GC?

* пока его не ковырял, должно быть интересно

По-моему, это пока что только драфт

Шипелёв вроде его крутил ...

Простая реализация wait-free подхода для низких задержек - это была основная цель...

Ну дык а причём тут тогда гц?

Ну дык а причём тут тогда гц?

Он тоже влияет на доступность сервиса и общие задержки ...

Просто вообще говоря, работа с памятью через гц может быть эффективнее потому что балк операции

Чем через ручное удаление ссылок после каждого использования

Он тоже влияет на доступность сервиса и общие задержки ...

Ну это на 1М рпс никак не влияет

Ну это на 1М рпс никак не влияет

Почему ?

У LMAX проблема была в другом, они же биржевой софт делали для, собственно, биржи. Там немного другие требования, там нельзя чтобы одному ответ отдавался 1мс, а другому 20.

Почему ?

Потому что если он отнимает меньше 5% времени приложения, то 950к ~= 1М

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

Ок, не думаю что мне стоит объяснять в чём разница между lock-free и wait-free подходами. Но в целом мы можем получить либо низкие задеркжи, либо высокую пропускную способность. Операции с памятью и проходы по генерациям ссылок тоже имеют свою стоимость - в итоге это тоже соответственно повлияет либо на пропускную способность либо на задержки.

Ок, не думаю что мне стоит объяснять в чём разница между lock-free и wait-free подходами. Но в целом мы можем получить либо низкие задеркжи, либо высокую пропускную способность. Операции с памятью и проходы по генерациям ссылок тоже имеют свою стоимость - в итоге это тоже соответственно повлияет либо на пропускную способность либо на задержки.

Омм.. как это соотносится с хайлоадом и 1М рпс?

Омм.. как это соотносится с хайлоадом и 1М рпс?

Я не думаю что мне стоит продолжать это обсуждение.

Им проще машинки перезагружать в конце business day

Ну и кстати замечание Виктора тоже было вполне оправдано, ибо действительно у всех бирж есть расписание и действительно в лмакс решили что можно ребутать прилагу в конце дня

Ок...

Если принято игнорировать потому что удовлетворяет бизнес требования - это не значит что это все игнорируют.

Я не думаю что мне стоит продолжать это обсуждение.

Не, мы с чего начали-то? Что мол в рили хайлоаде гц не нужон, потому что накладные расходы и все дела, но на данный момент не вижу ни одной причины этого делать. И Вы как-то меня пока в этом тоое не убедили

Я и не собирался.

В реальном мире Java разработчик никогда не перепрыгнет за 1M RPS.

В реальном мире Java разработчик никогда не перепрыгнет за 1M RPS.

мне не нравится твой стиль ведения беседы

и твои цели, что ты пришел сюда, тоже

В реальном мире Java разработчик никогда не перепрыгнет за 1M RPS.

Да вот ложь и провокация )

В реальном мире Java разработчик никогда не перепрыгнет за 1M RPS.

Например есть тот же айрон

ERROR: S client not available

Где 16М рпс )

Что это ?

https://github.com/real-logic/aeron

Как-то да, получается известный спич из серии "пишите на плюсах потому что java тормозит"

Что вообще говоря не так )

Как-то да, получается известный спич из серии "пишите на плюсах потому что java тормозит"

обычно такое слышишь уст из тех, кто не разобрался)

а у чувачка в подписках канал pro.go

хэх

а у чувачка в подписках канал pro.go

Видимо там есть крутой интеропт с C++ )

https://github.com/real-logic/aeron

Там MediaDriver отдельно обрабатывает входящий трафик и для таких RPS'ов они явно пишут что нужна Сишка с OpenOnload / DPDK или ПЛИСки.

Как-то да, получается известный спич из серии "пишите на плюсах потому что java тормозит"

Я не говорю что Java тормозит... у неё пока нет хорошего interop'a с сишкой.

В реальном мире Java разработчик никогда не перепрыгнет за 1M RPS.

Ну как, а это?

Ну как, а это?

Потому что нет возможности вызывать существующие сишные API без высоких накладных расходов.

Потому что нет возможности вызывать существующие сишные API без высоких накладных расходов.

Вроде пилят быструю замену для jni

И вот я тебе привёл пример где большая часть написана на java и выжимают больше 10M рпс

Вроде пилят быструю замену для jni

http://openjdk.java.net/jeps/191 Так точно.

И вот я тебе привёл пример где большая часть написана на java и выжимают больше 10M рпс

При это Java не обрабатывает трафик в Aeron'e при таких RPS'ах ...

При это Java не обрабатывает трафик в Aeron'e при таких RPS'ах ...

Там были разные бенчмарки и в том числе с java и с .Net

Кстати, прискорбная новость для всех в этом чатике, шарпы выиграли...

Там были разные бенчмарки и в том числе с java и с .Net

Странно что нет упоминания про openonload ...

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

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

Кстати правда интересно, без наезда было сказано

"бизнес-логика" это CRUD'ы AAA и валидация ?

В целом у меня лично большая часть этого барахла висит в PostgreSQL на мат. представлениях, правилах на правку/вставку и сишных триггерах, есть кастомный коннетор на shmem'e... JDBC не использую из-за костыльности - с базы сразу уходит JSON и кэшируется соответствующим образом. В качестве кэша сейчас использую свою реализацию Adaptive Replacement Cache.

"бизнес-логика" это CRUD'ы AAA и валидация ?

Бизнес-логика - это чтр конкретно приложение делает, кроме того что выдаёт 1м рпс )

Это приложение выдаёт пока 400К RPS из-за проблем с PostgreSQL'eм - сейчас патчим 10ый на поддержку blobfs для WAL журнала... банально проседают IOPS'ы.

1M у меня было на RTB бирже.

Нетфликс тоже вот сейчас собирается потиху слезать на SPDK для WAL журналов и прочего.

Изучал сегодня особенности применения x86 intrinsic'ов в JIT'e ... В целом включение -XX:-OptimizeFill -XX:-UseSuperWord даёт хороший прирост, но к сожалению много существующих SIMD инструкций просто не используются. В Java9 сейчас ситуация гораздо лучше в этом плане.

У меня есть приложение на Spring, в нем генерируется файл и отдается методом в контроллере. Я пока сделал так что этот метод отдает byte[], но это не то что нужно. Когда я открываю эту страницу в браузере то мне выводит просто набор символов (тот самый массив байтов), а надо чтобы начиналось скачивание этого файла. Как мне переделать метод?