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

[typik89]

5. Если сравнивать производительность для конечно точки, то JAR работает стабильно лучше. - не очень понял это предложение

   Спасибо за статью.

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

[aol-nnov]

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

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

[headliner1985]

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

[GerrAlt]

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

[dyadyaSerezha]

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

[dyadyaSerezha]

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

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

[anastasiya-asenchik]

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

[mello1984]

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

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

2. 7% экономии памяти - даже на голом приложении не шокируют. А что будет на реальных нагрузках с хипом реального сервиса - вопрос открытый. Там это может быть разница в 50 мб на фоне гига-двух.

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

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

[mizugoji]

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

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

[izogfif]

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