Комментарии 16
Обратите внимание на разницу времени старта: 1548ms vs 144ms. Впечатляет? При этом аналогичная версия на SpringBoot стартует около 3000ms
Не впечатляет от слова совсем. Если вам нужен непрерывно работающий сервис, недоступность даже 144ms так же плоха как и 3s. Вам нужны несколько подов бегущих параллельно и наверное масштабирующиеся от нагрузки. В этом плане экономия на старте пода это экономия на спичках. Если вам не нужен непрерывно работающий сервис, 3 секунды на старт ничем не хуже 144 мс.
В процессе разработки быстрое время запуска идёт на пользу
Так это же не бесплатно (за исключением случаев когда вы начинаете новый проект и вас окружают специалисты по Micronaut). Обычно Micronaut сравнивают со SpringBoot, и вот если рассматривать цену миграции ради 2 секунд экономии времени старта то это очень спорное решение. Опять же в плане рынка мало и проектов на Micronaut и специалистов.
Наверное, я допустил некорректную фразу в статье. Допустим есть два сервиса: один работает в нативно-откомплированном виде, практически без усилий со стороны разработки по причине выбора фрэймворка, второй сервис в виде байткода. Во втором сервисе всё работает (а не только старт) в десятки раз медленнее по своей природе. Не хочу чтобы дискуссию ушла ещё в сторону JIT или AOT, я очень неплохо разбираюсь и в этом. Далее, первый сервис можно точно также настроить в среде "бегущих" подов. Уход в другой контекст мне тоже непонятен. Если в том контексте атомарные сервисы будут быстрее работать, разве это плохо? Да, в среде K8S разница в скорости может быть и не так заметна, не в десятки раз, но эта разность будет уже по другим причинам. Мы сравниваем скорость работы атомарного процесса. Зачем тогда GraalVM или подобная технология? Можно подумать что "бегущих" подов это безполезные технологии? Заканчивую свой ответ. Я просто показал имеющуяся альтернативу. Использовать или не использовать быстрее в 10 раз работающий сервис или модуль - выбор архитектора. Выбор: попробовать Micronaut или остаться на SpringBoot? А может вообще уйти со SpringBoot в Quarkus. Я бы предложил попробовать откомпилировать в нативный вид сервис SpringBoot с JPA? В Golang компиляция в нативный вид присутсвует из коробки, например. И Golang при выборе технологии "побеждает" в том числе и из-за этого преимущества. Кстати, в Android-экосистеме подобный подход в видоизмененном виде уже давно используется. В упрощенном виде этот подход выглядит так: после установки на конкретное(!) устройство при первом запуске программа переводит себя в нативно-откомпилированный вид полностью, и далее работает уже нативно. Там уже давно не стоит вопрос о преимуществах нативно-откомпилированной программы. Если новые возможности не впечатлили, то можно остаться и на проверенных технологиях. Я знаю разработчиков, которые со мной захотели бы поспорить о ложных преимуществах Kotlin перед Java. Это была бы дискуссия на подобную тему. Кстати, в той же Android-экосистеме уже давно только Kotlin, и эффективность языка проверена на миллионах устройств и программ, как и нативная работа этих программ. Нашему enterprise-бэкэнду до такой статистики очень далеко. Но и Java для Android-разработки тоже осталась, если любишь Java продолжай на нём программировать. Так и здесь. Можно остаться на SpringBoot без возможности нативной компиляции. Нативная компиляция только формально есть, вспомни про JPA и "всё на рефлексии" . А можно попробовать почти идентичную технологию, которая позволяет делать сборку в нативный вид без "танцев с бубнами". Кто решения по выбору технологий принимает, многие знают и без меня :). Своим ответом никого обидеть не хочу. И на "религиозные" темы спорить тоже не хочу.
Ну вы откровенно подменяете понятия. Приложение на Micronaut не работает быстрее в 10 раз. Оно только быстрее стартует. Происходит это только по причине компайл-тайм инъекций зависимостей. Все, точка. Неоткуда больше взяться приросту скорости.
Вы серьезно считаете, что программа работающая в связке "jvm + байт-код" работает с той же скоростью, что и тот же вариант программы, скомпилированный в нативный вид?
Двадцать лет назад разрыв был в 10 раз. Сейчас я знаю примеры когда JIT дает более высокое быстродействие чем нативный код. Ни в коем случае не говорю что это правило, но тот разрыв что был 20 лет назад сейчас пренебрежимо мал. Другое дело что да, JIT требует "прогрева", тут не спорю.
Оптимизация в реальном времени: JIT компиляторы работают во время выполнения программы, что позволяет им собирать информацию о её поведении и использовании в реальном времени. Это дает возможность применять специфичные для контекста оптимизации, которые могут быть недоступны AOT компиляторам, работающим без знания конкретного контекста использования кода.
Специализация кода: JIT компиляция может адаптировать и оптимизировать код под конкретную аппаратную платформу и текущую нагрузку. Например, если JIT определяет, что определённая функция вызывается часто, он может оптимизировать её более агрессивно, включая инлайнинг маленьких функций и специализацию кода под текущие данные.
Адаптивная оптимизация: Поскольку JIT компиляторы анализируют программу в процессе её выполнения, они могут адаптировать оптимизацию в ответ на изменяющееся поведение программы. Например, оптимизации, базирующиеся на профилировании, могут учитывать частоту и условия выполнения определенных участков кода и адаптировать их для максимальной производительности.
Удаление недостижимого кода и динамическая девиртуализация: В процессе выполнения JIT может обнаружить код, который никогда не выполняется, и опустить его, или упростить вызовы виртуальных функций, которые всегда вызывают один и тот же метод.
@TerraV, спасибо. Полностью согласен, и про JIT-прогрев в частности. Добавлю, или акцентирую, что статья не про нативную сборку и не призыв, переходить на неё. И не призыв уходит с проверенного SpringBoot. Просто информация об ещё одном фрэймворке. Одна фраза в статье типа "эмоциональное" восхищение чем-то вызвало такую реацию? Автор же имеет право высказать свое отношение к чему-то? И если есть в новом фрэймворке, почему про это на написать. Я, когда читаю статьи, полезную информацию для себя просто помечаю, чтобы в свободное время поглубже разобраться. Только и всего. да, про скорость и вопрос про 10 раз. Естественно, после "прогрева" и работы JIT и оптимизаций, разница в скорости может сойти на нет. Я думал, это все понимают. Набросились на меня из GraalVM :)
Вы действительно считаете, что нейтив-код в 10 раз быстрее в реальном приложении, а не в синтетических тестах?
Будет ли в 10 раз быстрее работать ваше приложение?
Запросы в БД
Запросы в иные сервисы
Здравствуй, путешественник из прошлого. У нас тут 2024 год и java уже давно оптимизирована настолько, что говорить о большой разнице между нативным кодом и jvm не приходится.
Не хочу чтобы дискуссию ушла ещё в сторону JIT или AOT, я очень неплохо разбираюсь и в этом.
За последние ~10-15 лет очень многое изменилось. Советую разобраться заново.
@Sipaha, спасибо за комментарий. Вот уж JIT и AOT начали бурно обсуждать. Статью я хотел написать не про JIT и AOT :). Одна "неосторожная" фраза в статье увела дискуссию в эту сторону. Технологии JVM не стоят на месте и скорости работы могут быть соезмиримы. Просто есть у нас еще один фрэйморк. Статья про это. Ешё про реактивные возможности Kotlin. Я ещё для себя открыл не так давно Kotest, отличный фрэймворк. Моё субьективное мнение :) Есть еще отдельная тема о наличии JVM типа GraalVM в дополнение к "обычным". Ведь если целые компании тратят время на создание чего-то подобного, то значит в этом есть какой-то смысл. Я думаю, мы должны иметь информацию о подобных возможностях. А использовать или нет - это уже другой вопрос. Ещё раз спасибо.
Делать приложение, которое умеет работать параллельно со своей же более старой версией - трудно. И есть куча проектов, для которых простой нежелателен, но скорость разработки важнее.
Кроме того, не забывайте: не все используют кубы, кто-то и на docker compose сидит. А последний в rolling deploy не умеет в принципе!
Кроме того, не забывайте: не все используют кубы, кто-то и на docker compose сидит. А последний в rolling deploy не умеет в принципе!
У нас с вами нет противоречий. Есть задача - под нее можно подбирать инструмент который соответствует желаемым метрикам. Я обычно руководствуюсь двумя метриками - "Time to market" и "Cost of ownership". Так вот в плане скорости разработки в подавляющем большинстве случаев выгоднее выбирать инструмент которым уже владеешь профессионально. А в плане стоимости владения лучше избегать экзотики, т.к. рынок кандидатов довольно тощий.
Трудно наверное разве что джуну, для всех остальных поддержка обратной совместимости, хоть на сколько-то версий, вполне обычная практика. Я даже представить не могу, что можно писать не волнуясь об обратной совместимости
Создание реактивных сервисов Micronaut и Kotlin