это не значит быть заблокированным

только драйвер если поддерживает

не, ясно, что блокировка таки будет, если драйвер не умеет полноценный асинх с тредпулом выходит "виртуальный асинх"

это не значит быть заблокированным

А что это значит

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

На ок отдельный поток, но в какой то момент мы все равно будем ждать данные

Не никто ждать не будет все будет паралельно если правильно спроектировать

насчёт тред пула - если он забьётся то что тогда?

Он забьется если намеренно тупить и забивать его

если много клиентов

Он забьется если намеренно тупить и забивать его

Че эт

насчёт тред пула - если он забьётся то что тогда?

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

не контролировать пул потоков? так ещё хуже ж будет

если много клиентов

Все будет паралельно, утлизация cpu будет 100%

Все будет паралельно, утлизация cpu будет 100%

Утилизация при блокировке?)

Небудет никаких блокировок

Не понял, ты ж говоришь отдельный пул для блокирующих операции, че эт их не будет)

ну будут потоки лочится ну и что в пуле новые создадутся

пока ресурсы есть

Если поток висит на блокировке, то откуда быть утилизации ?

Если поток висит на блокировке, то откуда быть утилизации ?

он вечно там висеть будет?

Это не теория, это практика, во время нагруз тест у меня сервер обслуживал 60к клиентов одновременно и утилизировал 100% cpu. 4 ядра. Это говорит о том что практически никаких блокировок нет. Поэтому я так и топлю за Акку.

Нет, но если нагрузка хорошая то пул то кончится ?

Это не теория, это практика, во время нагруз тест у меня сервер обслуживал 60к клиентов одновременно и утилизировал 100% cpu. 4 ядра. Это говорит о том что практически никаких блокировок нет. Поэтому я так и топлю за Акку.

Ну так ты заблокируй поток и посмотри что будет

Первый Сервер на потоках java concurency. Держал 8к клиентов максимум, и утилизировал 30% cpu

Ну так ты заблокируй поток и посмотри что будет

Зачем?)

Первый Сервер на потоках java concurency. Держал 8к клиентов максимум, и утилизировал 30% cpu

А бывают какие то другие потоки?

А бывают какие то другие потоки?

Pthreads ????

А бывают какие то другие потоки?

Разные подходы, стандартный concurency и акторный подход

А если бы на Go написали бы а не на akka ))

А бывают какие то другие потоки?

Пох что джава потоки на них мапятся

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

Ну так ты заблокируй поток и посмотри что будет

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

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

Эт далеко не правда. Просто твои пул очень быстро кончится и все встанет колом

Кстати, могу ещё предложить на Quasar посмотреть

Кстати, могу ещё предложить на Quasar посмотреть

Посмотреть и блевануть?

Это ещё почему?

Это ещё почему?

Прост

У них тоже весьма интересное решение для concurrency

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

Так об этом и речь, достич такой утилизации на concurency невероятно сложно и дорого

А так потрки и железо то одинаковое

А так потрки и железо то одинаковое

Ну ща ага

Так об этом и речь, достич такой утилизации на concurency невероятно сложно и дорого

А акторам на JVM есть альтернатива?

А так потрки и железо то одинаковое

В винде потоки другие. Да и процы разные

А акторам на JVM есть альтернатива?

Файберы

Всмысле может какие-то другие модели разработки тоже хорошо работают

Эт далеко не правда. Просто твои пул очень быстро кончится и все встанет колом

Он не кончится, потому что мы этим операциям назначили отдельный поток (ядро) эти задачи не будут лезть на другие ядра

В винде потоки другие. Да и процы разные

Какая нах винда?)

А акторам на JVM есть альтернатива?

котлин корутины, конечно же!

котлин корутины, конечно же!

Хорошая попытка, но Котлин корутины это что угодно может быть

А акторам на JVM есть альтернатива?

Я сейчас vertx пытаюсь понять

Он не кончится, потому что мы этим операциям назначили отдельный поток (ядро) эти задачи не будут лезть на другие ядра

пул у тебя бесконечный?)

Он не кончится, потому что мы этим операциям назначили отдельный поток (ядро) эти задачи не будут лезть на другие ядра

ядра с потоками в джаве не мапятся, метод setAffinity из pthreads не реализован

Господа, а в явовском хешмапере хеш каждого элемента меньше buffersize хешмапы?

wat

пул у тебя бесконечный?)

Естественно!

пул у тебя бесконечный?)

Судя по всему не получится у тебя объяснить что если во всей цепочке есть блокирующие операции, то теряется смысл асинхронности

Тоесть хеш равен (hashCode() mod buffersize)?

Естественно!

ну удачи чо

Естественно!

если пул бесконечный, то у тебя система будет тратить время cpu только на диспетчирезацию самой себя)

Тоесть хеш равен (hashCode() mod buffersize)?

wat

Ну блин. Знаешь как хешмап работает?

Судя по всему не получится у тебя объяснить что если во всей цепочке есть блокирующие операции, то теряется смысл асинхронности

конечно не получится)

Ну блин. Знаешь как хешмап работает?

конечно

Судя по всему не получится у тебя объяснить что если во всей цепочке есть блокирующие операции, то теряется смысл асинхронности

Верно, но даже если и есть то их в конфиге можно замапить на отдельный пул и они не залочат всю систему

Верно, но даже если и есть то их в конфиге можно замапить на отдельный пул и они не залочат всю систему

залочат!

Хеш там как вычисляется?

Верно, но даже если и есть то их в конфиге можно замапить на отдельный пул и они не залочат всю систему

1. пулы не бесконечные

ERROR: S client not available

Верно, но даже если и есть то их в конфиге можно замапить на отдельный пул и они не залочат всю систему

2. даже если бы были бесконечные - залочили бы)

Окей, в лучшем случае какое время поиска по хешмапе?

залочат!

Почему?) Ты серьезно или это тролинг?

Хеш там как вычисляется?

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

Да

Да

так и говори)

Окей, в лучшем случае какое время поиска по хешмапе?

O(1)?

O(1)?

не время, а трудоемкость

Не суть

да, в лучше случае трудоемкость O(1)

Ясно

Спасибо

2. даже если бы были бесконечные - залочили бы)

У меня на небесконечных даже не лочат, а обращения к базе есть! Шах и мат)

У меня на небесконечных даже не лочат, а обращения к базе есть! Шах и мат)

у тебя нагрузка недостаточная

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

и приехали

Надо fixed пул делать

Это азы блин)

Спасибо

жаль ты про логарифм не спросил

Так нет там логарифма

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

Я так понимаю что кроме concurency многопоточности ты больше ничего не юзал?

Поиск не бинарный

А просто "дай мне k-ый элемент"

Так нет там логарифма

есть там логаримф, в случае при определенном трешолде и случаее)

Я так понимаю что кроме concurency многопоточности ты больше ничего не юзал?

wat

Окей, а когда там нет логарифма?

у тебя нагрузка недостаточная

Достаточная - Утилизация cpu 100%

И будет O(1)?

А просто "дай мне k-ый элемент"

в бакете поиск либо линейный, либо логарифм

А ну в бакете

Сам бакет то без логарифма?

Достаточная - Утилизация cpu 100%

facepalm