Pull to refresh

Comments 20

UFO landed and left these words here

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

Стартовало приложение за 0.022 секунды!


А не кажется ли вам, что это все какой-то самообман? В смысле, мы сами себя ограничиваем k8s и stateless приложениями, пытаемся оптимизировать холодный старт, чтобы микросервис можно было прибить в любой момент, и быстро рестартовать на другом узле — но это же автоматически означает, что приложение не может, например, эффективно использовать кеш, потому что при холодном старте нет прогрева этого кеша.

>даже для реализаций FaaS, где очень важна скорость холодного старта.
Я понимаю что быстрый старт — он всегда в общем не вреден, уж как минимум, вопрос скорее в том, стоит ли овчинка выделки? Как бы вы в целом оценили трудозатраты на всю работу, описанную тут? Это какой-то фиксированный объем для отдельного приложения, или будет зависеть от объема кодовой базы, или еще от чего-то?

Добрый день! На данный момент рассматриваем возможность перевести очень маленькие(пару сотен строк кода) сервисы, которые не нужны все 100% времени. Основные сервисы останутся как есть. Но, полагаю, это позволит выиграть немного памяти и ЦПУ.

То есть, у вас это именно мелкие, и stateless? А что насчет затрат усилий?

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

Там может не мучиться с натягиванием спринга на грааль и перевести их на микронавт?
UFO landed and left these words here
например, эффективно использовать кеш

он лежит в редисе и не важно сейчас у вас 2 инстанса или 20

Логично. Т.е. в наличии один statefull сервис, который позволяет остальным быть stateless?

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

Мне — нет. Но это специфика моих проектов, потому что они вообще не веб, а совсем другие.

Кваркус (https://quarkus.io) компилируется в натив уже очень давно, в коде при этом ничего править или добавлять не нужно.
Для того, чтобы собрать приложение (jax-rs, cdi, jpa) в натив уходит примерно 10 минут полной загрузки четырёхядерной машины и 8 гб памяти.
Стартует оно быстро, это правда. Но в процессе старта есть задачи, не связанные с инициализацией jvm — накатить liquibase, подцепиться к кафке и т.п., по ним очевидно нет выигрыша во времени. В потреблении памяти и ЦПУ принципиальных различий не замечено, что вполне естетственно.
Вообщем мы пока решили что овчинка выделки не стоит. Хотя всё это, конечно, интересно и т.п.
Вообще, по нашим наблюдениям, в обычном jvm режиме кваркус сравнимой функциональности стартует примерно в 5 (пять) раз быстрее спринг-бута при тех же ограничениях по железу.

В потреблении памяти и ЦПУ принципиальных различий не замечено, что вполне естетственно.

у меня кваркус с кафкой в нативном моде комфортно работает потребляя 15-20 мб памяти, а в жвм режиме порядка 200Мб

15-20 Мб RSS? Чё-то с трудом верится. Хотя всякое, конечно, бывает. На том сервисе, на котором я экспериментировал, он отъел плюс/минус столько же, сколько и в JVM режиме.

вот конфиг с кубера


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.

Sign up to leave a comment.

Articles