У нас профили вообще не сохраняются. После каждого запуска новый под заново вызывает свои методы и прогревается с нуля. Поэтому при обновлении он автоматически прогревает уже новую версию кода.
Java 17, G1 GC. Специально Code Cache и параметры JIT мы не настраивали, использовали стандартную tiered-компиляцию. С interpreter отдельно тоже не боролись: прогрев просто заранее проводит горячие пути через обычный цикл интерпретации и JIT. Тюнинг JVM мог бы помочь, но у нас грелись ещё Spring, прокси, сериализация, соединения и кэши, поэтому выбрали прикладной прогрев.
Спасибо, очень в тему! И ничего себе, завести тикет и сразу подготовить PR в Spring Framework, Boot и Buildpacks, это мощно!
У нас Java 17 в основном, поэтому JEP 515 на момент решения не рассматривали. В JDK 25 это действительно интересный вариант. Но наш прогрев затрагивает ещё Spring, сериализацию, соединения и кэши, поэтому я бы сравнивал Leyden отдельно и вместе с коротким HTTP-прогревом. А генерация кэша из интеграционных тестов выглядит логично, особенно если они хорошо покрывают реальные сценарии.
Используем только сценарии без бизнес-записи. Есть один POST, но он лишь принимает сложное тело запроса и ничего не изменяет. Операции с начислениями, статусами и событиями в прогрев не включаем. Для изменяющих операций понадобился бы отдельный dry-run или тестовый контур данных, у нас такой необходимости пока не было.
Выкатка стала дольше?
Да, немного. Но пока новый pod прогревается, трафик продолжают обслуживать старые. В итоге выкладка длится чуть дольше, зато пользователи не попадают на холодный сервис.
А на Go быстрее?
Кажется, что да, в Go нет JIT-компиляции во время работы. Но соединения, кэши и внешние клиенты всё равно могут прогреваться, поэтому полностью холодный старт не исчезает.
У нас профили вообще не сохраняются. После каждого запуска новый под заново вызывает свои методы и прогревается с нуля. Поэтому при обновлении он автоматически прогревает уже новую версию кода.
Доброй ночи!
Java 17, G1 GC. Специально Code Cache и параметры JIT мы не настраивали, использовали стандартную tiered-компиляцию. С interpreter отдельно тоже не боролись: прогрев просто заранее проводит горячие пути через обычный цикл интерпретации и JIT. Тюнинг JVM мог бы помочь, но у нас грелись ещё Spring, прокси, сериализация, соединения и кэши, поэтому выбрали прикладной прогрев.
Спасибо, очень в тему! И ничего себе, завести тикет и сразу подготовить PR в Spring Framework, Boot и Buildpacks, это мощно!
У нас Java 17 в основном, поэтому JEP 515 на момент решения не рассматривали. В JDK 25 это действительно интересный вариант. Но наш прогрев затрагивает ещё Spring, сериализацию, соединения и кэши, поэтому я бы сравнивал Leyden отдельно и вместе с коротким HTTP-прогревом. А генерация кэша из интеграционных тестов выглядит логично, особенно если они хорошо покрывают реальные сценарии.
Только чтение или есть изменения?
Выкатка стала дольше?
А на Go быстрее?