pro.jvm

17 Dec 2024 09:40

192 ядра это без нума

pro.jvm

17 Dec 2024 09:40

возвращаясь к тысяче, я тебе скажу так, в 1к платформенных это будет тупо дорого делать, обычно делают микропул + очередь с запасом, и конечно такое решение будет медленней, ведь IO в платформенном блокируется, а в луме нет, значит очередь будет копится

pro.jvm

17 Dec 2024 09:40

Так корутины это не потоки. Потоки это не cooperative multitasking.

pro.jvm

17 Dec 2024 09:38

receive side scaling
нума ещё
нет-нет, не говори, что тебе не надо в общую память ходить

pro.jvm

17 Dec 2024 09:38

где именно? жава сама вирт треды по ядрам разрулит

pro.jvm

17 Dec 2024 09:37

И у тебя нет тысячи ядер, чтобы это было параллельно

pro.jvm

17 Dec 2024 09:37

так давно же есть оценка что реактивный подход даёт 15-30% к пропускной способности IO-intensive системы. Ну тоесть часто проще чуть больше железа докинуть зато всё будет проще и пограммистов подешевле можно будет взять, да и дебаг без реактивщины сильно упростится и ускорится.

pro.jvm

17 Dec 2024 09:36

576k циклов на запрос при 3ггц. Ты уверен, что ты уложишься? Как ты будешь делать RSS в джаве?

pro.jvm

17 Dec 2024 09:36

погоди, ты не понял задачу с кафкой

pro.jvm

17 Dec 2024 09:33

запросы по ним будут гонятсья

pro.jvm

17 Dec 2024 09:32

Так а зачем тебе создавать то, что тебе не нужно вообще в принципе?

pro.jvm

17 Dec 2024 09:32

Я тоже, только сколько там запросов пройдет, и сколько ты будешь nic ждать?

pro.jvm

17 Dec 2024 09:31

я могу себе позволить открыть лям коннектов к бд

pro.jvm

17 Dec 2024 09:31

НЕЕЕЕЕТ

ТЫ НЕ ДОЛЖЕН ЮЗАТЬ ВИРТУАЛЬНЫЕ ПОТОКИ

ВЫИГРЫША ПО ПАМЯТИ НЕТ

ЗАЧЕМ ТЕБЕ СОЗДАВАТЬ ИХ НА КАЖДЫЙ ЧИХ

ДАВАЙТЕ ПУЛИТЬ ВИРТУАЛЬНЫЕ ПОТОКИ

А ПЛАТФОРМЕННЫЕ ПОЧЕМУ ХАРАМ

pro.jvm

17 Dec 2024 09:29

тут один ноунейм ответил

pro.jvm

17 Dec 2024 09:40

я про это все в начале писал

pro.jvm

17 Dec 2024 09:40

192 ядра это без нума

rss ГДЕ? где будут запускаться вирт треды? меня это не волнует, у жвм шедулер это разрулит, как и у голанга
входящих коннектов? да какой нибудь SO_REUSEPORT хоть

pro.jvm

17 Dec 2024 09:39

и он предлагает юзать семафор, что логично + непонятно, как вообще реализовать пулинг виртуальных потоков, что там по пинингу платформенных тредов в таком случае

мы же не пулим корутины или горутины

pro.jvm

17 Dec 2024 09:38

Так я и не имею ничего против разумного числа. Просто аргумент про три миллиона невалидный, нет таких реальных задач.

pro.jvm

17 Dec 2024 09:37

3 ляма я приводил в пример для сервака

pro.jvm

17 Dec 2024 09:37

Так это тысяча, не три миллиона

pro.jvm

17 Dec 2024 09:37

то есть из 1 млн сообщений, берем последовательно первый батч на тысячу и каждое сообщение из этой тысячи параллельно обрабатываем, результат обработки пишем в базку и коммитим оффсеты в кафку

pro.jvm

17 Dec 2024 09:36

чтение с кафки последовательное бай дизайн, я сказал про обработку батча параллельно

pro.jvm

17 Dec 2024 09:33

Я тоже, только сколько там запросов пройдет, и сколько ты будешь nic ждать?

pro.jvm

17 Dec 2024 09:33

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

pro.jvm

17 Dec 2024 09:32

без вирт тредов я как это сделаю?

pro.jvm

17 Dec 2024 09:32

и вирт треды которые в IO в бд висят просто будут спать

pro.jvm

17 Dec 2024 09:31

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

pro.jvm

17 Dec 2024 09:30

ага

It is possible, however, that code running in a virtual thread may require the use of a finite resource, such as a database connection.

pro.jvm

17 Dec 2024 09:29

Очередной спор на 400 сообщений