A
какой rps на кафке получился и на IIB?
Size: a a a
2021 January 15
SB
Производительность меряется на фиксированном железе же. Причём одном и том же. Так вот условный глассфиш даёт больше тпс чем условная кафка, а условный веблоджик чуть больше, чем условный глассфиш
Што, простите ) ? А условный ворд даёт больше тпс чем условный глассфиш ))) ? Кафка - это просто распределённый транзакционный лог, это не сервер приложений.
Н
Производительность меряется на фиксированном железе же. Причём одном и том же. Так вот условный глассфиш даёт больше тпс чем условная кафка, а условный веблоджик чуть больше, чем условный глассфиш
нет же, софт работает по разному
если на оборудовании подобранном под каждый стек, но одной цены, тогда ок
если на оборудовании подобранном под каждый стек, но одной цены, тогда ок
А
Я не могу ответить, извините. Скажу только, что один и тот же поток сообщений обрабатываемый в разных бизнес процессах (в разных бизнес подразделениях компании) мы направляем и туда и туда. Число потребителей и прикладных процессов разное, но соизмеримое. Логика маршрутизации внутри технологического сегмента - одинаковая. Сервера баз банных - одни и теже. Ресурсы на kafka потребовались в 7 раз выше по памяти и почти в 12 по процессорам.
Н
Анатолик
Я не могу ответить, извините. Скажу только, что один и тот же поток сообщений обрабатываемый в разных бизнес процессах (в разных бизнес подразделениях компании) мы направляем и туда и туда. Число потребителей и прикладных процессов разное, но соизмеримое. Логика маршрутизации внутри технологического сегмента - одинаковая. Сервера баз банных - одни и теже. Ресурсы на kafka потребовались в 7 раз выше по памяти и почти в 12 по процессорам.
а спецы компетентные по кафке есть? на дефолтных конфигах не любой софт работает нормально
AP
Што, простите ) ? А условный ворд даёт больше тпс чем условный глассфиш ))) ? Кафка - это просто распределённый транзакционный лог, это не сервер приложений.
слово "условный" как бы должно намекать, что мне лень было писать что-то в духе "одинаковый функционал, реализованный на родственном одному, второму или третьему названию софтварном стеке"
A
Анатолик
Я не могу ответить, извините. Скажу только, что один и тот же поток сообщений обрабатываемый в разных бизнес процессах (в разных бизнес подразделениях компании) мы направляем и туда и туда. Число потребителей и прикладных процессов разное, но соизмеримое. Логика маршрутизации внутри технологического сегмента - одинаковая. Сервера баз банных - одни и теже. Ресурсы на kafka потребовались в 7 раз выше по памяти и почти в 12 по процессорам.
Жаль нельзя детали обсудить. Выглядит невозможным, при правильном конфигурировании, чтобы кафка была настолько хуже ibm.
Ранее встречал кейсы, когда кафка была быстрее и когда она была сравнима.
Ранее встречал кейсы, когда кафка была быстрее и когда она была сравнима.
AP
Анатолик
Я не могу ответить, извините. Скажу только, что один и тот же поток сообщений обрабатываемый в разных бизнес процессах (в разных бизнес подразделениях компании) мы направляем и туда и туда. Число потребителей и прикладных процессов разное, но соизмеримое. Логика маршрутизации внутри технологического сегмента - одинаковая. Сервера баз банных - одни и теже. Ресурсы на kafka потребовались в 7 раз выше по памяти и почти в 12 по процессорам.
вот я охотно верю, правда мой опыт это где-то ~5 раз
VI
А почему вы выбрали Archimate? O-AA для отображения архитектуры ПО рекомендует c4model.com Саймона Брауна
Согласен про C4. в EPAM мы обычно используем Solution Architecture Document. К сожалению, про это пока нет статьи, но есть про диаграммы, которые я обычно использую. Для описания солюшна должно подойти
VI
А
Слово "хуже" не уместно. Проект работает и работает успешно. Спецы - интеграторы, потом свои на развитие и доводку.
Точно совершенно - проще чем IBM.
Точно совершенно - проще чем IBM.
AP
@jFagor если честно, я перестал запоминать меняющиеся продуктовые названия. Так-то и веблоджик вроде переименовывали после девятки покупки. И у IBM продукт уже давно иначе называется.
Понятно же, о каких трёх стеках речь идёт.
Понятно же, о каких трёх стеках речь идёт.
MS
Согласен про C4. в EPAM мы обычно используем Solution Architecture Document. К сожалению, про это пока нет статьи, но есть про диаграммы, которые я обычно использую. Для описания солюшна должно подойти
Про диаграммы статья полезная. Будем ждать про документ :)
SB
Анатолик
Я не могу ответить, извините. Скажу только, что один и тот же поток сообщений обрабатываемый в разных бизнес процессах (в разных бизнес подразделениях компании) мы направляем и туда и туда. Число потребителей и прикладных процессов разное, но соизмеримое. Логика маршрутизации внутри технологического сегмента - одинаковая. Сервера баз банных - одни и теже. Ресурсы на kafka потребовались в 7 раз выше по памяти и почти в 12 по процессорам.
Интересно, жаль что подробностей нет. А кафка как использовалась - в изначальном виде или через всякие там kafka streams, ksql и т.п.?
F
@jFagor если честно, я перестал запоминать меняющиеся продуктовые названия. Так-то и веблоджик вроде переименовывали после девятки покупки. И у IBM продукт уже давно иначе называется.
Понятно же, о каких трёх стеках речь идёт.
Понятно же, о каких трёх стеках речь идёт.
Да, я понял, дальше как прочел. на самом деле когда решения однотипны, их десятки, да все про одно, уже даже нет смысла говорить, так как преимуществ почти нет, только плюсы для отдельных кейсов.
P
во-первых, 1 млн это не очень большое количество пользователей само по себе
во-вторых, технически важнее количество транзакций
в третьих, разделяйте слои: вы биллинг хотите модернизировать или платёжный шлюз всё-таки? Какую из частей "платёжной системы"? Или всю архитектуру перепилить? Тогда почему именно шина стала ключевым элементом? Старайтесь вообще логику и шину отдельно держать по-максимуму (100% ни у кого не получалось ещё)
ну и в чётвёртых, выбор-то не велик - либо модная кафка, либо проверенные IBM или Оракл
Вендоров не порекомендую: что белочка, что джет, что Ланит - все имеют свои плюсы и минусы
во-вторых, технически важнее количество транзакций
в третьих, разделяйте слои: вы биллинг хотите модернизировать или платёжный шлюз всё-таки? Какую из частей "платёжной системы"? Или всю архитектуру перепилить? Тогда почему именно шина стала ключевым элементом? Старайтесь вообще логику и шину отдельно держать по-максимуму (100% ни у кого не получалось ещё)
ну и в чётвёртых, выбор-то не велик - либо модная кафка, либо проверенные IBM или Оракл
Вендоров не порекомендую: что белочка, что джет, что Ланит - все имеют свои плюсы и минусы
Поддерживаю.
Первый вопрос в "распиле" монолита точно не выбор конкретной шины. А так можем с нашим технологическим подразделением более предметный разговор организовать (в личку).
Первый вопрос в "распиле" монолита точно не выбор конкретной шины. А так можем с нашим технологическим подразделением более предметный разговор организовать (в личку).
AP
Да господи, вот чё сразу про монолит. Речь же не об этом была )
K
Поддерживаю.
Первый вопрос в "распиле" монолита точно не выбор конкретной шины. А так можем с нашим технологическим подразделением более предметный разговор организовать (в личку).
Первый вопрос в "распиле" монолита точно не выбор конкретной шины. А так можем с нашим технологическим подразделением более предметный разговор организовать (в личку).
Ммм ... а если не секрет, какой вопрос первый ? :)
P
Сказано: 90% логики в БД, хранимки, не тянет нагрузку, сложно дорабатывать =)
K
Сказано: 90% логики в БД, хранимки, не тянет нагрузку, сложно дорабатывать =)
Нагрузку тянет и дальше тянуть будет, это не проблема.
Проблема в расширении бизнеса - в поддержке, грубо говоря. разрабов высокой квалификации не хватает.
Поэтому может было бы проще перейти на шину, а вязать к шине новые "бизнесы" разрабы высокого уровня не нужны
Проблема в расширении бизнеса - в поддержке, грубо говоря. разрабов высокой квалификации не хватает.
Поэтому может было бы проще перейти на шину, а вязать к шине новые "бизнесы" разрабы высокого уровня не нужны