anastasiya-asenchik Aug 18 2023 at 17:40

Как скомпилировать Spring Boot приложение в native image с помощью GraalVm и развернуть его с помощью Docker

Medium

11 min

7.5K

Programming*Java*

Tutorial

Java one love season ☕

From sandbox

Comments 10

typik89 Aug 18 2023 at 18:34

Если сравнивать производительность для конечно точки, то JAR работает стабильно лучше. - не очень понял это предложение
Спасибо за статью.
Сделал для себя вывод, что кажется 7 процентов того не стоят, сколько особенностей настройки стоит держать в голове. Да и если я правильно понимаю, то в итоге есть вероятность, что с jit оптимизациями приложение будет работать даже быстрей, чем native image

aol-nnov Aug 18 2023 at 19:38

Если сравнивать производительность для конечно точки

вероятно, имелась ввиду api endpoint )

headliner1985 Aug 18 2023 at 20:00

Пока как я понимаю единственное применение это в облаках для лямбд, функций и тд. ТК там платишь за время и ресурсы.

GerrAlt Aug 18 2023 at 21:54

Если у вас присутствует развертывание дополнительных экземпляров сервиса в ответ на повышение нагрузки на нем, вам скорее всего очень хочется чтобы старт новых экземпляров происходил максимально быстро - вот тут native image также может найти применение.

dyadyaSerezha Aug 20 2023 at 08:02

Если изменения нагрузки суточные, то вы мало что выиграете. Но в доках самого GraalVM написано, что и памяти такой екзешник меньше ест, что и понятно - не надо хранить кучу байт-кода, jit-компилятор, загрузчик классов и т.п.

dyadyaSerezha Aug 20 2023 at 08:03

Это стало одной из причин интереса к GraalVm - виртуальной машине, написанной на Java, помогающая делать программы быстрее с помощью JIT компилятора

Я даже не знаю, есть ли сейчас какие-то jvm, у которых нет jit-компилятора. Так зачем на этом акцентировать?

anastasiya-asenchik Aug 22 2023 at 22:24

да, спасибо за замечание, сделала апдейт)

mello1984 Aug 22 2023 at 08:31

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

Запуск 4 секунды против 1, с одной стороны выглядит существенным (допустим 10 батчей в кубе - это 40 секунд против 10. Но если у вас сервис сам стартует секунд 15 хотя бы - это разница 150 секунд против 180. При этом сборка простенького образа в 12 минут - это усложнение разработки...
7% экономии памяти - даже на голом приложении не шокируют. А что будет на реальных нагрузках с хипом реального сервиса - вопрос открытый. Там это может быть разница в 50 мб на фоне гига-двух.

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

За статью спасибо, понравилась.

mizugoji Jul 2 at 12:05

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

Подскажите, а что это за сервисы такие, где быстро стартуют, принимают запросы и приложение завершается?

izogfif Aug 18 at 01:53

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