Не будет у меня возникать тк джавовские имплементации обычно делают два евент лупа на ядро. А в ноде запускают несколько процессов.
Проблема у вас в случае event loop будет возникать в том что в случае утилизации множества ядер потребуется как-то балансировать нагрузку.
А вы платите за эту нормальную машину из своего кармана? Представляете бывают проекты где инстансов микро-сервисов пару тысяч и вот таким горе программистам на каждый инстанс надо подавать по 16 ядер и 64Гб оперативки иначе в их понимании джава не взлетает.
На нормальной машине где более одного потока исполнения, про что я сразу сказал. А не на куцем полпроцессора. Где обычно java и используется.
А в Кафку как будем ходить? Или данные читать с какого нить AWS S3? Джава или Нода тем и хороши что много разработчиков и много различных библиотек доступны.
А если же будет 512 юнита цпу и 512Мб памяти то лучше взять вообще openresty с lapis фреймворк на lua. Жрать всего будет меньше
О неужели снизошло озарение, что программы разные бывают и по разному их надо реализовывать.
Дополнительно все сильно зависит от используемой загрузки.
Если тянуть по миллиону и одновременно куча клиентов то первее умрет Постгрес. и никакие потоки и ивент лупы тут вообще не спасут.
К примеру если вы начнете тянуть под миллион записей, у вас async non-blocking тоже может сливать, потому что банально оно однопоточный.
А кроме вас никто и не утверждал что есть серебряная пуля.
Помините фразу вашу — Давайте начнем с того что в java нет особых проблем с тредами. И на этом можно и закончить.
non-blocking не панацея, как и многопоточная модель.
Те вы будет ок про наш спор если мы оставляем 512Мб памяти и читерим до 2048 ЦПУ юнитов?
Но в случае non-blocking они же будут жрать память.
Каша какая то — что такое гибридная модель? Это когда на каждое ядро запускаем event loop? а не на одном все делаем? Так это все равно как был async non-blocking так и остался. И чтобы закончить эту демагогию — готовы ли вы доказать преимущества тысячи потоков перед парочкой.
Я беру springboot reactive, lettuce, vertx-pg-client. Вы springboot, Jedis и PG JDBC — и смотрим на 512 юнитах цпу, 512Мб памяти контейнера(не хипа). Выигрывает кто больше обработает запросов за 5 минут на 1000 конкурентных юзерах.
512 CPU units это пол ядра :)
И без обид но вы вообще не в курсе что такое async non-blocking. Почитайте про epoll, что такое Netty и тд. Мне не надо стопяцот потоков чтобы читать/писать с сокетов. Я обойдусь всего парочкой — тк в IO bound задач нет проблем с ЦПУ тк основное время это записать-подождать-прочитать какую либо ИО задачу. Все ваши потоки будут просто стоять и ждать и кушать память. При 1000 конкуретных юзерах и thread-per-request у вас по дефолту отожрется 1Гб памяти только для хттп потоков.
нет — Кваркус это просто прослойка под вертексом. С ним из коробки не особо удобно работать на всех его колбеках. А кваркус это все причесывает и делает аля спринг бут :)
Мне нравится ваш подход — возьмем кривое nodejs приложение и будем сравнивать с хорошо написанным джавовским :))) Речь то не об утекании памяти в кривых приложениях, а о том что вы не понимаете зачем нужен async non-blocking подход. Вы считаете что thread-per-request это лучшая практика и что создание тысячи тредов это нормальная ситуация. Готов с вами поспорить на ящик octomore 6.3 что вы пишете свое стандартное потоковое приложение с хождением в редис и постгрес, а я свое и потом мы запускаем все в докере с жесткими ограничениями типа 512 на CPU и 512Mb памяти на контейнер. И долбим к примеру 1000 конкурентных юзеров на это все — а дальше смотрим latency и error rate.
Давайте начнем с того, что однопоточный NodeJS может лопатить тысячи запросов в секунду не отжирая гигабайты памяти. а в джава подход — зачем нам думать о памяти и производительности, нафигачим тысячи потоков и разрастемся на десятки ЕС2 инстансов.
Vertx клиент никто не архивировал и он активно развивается: github.com/eclipse-vertx/vertx-sql-client
R2DBC для продакшена еще не готов, то там то здесь вылазят баги — лично сталкивался и постил им тикеты. Да и проскальзывало, что разработчики сосредоточены на доведением его до ума, а не попытках выжать максимум производительности.
Так же Вертх очень быстр: www.techempower.com/benchmarks/#section=data-r15&hw=ph&test=db
Единственное пришлось сделать свою прослойку чтобы удобно работать с ним через Flux/Mono.
и в чем проблема писать БД лог или же складывать все в таблицу куда только инсерты разрешены.
без обслуживания инфраструктуры
А как быть с транзакционностью — на каком этапе запись в блокчейн?
У меня может быть сложная транзакция в которой создается кучу всего и сейчас я беру и откатываю в случае ошибки. а тут появляется второй датасорс и надо обеспечить согласованность данных. Что делать если блокчейн пишется после фиксации транзакции и запись падает или наоборот записываем в блокчейн в середине транзакции и потом транзакция откатывается?
и нивелировать мошенничество с фин отчетами
Как кто то может добраться до БД и что то менять, то так же можно и своих фейковых узлов сделать чтобы в результате цепочка была фейковая :)
а где будет информация храниться? Если только на конкретном одном предприятии то зачем тут блокчейн? Если же это глобальная сеть то значит все мои операции будут видны всему миру — зачем мне такое счастье?
Можно и витамином Ц объесться и помереть. Но это ведь не значит, что он вредный.
Реактивщина отлично заходит на IO bounded задачах. И чего мелочиться с примерами — можно завернуть все в к8с с истио и считать все в хадупе. Чтобы показать какой великолепный и понятный подход плодить на каждый веб запрос по реквесту :)
Из проблем с чем я столкнулся: github.com/r2dbc/r2dbc-postgresql/issues/207 и не обленился сделать ишью.
Так же периодически зависали конекты и приходилось убивать джава процесс.
Если сделать матрешку из конекшена, пула и прокси то у меня на мультитредовых тестах вылетала 34000 постгрес ошибка, хотя никакими курсорами я не пользовался. Стоило убрать либо прокси либо пул и все становилось хорошо.
Периодически получал ошибку, что конекшен неожиданны был закрыт.
До текущего релиза шел в комплекте r2dbc-client, а сейчас то-ли на него забили то-ли еще что, но в bom его уже нет. Что также неприятно.
странно, но у меня все работает :)
у меня стандартный джововский набор программ и никаких проблем не было. Кроме Transmission Remote GUI, который за пару дней обновили и уже все работает.
Не будет у меня возникать тк джавовские имплементации обычно делают два евент лупа на ядро. А в ноде запускают несколько процессов.
А вы платите за эту нормальную машину из своего кармана? Представляете бывают проекты где инстансов микро-сервисов пару тысяч и вот таким горе программистам на каждый инстанс надо подавать по 16 ядер и 64Гб оперативки иначе в их понимании джава не взлетает.
А в Кафку как будем ходить? Или данные читать с какого нить AWS S3? Джава или Нода тем и хороши что много разработчиков и много различных библиотек доступны.
О неужели снизошло озарение, что программы разные бывают и по разному их надо реализовывать.
Если тянуть по миллиону и одновременно куча клиентов то первее умрет Постгрес. и никакие потоки и ивент лупы тут вообще не спасут.
А кроме вас никто и не утверждал что есть серебряная пуля.
Помините фразу вашу — Давайте начнем с того что в java нет особых проблем с тредами. И на этом можно и закончить.
Те вы будет ок про наш спор если мы оставляем 512Мб памяти и читерим до 2048 ЦПУ юнитов?
Каша какая то — что такое гибридная модель? Это когда на каждое ядро запускаем event loop? а не на одном все делаем? Так это все равно как был async non-blocking так и остался. И чтобы закончить эту демагогию — готовы ли вы доказать преимущества тысячи потоков перед парочкой.
Я беру springboot reactive, lettuce, vertx-pg-client. Вы springboot, Jedis и PG JDBC — и смотрим на 512 юнитах цпу, 512Мб памяти контейнера(не хипа). Выигрывает кто больше обработает запросов за 5 минут на 1000 конкурентных юзерах.
512 CPU units это пол ядра :)
И без обид но вы вообще не в курсе что такое async non-blocking. Почитайте про epoll, что такое Netty и тд. Мне не надо стопяцот потоков чтобы читать/писать с сокетов. Я обойдусь всего парочкой — тк в IO bound задач нет проблем с ЦПУ тк основное время это записать-подождать-прочитать какую либо ИО задачу. Все ваши потоки будут просто стоять и ждать и кушать память. При 1000 конкуретных юзерах и thread-per-request у вас по дефолту отожрется 1Гб памяти только для хттп потоков.
Вы походу читаете через строку.
и писать я буду на джаве — какой нить springboot(чтобы пожирнее было :))) ), lettuce и vertx-pg-client. Но могу и на Ноде если вам так сильно хочется.
там тоже внутри вертх драйвер: https://github.com/quarkusio/quarkus/blob/master/extensions/reactive-pg-client/runtime/src/main/java/io/quarkus/reactive/pg/client/runtime/PgPoolProducer.java#L16
нет — Кваркус это просто прослойка под вертексом. С ним из коробки не особо удобно работать на всех его колбеках. А кваркус это все причесывает и делает аля спринг бут :)
Мне нравится ваш подход — возьмем кривое nodejs приложение и будем сравнивать с хорошо написанным джавовским :))) Речь то не об утекании памяти в кривых приложениях, а о том что вы не понимаете зачем нужен async non-blocking подход. Вы считаете что thread-per-request это лучшая практика и что создание тысячи тредов это нормальная ситуация. Готов с вами поспорить на ящик octomore 6.3 что вы пишете свое стандартное потоковое приложение с хождением в редис и постгрес, а я свое и потом мы запускаем все в докере с жесткими ограничениями типа 512 на CPU и 512Mb памяти на контейнер. И долбим к примеру 1000 конкурентных юзеров на это все — а дальше смотрим latency и error rate.
Давайте начнем с того, что однопоточный
NodeJSможет лопатить тысячи запросов в секунду не отжирая гигабайты памяти. а в джава подход — зачем нам думать о памяти и производительности, нафигачим тысячи потоков и разрастемся на десятки ЕС2 инстансов.R2DBC для продакшена еще не готов, то там то здесь вылазят баги — лично сталкивался и постил им тикеты. Да и проскальзывало, что разработчики сосредоточены на доведением его до ума, а не попытках выжать максимум производительности.
Так же Вертх очень быстр: www.techempower.com/benchmarks/#section=data-r15&hw=ph&test=db
Единственное пришлось сделать свою прослойку чтобы удобно работать с ним через Flux/Mono.
и в чем проблема писать БД лог или же складывать все в таблицу куда только инсерты разрешены.
А как быть с транзакционностью — на каком этапе запись в блокчейн?
У меня может быть сложная транзакция в которой создается кучу всего и сейчас я беру и откатываю в случае ошибки. а тут появляется второй датасорс и надо обеспечить согласованность данных. Что делать если блокчейн пишется после фиксации транзакции и запись падает или наоборот записываем в блокчейн в середине транзакции и потом транзакция откатывается?
Как кто то может добраться до БД и что то менять, то так же можно и своих фейковых узлов сделать чтобы в результате цепочка была фейковая :)
subscribeOn,publishOnиparallel:)))Реактивщина отлично заходит на IO bounded задачах. И чего мелочиться с примерами — можно завернуть все в к8с с истио и считать все в хадупе. Чтобы показать какой великолепный и понятный подход плодить на каждый веб запрос по реквесту :)
не — я понял, что надо убирать r2dbc иначе в проде будет беда и в авральном режиме переписывал все на vertx.io/docs/vertx-pg-client/java
Согласен, поэтому и написал, что в качестве PoC все смотрится красиво :)
так же можно посмотреть: www.techempower.com/benchmarks/#section=data-r18&hw=ph&test=db
Из проблем с чем я столкнулся: github.com/r2dbc/r2dbc-postgresql/issues/207 и не обленился сделать ишью.
Так же периодически зависали конекты и приходилось убивать джава процесс.
Если сделать матрешку из конекшена, пула и прокси то у меня на мультитредовых тестах вылетала 34000 постгрес ошибка, хотя никакими курсорами я не пользовался. Стоило убрать либо прокси либо пул и все становилось хорошо.
Периодически получал ошибку, что конекшен неожиданны был закрыт.
До текущего релиза шел в комплекте r2dbc-client, а сейчас то-ли на него забили то-ли еще что, но в bom его уже нет. Что также неприятно.
у меня стандартный джововский набор программ и никаких проблем не было. Кроме Transmission Remote GUI, который за пару дней обновили и уже все работает.