Отчёты обычно формируются на основе сложных запросов к БД. Поэтому на порядок лучший профит получится, если формировать отчёт запросами к реплике БД, а не от того, что основная БД будет также загружена запросами из другого процесса.
Да, я думал про такой вариант, но отбросил его, т.к. делать это на уровне своего приложения нелогично, когда уже есть ffmpeg, imagemagick и т.д.
Вопрос же был не в общем кол-ве занятой памяти на сервере, а исключительно про занятую под монолитное приложение.
Под одновременными реквестами Вы имеете в виду в секунду или в минуту? Вообще, когда говорят про пользователей, обычно подразумевается, что в предыдущие N минут были какие-то запросы от 16 тыс. уников. Где N — время, исходя из которого границы визита определяются, для GA и Метрики — это 30 минут iirc. Напрямую rps из этого вывести сложно, не зная специфики приложения.
Кстати, роуты в Rails проверяются по порядку, так что если у Вас реально проблема с тысячами неиспользуемых роутов, то вынесите десяток реально используемых на самый верх routes.rb и остальные роуты будут отнимать ресурсы на проверку раз в году, или когда там до них дело дойдёт )
Нет, если потребляемое ОЗУ растёт линейно от кол-ва пользователей, то это нормально только для какого-нибудь кеша или in-memory БД, но там есть свои приёмы, чтобы ограничить потребляемую память сверху.
А для основного приложения — это совсем ненормально… Какой-нибудь reddit-эффект и у вас серваки вылетят с out of memory?
Ох, как Вас бомбит, даже ссылку на официальные system requirements заминусовали… ну и ну.
Не описания, а описания и выполнения. И да, процессы тоже жрут память.
Ну, если у них бизнес-процессы выполняются в том же процессе, что и IDE, то это не монолит виноват, это уже фантасмагория какая-то.
Намекаю: если вы чего-то в жизни не видели, это не значит, что этого не бывает.
А я и не спорю, что бывает. Но когда такое бывает, всегда можно улучшить и привести систему в более адекватное состояние, было бы желание и ресурсы.
Если в рекомендациях у IBM что-то написано — это не значит, что этому нужно верить.
Вот как! То есть Вы считаете, что когда разработчик заявляет, что для оптимальной работы его системы требуется N памяти (где N — это дофига Gb), а по факту система потребляет 4*N, то это адекватная работа системы? IBM слишком высокомерна по отношению к своим пользователям, примерно как Вы — к собеседникам )
For 64-bit systems, the minimum system memory requirement to support a clustered configuration with a deployment manager, node agent, and single cluster member is 6 GB. However, for optimal performance the recommended configuration is 8 GB.
Даже исходя из этого, можно сделать вывод, что у вас скорее был какой-то баг с утечкой памяти...
В классических клиент-серверных приложениях все эти микросервисы 10 лет назад уже были, может ещё и раньше были… чего тут обсуждать то? Или Вы их теперь через Docker стали разворачивать? xD
видел веб-приложения, которые совершенно по делу жрут 32 гигабайта и более — самый яркий пример это пожалуй IBM BPM. Всего-то на 50 пользователей, примерно.
Судя по описанию, какая-то web-IDE для описания бизнес-процессов. Хз как она умудряется столько памяти жрать… Интерфейс весь (сохранение взаимного расположения, drag-n-drop, etc.) можно на клиенте отрабатывать, к серверу запросы только при явном сохранении или авто-сохранение раз в минуту, плюс подгрузка запрашиваемых данных в JSON.
Я даже демо-видео посмотрел ради интереса и в упор не вижу с чего бы воркеру этой штуки хотя бы 1 Gb по делу съесть, не то что 32. Просто это IBM и им наплевать сколько вам придётся памяти докупить xD
Как правило, всё это добро сводится к запуску фоновых задач посредством того же монолита. Поэтому его сетап сводится к переносу crontab, если само приложение его не заполняет автоматически.
А если парсер прайса и ресайзер картинок — это отдельные приложения, то это уже и не монолит по сути.
В статье только аббревиатура HTTP встречается 6 раз, не считая множества других признаков… Так что уместнее вопрос, с чего Вы взяли, что тут обсуждается что-то кроме веб-приложений?
Монолит жрет 16Gb памяти. Микросервис, который точка отказа — 128Mb.
Это что ж Вы такое делаете? Обычно 500 Mb под инстанс монолита более, чем хватает.
Хоть числа и только как пример, но их соотношение вызывает вопросы… На микросервис конечно меньше памяти приходится, но во-первых не в 100 с лишним раз, а раз в 5-10, да и сумма памяти, потребляемой всеми микросервисами скорее всего будет в пару раз больше, чем нужно монолиту.
У меня сложилось впечатление, что Fesor имеет представление о том как происходит аллокация памяти. Чего не знают обычно пользователи скриптовых и языков с динамической типизацией.
Очень самокритично )
Так и быть, просвещу Вас: в Java строки иммутабельны и вместо конкатенации по факту происходит создание новой строки, поэтому Ваш пассаж про непрерывный блок памяти вообще мимо кассы.
Тут смысл именно сравнить str += 's' и $str .= 's', как эквивалентные операции. А после того, как выяснили, что конкатенация строк в Java медленная, надо задавать себе правильные вопросы, например: "а почему она медленная?". И разумеется, глупо отвечать "потому что в Java кривое управление памятью"… вообще никогда не списывайте на то, что язык плох. Языки пишут отнюдь не идиоты, кроме того в их разработку вкладываются огромные средства. Поэтому не бывает что-то медленно без причины, это всегда следствие определенных компромиссов, которые дают другие преимущества.
Смысл есть от любых сравнений. Если сравнивать скорость конкатенации строк, то можно узнать, что в Java она медленная. А перфоманс языка надо уже на более сложных алгоритмах смотреть, но там каждый тест должен эксперт по конкретному языку писать, а не так, как это обычно бывает в интернете )))
Обычно при сравнении производительности просто пишут эквивалентный код на разных языках, цели написать его оптимально при этом нет, скорее наоборот. Поэтому StringBuilder применять в данной случае нельзя, т.к. автор поставил задачу замерить именно скорость "ада и содомии по созданию строк".
А то Вы такими темпами второй тест редуцируете до строчки count = 1000000 и так далее.
В общем, сравнения должны быть честными, вне зависимости от того, что сравнивается.
Отчёты обычно формируются на основе сложных запросов к БД. Поэтому на порядок лучший профит получится, если формировать отчёт запросами к реплике БД, а не от того, что основная БД будет также загружена запросами из другого процесса.
Какая-то ложная дихотомия получается… Этак, если в проекте используется cron, то он уже микросервисным резко становится? xD
Да, я думал про такой вариант, но отбросил его, т.к. делать это на уровне своего приложения нелогично, когда уже есть ffmpeg, imagemagick и т.д.
Вопрос же был не в общем кол-ве занятой памяти на сервере, а исключительно про занятую под монолитное приложение.
Под одновременными реквестами Вы имеете в виду в секунду или в минуту? Вообще, когда говорят про пользователей, обычно подразумевается, что в предыдущие N минут были какие-то запросы от 16 тыс. уников. Где N — время, исходя из которого границы визита определяются, для GA и Метрики — это 30 минут iirc. Напрямую rps из этого вывести сложно, не зная специфики приложения.
Кстати, роуты в Rails проверяются по порядку, так что если у Вас реально проблема с тысячами неиспользуемых роутов, то вынесите десяток реально используемых на самый верх routes.rb и остальные роуты будут отнимать ресурсы на проверку раз в году, или когда там до них дело дойдёт )
Нет, если потребляемое ОЗУ растёт линейно от кол-ва пользователей, то это нормально только для какого-нибудь кеша или in-memory БД, но там есть свои приёмы, чтобы ограничить потребляемую память сверху.
А для основного приложения — это совсем ненормально… Какой-нибудь reddit-эффект и у вас серваки вылетят с out of memory?
Сейчас чего только нет поверх JS, уверен, что и Forth найдётся...
Есть ведь уже Amber:
Наслаждайтесь ;-)
Ох, как Вас бомбит, даже ссылку на официальные system requirements заминусовали… ну и ну.
Ну, если у них бизнес-процессы выполняются в том же процессе, что и IDE, то это не монолит виноват, это уже фантасмагория какая-то.
А я и не спорю, что бывает. Но когда такое бывает, всегда можно улучшить и привести систему в более адекватное состояние, было бы желание и ресурсы.
Вот как! То есть Вы считаете, что когда разработчик заявляет, что для оптимальной работы его системы требуется N памяти (где N — это дофига Gb), а по факту система потребляет 4*N, то это адекватная работа системы? IBM слишком высокомерна по отношению к своим пользователям, примерно как Вы — к собеседникам )
Кстати, посмотрел требования к IBM BPM Advanced 8.5.7
Даже исходя из этого, можно сделать вывод, что у вас скорее был какой-то баг с утечкой памяти...
В классических клиент-серверных приложениях все эти микросервисы 10 лет назад уже были, может ещё и раньше были… чего тут обсуждать то? Или Вы их теперь через Docker стали разворачивать? xD
Судя по описанию, какая-то web-IDE для описания бизнес-процессов. Хз как она умудряется столько памяти жрать… Интерфейс весь (сохранение взаимного расположения, drag-n-drop, etc.) можно на клиенте отрабатывать, к серверу запросы только при явном сохранении или авто-сохранение раз в минуту, плюс подгрузка запрашиваемых данных в JSON.
Я даже демо-видео посмотрел ради интереса и в упор не вижу с чего бы воркеру этой штуки хотя бы 1 Gb по делу съесть, не то что 32. Просто это IBM и им наплевать сколько вам придётся памяти докупить xD
Как правило, всё это добро сводится к запуску фоновых задач посредством того же монолита. Поэтому его сетап сводится к переносу crontab, если само приложение его не заполняет автоматически.
А если парсер прайса и ресайзер картинок — это отдельные приложения, то это уже и не монолит по сути.
В статье только аббревиатура HTTP встречается 6 раз, не считая множества других признаков… Так что уместнее вопрос, с чего Вы взяли, что тут обсуждается что-то кроме веб-приложений?
У Вас, видимо, есть несколько примеров веб-приложений, которые могут по делу откушать 16 Gb оперативки?
Это что ж Вы такое делаете? Обычно 500 Mb под инстанс монолита более, чем хватает.
Хоть числа и только как пример, но их соотношение вызывает вопросы… На микросервис конечно меньше памяти приходится, но во-первых не в 100 с лишним раз, а раз в 5-10, да и сумма памяти, потребляемой всеми микросервисами скорее всего будет в пару раз больше, чем нужно монолиту.
Очень самокритично )
Так и быть, просвещу Вас: в Java строки иммутабельны и вместо конкатенации по факту происходит создание новой строки, поэтому Ваш пассаж про непрерывный блок памяти вообще мимо кассы.
Вы ветку комментариев то читаете или к чему Ваш комментарий? Про кривое управление памятью Fesor писал двумя сообщениями выше.
Тут смысл именно сравнить
str += 's'и$str .= 's', как эквивалентные операции. А после того, как выяснили, что конкатенация строк в Java медленная, надо задавать себе правильные вопросы, например: "а почему она медленная?". И разумеется, глупо отвечать "потому что в Java кривое управление памятью"… вообще никогда не списывайте на то, что язык плох. Языки пишут отнюдь не идиоты, кроме того в их разработку вкладываются огромные средства. Поэтому не бывает что-то медленно без причины, это всегда следствие определенных компромиссов, которые дают другие преимущества.Смысл есть от любых сравнений. Если сравнивать скорость конкатенации строк, то можно узнать, что в Java она медленная. А перфоманс языка надо уже на более сложных алгоритмах смотреть, но там каждый тест должен эксперт по конкретному языку писать, а не так, как это обычно бывает в интернете )))
Обычно при сравнении производительности просто пишут эквивалентный код на разных языках, цели написать его оптимально при этом нет, скорее наоборот. Поэтому StringBuilder применять в данной случае нельзя, т.к. автор поставил задачу замерить именно скорость "ада и содомии по созданию строк".
А то Вы такими темпами второй тест редуцируете до строчки
count = 1000000и так далее.В общем, сравнения должны быть честными, вне зависимости от того, что сравнивается.