Нод 2, бэкенд

а для одной ноды самое то. да. я такие как раз на ажуре и беру.

А шо там по нагрузке?

В пике шло порядка двух сотен сообщений в секунду, наверное, в центральную очередь, где 100 потоков. Она в процессе работы генерит сообщения в другие очереди

а для одной ноды самое то. да. я такие как раз на ажуре и беру.

Ага, мы в амазоне)

Хм

Ну на 2 может и многовато

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

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

Тредпул, рулится либой - клиентом к актив мк

Блокировки есть, ходим синхронно на реальное железо за данными

Toolbox App кто уже использует. Как он приложения обновляет? Как всегда, качает весь пакет, или патчами?

Тогда без такого количества никак

Тогда без такого количества никак

Да, всё правда, спасибо

Счас поем и буду писать письмо

Лёг в 7, встал в 2)

Удаленка?

Удаленка?

Европа обновлялась ночью, я контролировал процесс

А это из дома комфортнее

Чем в офис ехать и ночь с пиццей сидеть

Три сотни потоков листенеров - многовато таки на два ядра же?

Ядра два, потоков 300, значит планировщик JVM очень много работы делает по переключению контекста выполнения каждого потока, приводя его в соответствие физической модели. Проще говоря - чет дохрена потоков на 2 ядра.

Ядра два, потоков 300, значит планировщик JVM очень много работы делает по переключению контекста выполнения каждого потока, приводя его в соответствие физической модели. Проще говоря - чет дохрена потоков на 2 ядра.

Вот и я о том же

На 4 ещё куда ни шло

Но откровенно говоря вопрос такой: зачем вам вообще больше 1 листенера на ActiveMQ? Если говорить про распространенные практики - обычно берут Runtime.availableProcessors() * 2. Так, например, это дефолтная конфигурация Worker потоков для обработки запросов в Netty.

На 4 ещё куда ни шло

Даже на 4 много

тут еще дело в чем - сколько у этих потоков idle time. Если они все спящие и про запас - нет проблем, но есть у всех 100% running, тогда на переключениях контекста ты достойно теряешь

есть 100 load - нет смысла больше 3-4 на ядро

тут еще дело в чем - сколько у этих потоков idle time. Если они все спящие и про запас - нет проблем, но есть у всех 100% running, тогда на переключениях контекста ты достойно теряешь

Ну даже если они припаркованы, они все равно бесполезные. Плюс каждому нужен локальный стек и пр. Каждый поток, даже припаркованный - это ресурсы вашей системы в никуда.

верно, но по производительности это не сильно ударит если все тихо а вот если во все сокеты начнется заливка данных - тогда держитесь

Я вообще не вижу необходимости здесь городить тонну потоков. На мой взгляд, в базовом случае, будет достаточно 1 IO потока и Runtime.availableProcessors * 2 на обработку. Вспомним Node.JS, Java NIO, обработка входящего потока прекрасно выполняется без необходимости параллелить этот процесс

Процессоры денег стоят

И просто так их мне никто не даст

Нагрузка на всё - только в пиках

Так используйте 1 поток на IO и до 10 на обработку. В вашем случае - более, чем достаточно

Большую часть времени - они припаркованы, у меня там вообще рост от 20 до 100, если не пик, то мы и не вырастем

Полный перезапуск - это как раз пик, поэтому вчера мы немного застряли

Но, на 4 ядрах мы это моделировали, прожуем без проблем

Но тут вот какой момент с однопоточной моделью: не знаю про ActiveMQ, но RabbitMQ гарантирует доставку. Это работает так: Агент А отправляет сообщение агенту В через брокера. Брокер передал сообщение агенту В, но сообщение не удалил, лишь пометил. Если от агента В приходит флаг ACK на это сообщение, оно удаляется, в противном случае возвращается в очередь. Теперь вот что: если вы используете 1 поток на вычитку входящих сообщений, а обработку в пуле, то в случае, если обработка провалится, сообщение не вернётся в очередь ActiveMQ, т.к. IO поток после вычитки и перед передачей в пул обработки пометит сообщение как ACK (Acknowledge). Обычно это делается под капотом фреймворка интеграции с ActiveMQ, например. В общем, проектируя систему, держите это в голове. Проблема решается использованием более низкоуровневых транспортных абстракции, например.

Но тут вот какой момент с однопоточной моделью: не знаю про ActiveMQ, но RabbitMQ гарантирует доставку. Это работает так: Агент А отправляет сообщение агенту В через брокера. Брокер передал сообщение агенту В, но сообщение не удалил, лишь пометил. Если от агента В приходит флаг ACK на это сообщение, оно удаляется, в противном случае возвращается в очередь. Теперь вот что: если вы используете 1 поток на вычитку входящих сообщений, а обработку в пуле, то в случае, если обработка провалится, сообщение не вернётся в очередь ActiveMQ, т.к. IO поток после вычитки и перед передачей в пул обработки пометит сообщение как ACK (Acknowledge). Обычно это делается под капотом фреймворка интеграции с ActiveMQ, например. В общем, проектируя систему, держите это в голове. Проблема решается использованием более низкоуровневых транспортных абстракции, например.

Да, это я знаю, насколько я знаю - нам не критично, если где-то что-то пропадет

Да, это я знаю, насколько я знаю - нам не критично, если где-то что-то пропадет

Тем более. Делайте 1 листенер, который пихает задачи на обработку в пул из, например, 8 потоков.

300 потоков - в 99% случаев - ошибочное проектирование системы.

Тем более. Делайте 1 листенер, который пихает задачи на обработку в пул из, например, 8 потоков.

У нас так и было, были свои проблемы, ушли на вариант который я выше описал

300 потоков - в 99% случаев - ошибочное проектирование системы.

300 - это всего

промежуточная очередь и пул потоков нынче не модно?

300 - это всего

Тем он менее

промежуточная очередь и пул потоков нынче не модно?

А зачем здесь?

Вообще на все очереди и не очереди

Начальный старт - где-то до сотни потоков

И максимальная сотня нужна только на одну очередь

Остальные надо покрутить

Чтобы в пике было потоков 150, из них 100 на главную очередь, в которую вся нагрузка приходит

Вообще на все очереди и не очереди

Это все равно много. Старайтесь их сократить. 100 потоков это очень много. Очень много бесполезной работы вашего приложения уходит на переключение контекста. В вашем случае многопоточность не помогает, а скорее мешает. Если постоянно переключать множество потоков, работа будет выполнена неэффективно.

Именно это и и было сегодня ночью

Поэтому, я полностью согласен

Поэтому, я полностью согласен

Рад был помочь. Удачи вашему проекту!

Рад был помочь. Удачи вашему проекту!

Спасибо

как вы в хибере получаете некст значение сиквенца? без директ склл. (конкретного seq)

как вы в хибере получаете некст значение сиквенца? без директ склл. (конкретного seq)

Select currval('users_seq')

так это же текущий

он же написал без SQL

так это же текущий

Ну nextval()

но это с директ скл

он же написал без SQL

Аа, этого я не понял из вопроса

но это с директ скл

Иначе никак

ии то что ты пишешь вроде только под оракл

ии то что ты пишешь вроде только под оракл

Не, постгре

ну под те субд которые sequence поддерживают

ну под те субд которые sequence поддерживают

Ага

ну под те субд которые sequence поддерживают

H2, HSQLD, Postgres - эти точно работают с таким синтаксисом

ERROR: S client not available

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

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

нужно будет писать SELECT sequence_name.nextval FROM dual

нужно будет писать SELECT sequence_name.nextval FROM dual

А что за dual?

нужно будет писать SELECT sequence_name.nextval FROM dual

у меня так и есть

в oracle нельзя SELECT 1

Там используется dummy таблица

@Id @GeneratedValue(strategy = GenerationType.SEQUENCE, generator = "user_info_id_seq") @SequenceGenerator(name = "user_info_id_seq", sequenceName = "user_info_id_seq", allocationSize = 1) а такое с ораклом не катит?

только там SELECT sequence_name.nextval id FROM dual

id вроде нужен

@Id @GeneratedValue(strategy = GenerationType.SEQUENCE, generator = "user_info_id_seq") @SequenceGenerator(name = "user_info_id_seq", sequenceName = "user_info_id_seq", allocationSize = 1) а такое с ораклом не катит?

это ты описываешь. а как накрутить +1 и получь?

в oracle нельзя SELECT 1

Ух ты! Спасибо! Не знал.

это ты описываешь. а как накрутить +1 и получь?

а, не так понял вопрос

но уже и ответили же

угу

значит никак

я думал ты предлагаешь другой вариант

значит никак

https://stackoverflow.com/a/23267212/2262442

Ух ты! Спасибо! Не знал.

еще нельзя в какой-то из IBM базы DB2 или Informix :P

ой впизду такое городить) нигде такое особо не используется больше

ой впизду такое городить) нигде такое особо не используется больше

а почему нельзя просто запросом?

да можно. думал че то есть красивое готовое уже

не, красивее некуда)

главное чтобы имя seq не поменял никто))))0

главное чтобы имя seq не поменял никто))))0

ого ) извращения можно придумать

хотя, вроде seq к таблице не привязываются, так что нет

думал решить проблему методом selectа seq из объектов

что то в торе решил проверить какой сек у меня щас. а без сессии никак

Вероятно, не очень умный вопрос: private static KeyPair GenerateKeys() { return generateKeyPair(); } final String pubKey = Base64.getEncoder().encodeToString(GenerateKeys.getPublicKey()) final String privKey = Base64.getEncoder().encodeToString(GenerateKeys.getPrivateKey()) У меня будет два ключа которые между собой никак не связаны? Или это таки будет публичный сгенерированный на основе приватного? Алгоритм ECDSA от BouncyCastle

а есть документация какая-нибудь к классу GenerateKeys и его статическим методам getPrivateKey и getPublicKey

Я бы рекомендовал почитать документацию