корне

ага, есть такое

и томуподобной фигни

я столько говна с этом шадуом съел

больше только со спринг-бутом ?

а может еще вспомнишь что-то конкретное?

ну, самое банальное -- это то, что по джарке часто сложно сказать, что именно в неё в итоге попало

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

ну да

если пытаешься со спрингом его использовать, то это просто бесконечное количество конфликтов файловых

но у бутового пакера есть свои проблемы из за особенностей доступа к запакованным в jar jar-кам

в зависимости от задачи fat-jar может быть лучше

спасибо. то что нужно

типа, попытка найти несущестующий файл может занимать столько времени, что если у тебя какая-то библиотека делает это в цикле, то время загрузки можно увеличить в разы

а для чего не fat jar может быть лучше?

Я вот залез в джар, META-INF/maven. там список либ

да, в какой-то момент они это добавили

я его использовал последний раз года два назад может три

а для чего не fat jar может быть лучше?

ну например если докер канонический, с слоями, то фэтджар - сильно слои увеличивает, application там удобнее

да, в какой-то момент они это добавили

так это от плагина зависит, надо посмотреть как в мавеновском сделали

я про мавеновский и говорю

а, я просто грэдлом собирал эту джарку

проблему одинаковых файлов понимал, но пока не сталкивался

грейдловый не видел, там обычно это просто делается одной строчкой склеивающей все файлики зависимостей

что совсем страшно

мы используем mergeServiceFiles, т.к. у нас на них все построено

остальное пока не тревожило, спрингом не пользуемся, у нас альтернативный стэк)

Это хорошо, каждой задаче свои инструменты

Просто нужно знать, что такое бывает

И быть к этому готовым

с учетом докера сегодня кажется что проще использовать application plugin, он отлично ложится на слои, image растет очень умеренно

К тому же сейчас плагины стали умнее, многие проблемы умеют лечить

ну проблему с двумя ресурсами врядли они вылечат, это надо классы патчить)

Ну, если известный формат, то можно мерджить

Но это конечно не то что хотелось бы

странно что классы принято расскладывать по пакетам, а ресурсы - нет

А что у вас за альтернативный стэк?

http://bootique.io/

странно что классы принято расскладывать по пакетам, а ресурсы - нет

Тем не менее именно так все и делают ?

т.е выкатывать апликейшен в виде пачки джарников это окей?

т.е выкатывать апликейшен в виде пачки джарников это окей?

it depends

посмотри на idea)

т.е выкатывать апликейшен в виде пачки джарников это окей?

Абсолютно ок

Самый безглючный способ

Фэтджар просто удобнее

Особенно если он еще и экзекютабл

грепать процессы так не очень удобно из-за большой команды для запуска всего этого дела

ну вот jlink придет, и будет действительно executable)

грепать процессы так не очень удобно из-за большой команды для запуска всего этого дела

Это по большому счету мелочи

надо пользоваться удобными инструментами для грепанья)

ну вот jlink придет, и будет действительно executable)

Ну, если совсем executable хочется, то rust ?

надо пользоваться удобными инструментами для грепанья)

htop?

ага

Или go. Надеюсь меня закидают тухлыми помидорами

Ну, если совсем executable хочется, то rust ?

ну тут скорее про минимальный рантайм и простую привязку к версии, на которой можно оттестить и распространять. для проектов типо idea например было бы очень удобно

или опять же, собрал jlink, вкинул в докер, и потом только маленький jar обновляется

java -Xmx32m -Xss256k -jar build/libs/guice-1.0-SNAPSHOT-all.jar хелоуворлд с guice занял 55мб в памяти. jvm так и не научилась меньше кушать?

Ну, если совсем executable хочется, то rust ?

причем мне нравится раст, но я понимаю что для множества проектов он не нужен, скорость разработки куда важнее чем перф или размер бинаря

java -Xmx32m -Xss256k -jar build/libs/guice-1.0-SNAPSHOT-all.jar хелоуворлд с guice занял 55мб в памяти. jvm так и не научилась меньше кушать?

о, расскажи методику подсчета)

java -Xmx32m -Xss256k -jar build/libs/guice-1.0-SNAPSHOT-all.jar хелоуворлд с guice занял 55мб в памяти. jvm так и не научилась меньше кушать?

А зачем? ?

причем мне нравится раст, но я понимаю что для множества проектов он не нужен, скорость разработки куда важнее чем перф или размер бинаря

Конечно, это же я так, вроде пошутил. Хоть и есть в каждой шутке только доля шутки

о, расскажи методику подсчета)

ps aux | grep guice -> RSS

о, расскажи методику подсчета)

или ты за параметры -Xmx32m?

ну RSS это же еще и shared память

у меня полноценное приложение с джусом, базой, рестом, хтмлом, очередью на xmx10m стартует и работает)

и сколько памяти кушает?

ну это сложный вопрос)

загружено 5к классов, размер стека не задавал

метаспейс около 28мб

VIRT 5Gb, RES 105*Mb

хм)

Экономно

правда все-таки свалилось с OOM когда запрос пыталось обработать)

но хэлс чеки отдает)

у меня спрингбут приложуха 170мб кушает

запускал по рекомендуемым параметрам отсюды https://spring.io/blog/2015/12/10/spring-boot-memory-performance

Спринг довольно прожерливый

эт да

без параметров висит приложуха похожая, там 652мб уже

Ну и сильно от поднятой инфраструктуры зависит

и висит веб на пхп. потребления пару мб) отрабатывает только когда приходят запросы в пул

ну а теперь пусти 1000 человек на php и на java

аккуратно написанный java сервер вида не даст, и дальше свой гигабайт будет отжирать)

Ну, так можно не давать так много памяти, я так думаю, что и на 256к будет отлично работать, только мусор придется чаще собирать

Да, пхп вообще умирает после обработки -- вообще ничего жрать не должен

Пока запросы не придут, зато уж если придут...

ну окей, мое полноценное приложение на джаве на 11мб хипа, и при стеке в 256кб отлично работает)

ну а теперь пусти 1000 человек на php и на java

запрос отработает за 40-70мс, каждый активный запрос примерно 30мб кушает. учитывая что на сервере будет всего 2-4 ядра, то одновременно много не будет обрабатываться, и все будут стоять в очереди. так что до гига вряд ли дойдет)

запрос отработает за 40-70мс, каждый активный запрос примерно 30мб кушает. учитывая что на сервере будет всего 2-4 ядра, то одновременно много не будет обрабатываться, и все будут стоять в очереди. так что до гига вряд ли дойдет)

ну если джаву тоже взять андертоу какой, а не сервлеты, то ты так же в 200 мб можешь уложиться, выше пример

андертоу рулит?

ну окей, мое полноценное приложение на джаве на 11мб хипа, и при стеке в 256кб отлично работает)

Я не вижу смысла мериться потребляемой памятью, опасно просто нет смысла давать северному приложению 10мб памяти

конечно нет смысла, но чисто из теоретических соображений...

У меня вот это приложение сейчас на проде ест 270мб)

Я не вижу смысла мериться потребляемой памятью, опасно просто нет смысла давать северному приложению 10мб памяти

если на сервере 2 гига памяти, и у тебя каждый сервис жрет по 500мб. то как много сервисов одновременно ты сможешь держать, которые будут молча висеть ждать с моря погоды?

Using month variable rewrite this pattern in such a way that it matches the date in format 13 JUN 1992 (two digits, a whitespace, a month abbreviation, a whitespace, four digits).

если на сервере 2 гига памяти, и у тебя каждый сервис жрет по 500мб. то как много сервисов одновременно ты сможешь держать, которые будут молча висеть ждать с моря погоды?

Во-первых, не обязательно давать 500метров, можно отлично и на 128 работать. А во-вторых, вопрос в итоге не в памяти, а общей нагрузке

val month = "(JAN|FEB|MAR|APR|MAY|JUN|JUL|AUG|SEP|OCT|NOV|DEC)" fun getPattern(): String = """\d{2}\s\?:$month\s\d{4}"""