5916
Сообщество разработчиков Java Scala Kotlin Groovy Clojure Чат для нач-их: @javastart Наш канал: @proJVM Вакансии: @jvmjobs @jvmjobschat ⚠️ Оффтоп -> @flood ❌Переход на личности ❌Троллинг ❌Реклама ❌HH (вакансии) ❌Варез
ну вообще огромные страницы иногда дают ОГРОМНЫЙ буст из за меньшего кол-ва tlb miss'ов
Читать полностью…
Вы не можете так же эффективно создавать и уничтожать тысячи платформенных потоков, как виртуальные
Читать полностью…
тогда я наверное не понял. А что именно еще можно было бы оптимизировать в стеках?
Читать полностью…
Посмотрел(пролистал), честно говоря для оптимизации размера стэка особо ничего не увидел
в основном касается оптимизации копирования фреймов virtual thread continuation <-> platform thread stack
по оптимизации размера увидел планируемую в будущем компрессию фреймов, все (
ну если говорить про внешнюю систему, то там вообще ещё надо помнить про poison pill
Читать полностью…
И тут уже зависит от того, насколько долго внешняя система будет отвечать
Читать полностью…
ну если получится доказать про память, то ок
но про параллельность /конкурентность все равно же в jdbc cp упрется
Я уверен, что решение на виртуальных потоках:
Позволит обработать каждое сообщение в батче параллельно
Будет стоить меньше по памяти, чем платформенный тред (на платформенных мы можем вылетать по OOM при ограниченных ресурсах)
Будет быстрее
Да норм идея, паттерн мульти трэдед консьюмер, где требуется обработка батча параллельно + тут поможет структурное конкарренси
Читать полностью…
> 1/ even 4KB granularity is quite a lot (the expected waste is at least 2KB per thread)
Про это я тоже писал! Когда там висит весь спринг, разницы особо нет.
А как можно оптимизировать стек под виртуальный тред онли?
Читать полностью…
вспомнил кейс smallrye messaging (подотносительно Quarkus)
тайм-аут по умолчанию 60 сек воспринимается как сообщение, которое нельзя обработать и общение с Kafka и данным консьюмером блокируется.
я скорее к тому, что там действительно уже все сильно зависит от внешней системы, к подтверждению твоих слов как конкретный кейс
И в реальных системах никто пулы на 1к потоков не делает, а значит там будет базовый пул потоков + очередь, и эта очередь будет забиваться
Читать полностью…
/channel/jvmchat/623423
Смотрим на res, дальше проецируем, что будет, когда в стеке окажется реальный код, а не два фрейма.
Топик с 1 млн сообщений, батчи по 1к сообщений, для каждого сообщения поход во внешний сервис для обогащения, батчи после успешной параллельной обработки записывается в базу через jdbc
Читать полностью…
главная идея использования virtual threads в kafka consumer это именно уход от проблемы context switching.
Про память ещё доказать надо :)
Там предположение, что код будет делать fan-out для параллельных тасок, и у них будет минимальный стек.
Читать полностью…