Сравнение инструментов ускорения Java сервиса

Сравнение инструментов ускорения Java сервиса

Den

Всем привет!

Итоговый пост - сравнение разных способов ускорения Java. Сравнение по покрываемому функционалу и потенциальным недостаткам (drawback). За точку отсчета берем Java Spring Boot приложение.

Видно, что native image и CRaC "бьют по площадям" - в итоге мы получаем оптимизированный образ приложения, готовый для запуска. В случае native image - в бинарный код переведено все, в случае CRaC - только то, что решил перевести JIT компилятор.

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

Теперь про подводные камни.

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

CRaC, профилирование и CDS требует время на "обучение" - сбор статистики использования классов и кода. Кроме того, если условия обучения не 100% совпадут с условиями на ПРОМ - ожидаемого эффекта ускорения не будет. Указал в таблице как плюс-минус, т.к приложение не упадет, а просто будет работать медленнее.

Хранение jar в распакованном виде никак не влияет на приложение за исключением немного более сложной процедуры сборки.

У Micronaut и Quarkus одинаковые подводные камни в виде чуть более медленной сборки (не так драматично медленной, как native image) и меньше функционала "из коробки".

Надеюсь таблички помогут сделать вам выбор.



Report Page