Comments 20
Стартовало приложение за 0.022 секунды!
А не кажется ли вам, что это все какой-то самообман? В смысле, мы сами себя ограничиваем k8s и stateless приложениями, пытаемся оптимизировать холодный старт, чтобы микросервис можно было прибить в любой момент, и быстро рестартовать на другом узле — но это же автоматически означает, что приложение не может, например, эффективно использовать кеш, потому что при холодном старте нет прогрева этого кеша.
>даже для реализаций FaaS, где очень важна скорость холодного старта.
Я понимаю что быстрый старт — он всегда в общем не вреден, уж как минимум, вопрос скорее в том, стоит ли овчинка выделки? Как бы вы в целом оценили трудозатраты на всю работу, описанную тут? Это какой-то фиксированный объем для отдельного приложения, или будет зависеть от объема кодовой базы, или еще от чего-то?
Добрый день! На данный момент рассматриваем возможность перевести очень маленькие(пару сотен строк кода) сервисы, которые не нужны все 100% времени. Основные сервисы останутся как есть. Но, полагаю, это позволит выиграть немного памяти и ЦПУ.
например, эффективно использовать кеш
он лежит в редисе и не важно сейчас у вас 2 инстанса или 20
Кваркус (https://quarkus.io) компилируется в натив уже очень давно, в коде при этом ничего править или добавлять не нужно.
Для того, чтобы собрать приложение (jax-rs, cdi, jpa) в натив уходит примерно 10 минут полной загрузки четырёхядерной машины и 8 гб памяти.
Стартует оно быстро, это правда. Но в процессе старта есть задачи, не связанные с инициализацией jvm — накатить liquibase, подцепиться к кафке и т.п., по ним очевидно нет выигрыша во времени. В потреблении памяти и ЦПУ принципиальных различий не замечено, что вполне естетственно.
Вообщем мы пока решили что овчинка выделки не стоит. Хотя всё это, конечно, интересно и т.п.
Вообще, по нашим наблюдениям, в обычном jvm режиме кваркус сравнимой функциональности стартует примерно в 5 (пять) раз быстрее спринг-бута при тех же ограничениях по железу.
В потреблении памяти и ЦПУ принципиальных различий не замечено, что вполне естетственно.
у меня кваркус с кафкой в нативном моде комфортно работает потребляя 15-20 мб памяти, а в жвм режиме порядка 200Мб
вот конфиг с кубера
resources:
limits:
cpu: 0.1
memory: 40M
requests:
cpu: 0.05
memory: 20M
Да, прочитали с топика, сделали бизнес логику по преобразованию сущности и записали ее в другой топик.
Вот что подключено сейчас
Installed features: [cdi, config-yaml, hibernate-validator, kotlin, micrometer, mutiny, smallrye-context-propagation, smallrye-fault-tolerance, smallrye-health, smallrye-reactive-messaging, smallrye-reactive-messaging-kafka, vertx]
В потреблении памяти и ЦПУ принципиальных различий не замечено, что вполне естетственно.
Не очень естественно. У GraalVM большинство оптимизаций про память. Мы у себя проводили тестирование. Выигрыш есть и местами существенный именно по памяти. Но вот скорость компиляции/линковки и требуемые под это дело ресурсы вынудили нас остаться с Кваркусом на JVM.
А вот оно, Annotation Oriented Programming in Action.
Релиз Spring Native Beta