Ускорение запуска Spring Boot

У меня есть приложение Spring Boot. Я добавил много зависимостей (к сожалению, похоже, все они мне нужны), и время запуска значительно увеличилось. Просто выполнение SpringApplication.run(source, args)занимает 10 секунд.

Хотя это может быть немного по сравнению с тем, к чему «привыкли», я недоволен тем, что это занимает так много времени, в основном потому, что это нарушает процесс разработки. Само приложение на данный момент довольно мало, поэтому я предполагаю, что большую часть времени он связан с добавленными зависимостями, а не с самими классами приложения.

Я предполагаю, что проблема заключается в сканировании пути к классам, но я не знаю, как:

• Подтвердите, что это проблема (например, как «отладить» Spring Boot)
• Если это действительно причина, как я могу ее ограничить, чтобы она стала быстрее? Например, если я знаю, что какая-то зависимость или пакет не содержат ничего, что Spring должен сканировать, есть ли способ ограничить это?

Я предполагаю, что расширение Spring для параллельной инициализации bean-компонентов во время запуска ускорит процесс, но этот запрос на улучшение был открыт с 2011 года, без какого-либо прогресса. Я вижу некоторые другие усилия в самой Spring Boot, такие как Исследование улучшений скорости Tomcat JarScanning , но это специфично для Tomcat, и от него отказались.

Эта статья:

• http://www.nurkiewicz.com/2010/12/speeding-up-spring-integration-tests.html

хотя и нацелен на интеграционные тесты, предлагает использовать lazy-init=true, однако я не знаю, как применить это ко всем bean-компонентам в Spring Boot с использованием конфигурации Java - здесь есть указатели?

Любые (другие) предложения приветствуются.

Spring Boot выполняет множество автоматических настроек, которые могут не понадобиться. Поэтому вы можете сузить круг автоконфигурации, которая необходима вашему приложению. Чтобы увидеть полный список включенных автоконфигураций, просто запустите логирование org.springframework.boot.autoconfigureв режиме DEBUG ( logging.level.org.springframework.boot.autoconfigure=DEBUGin application.properties). Другой вариант - запустить приложение весенней загрузки с --debugопцией:java -jar myproject-0.0.1-SNAPSHOT.jar --debug

На выходе будет что-то вроде этого:

=========================
AUTO-CONFIGURATION REPORT
=========================

Изучите этот список и включите только необходимые автоконфигурации:

@Configuration
@Import({
        DispatcherServletAutoConfiguration.class,
        EmbeddedServletContainerAutoConfiguration.class,
        ErrorMvcAutoConfiguration.class,
        HttpEncodingAutoConfiguration.class,
        HttpMessageConvertersAutoConfiguration.class,
        JacksonAutoConfiguration.class,
        ServerPropertiesAutoConfiguration.class,
        PropertyPlaceholderAutoConfiguration.class,
        ThymeleafAutoConfiguration.class,
        WebMvcAutoConfiguration.class,
        WebSocketAutoConfiguration.class,
})
public class SampleWebUiApplication {

Код был скопирован из этого сообщения в блоге .

Ответ, получивший наибольшее количество голосов до сих пор, не является неправильным, но он не входит в ту глубину, которую я хотел бы видеть, и не содержит научных доказательств. Команда Spring Boot выполнила упражнение по сокращению времени запуска для Boot 2.0, и билет 11226 содержит много полезной информации. Также есть билет 7939 открытый для добавления информации о времени для оценки состояния, но, похоже, он не имеет конкретного ETA.

Самый полезный и методичный подход к отладке запуска Boot принадлежит Дэйву Сайеру. https://github.com/dsyer/spring-boot-startup-bench

У меня тоже был аналогичный вариант использования, поэтому я взял подход Дейва к микротестированию с JMH и начал использовать его. Результатом является проект загрузочного тестирования . Я разработал его таким образом, чтобы его можно было использовать для измерения времени запуска любого приложения Spring Boot, используя исполняемый файл jar, созданный bootJar(ранее называвшийсяbootRepackage в Boot 1.5) задачей Gradle. Не стесняйтесь использовать его и оставлять отзывы.

Мои выводы таковы:

1. ЦП имеет значение. Много.
2. Запуск JVM с -Xverify: none существенно помогает.
3. Помогает исключение ненужных автоконфигураций.
4. Дэйв рекомендовал аргумент JVM -XX: TieredStopAtLevel = 1 , но мои тесты не показали значительного улучшения с этим. Кроме того, -XX:TieredStopAtLevel=1вероятно, замедлит ваш первый запрос.
5. Были сообщения о медленном разрешении имени хоста, но я не обнаружил, что это проблема для тестируемых приложений.

В Spring Boot 2.2.M1 добавлена ​​функция поддержки отложенной инициализации в Spring Boot.

По умолчанию при обновлении контекста приложения создается каждый компонент в контексте и внедряются его зависимости. Напротив, когда определение bean-компонента настроено на ленивую инициализацию, оно не будет создано, и его зависимости не будут внедряться до тех пор, пока они не понадобятся.

Включение ленивой инициализации Установите spring.main.lazy-initializationзначение true

Когда включать ленивую инициализацию

ленивая инициализация может значительно сократить время запуска, но есть и некоторые заметные недостатки, и важно включить ее с осторожностью

Для получения дополнительной информации, пожалуйста, проверьте документ

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

См .: Минимизация времени запуска Spring Boot

В итоге:

Вы можете увидеть, что происходит под обложками, и включить ведение журнала отладки, просто указав --debug при запуске приложения из командной строки. Вы также можете указать debug = true в своем application.properties.

Кроме того, вы можете установить уровень ведения журнала в application.properties очень просто:

logging.level.org.springframework.web: DEBUG logging.level.org.hibernate: ОШИБКА

Если вы обнаружите автоматически настроенный модуль, который вам не нужен, его можно отключить. Документацию по этому поводу можно найти здесь: http://docs.spring.io/spring-boot/docs/current-SNAPSHOT/reference/htmlsingle/#using-boot-disables-specific-auto-configuration

Пример мог бы выглядеть так:

@Configuration
@EnableAutoConfiguration(exclude={DataSourceAutoConfiguration.class})
public class MyConfiguration {
}

Вот полный список возможных действий, описанных здесь: https://spring.io/blog/2018/12/12/how-fast-is-spring

Я поставлю самые важные замечания со стороны Spring (немного скорректировано):

• Исключения пути к классам из веб-стартеров Spring Boot:
  • Валидатор гибернации
  • Джексон (но от этого зависят приводы Spring Boot). Используйте Gson, если вам нужен рендеринг JSON (работает только с MVC из коробки).
  • Возврат: вместо этого используйте slf4j-jdk14
• Используйте spring-context-indexer. Это не добавит многого, но каждая мелочь помогает.
• Не используйте приводы, если вы можете себе это позволить.
• Используйте Spring Boot 2.1 и Spring 5.1. Переключитесь на 2.2 и 5.2, когда они доступны.
• Исправьте расположение файлов конфигурации Spring Boot с помощью spring.config.location(аргумент командной строки или свойство System и т. Д.). Пример для тестирования в IDE: spring.config.location=file://./src/main/resources/application.properties.
• Отключите JMX, если он вам не нужен spring.jmx.enabled=false(это значение по умолчанию в Spring Boot 2.2)
• По умолчанию делает определения bean-компонентов ленивыми. В spring.main.lazy-initialization=trueSpring Boot 2.2 появился новый флаг (используется LazyInitBeanFactoryPostProcessorдля более старых версий Spring).
• Распакуйте толстую банку и запустите с явным путем к классам.
• Запустите JVM с помощью -noverify. Также учтите -XX:TieredStopAtLevel=1(это замедлит JIT позже за счет сэкономленного времени запуска).

Упомянутое LazyInitBeanFactoryPostProcessor(вы можете использовать его для Spring 1.5, если вы не можете применить флаг, spring.main.lazy-initialization=trueдоступный из Spring 2.2):

public class LazyInitBeanFactoryPostProcessor implements BeanFactoryPostProcessor {

  @Override
  public void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) {
      for (String beanName : beanFactory.getBeanDefinitionNames()) {
        BeanDefinition definition = beanFactory.getBeanDefinition(beanName);
        definition.setLazyInit(true);
      }
  }
}

Вы также можете использовать (или написать свое собственное - это просто) что-нибудь для анализа времени инициализации beans: https://github.com/lwaddicor/spring-startup-analysis

Надеюсь, поможет!

В моем случае было слишком много точек останова. Когда я нажал кнопку «Mute Breakpoints» и перезапустил приложение в режиме отладки, приложение запустилось в 10 раз быстрее.

Если вы пытаетесь оптимизировать цикл разработки для ручного тестирования, я настоятельно рекомендую использовать инструменты разработчика .

Приложения, использующие spring-boot-devtools, будут автоматически перезапускаться при изменении файлов в пути к классам.

Просто перекомпилируйте - и сервер перезапустится (для Groovy вам нужно только обновить исходный файл). если вы используете IDE (например, vscode), она может автоматически компилировать ваши java-файлы, поэтому простое сохранение java-файла может косвенно инициировать перезапуск сервера - и в этом отношении Java становится такой же простой, как Groovy.

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

К сожалению, это не помогает сократить время запуска для развертывания или автоматического модульного тестирования.

ПРЕДУПРЕЖДЕНИЕ: Если вы не используете Hibernate DDL для автоматического создания схемы БД и не используете кеш L2, этот ответ к вам НЕ применим. Прокрутите вперед.

Я пришел к выводу, что Hibernate значительно увеличивает время запуска приложения. Отключение кеша L2 и инициализации базы данных приводит к более быстрому запуску приложения Spring Boot. Оставьте кеш включенным для производства и отключите его для своей среды разработки.

application.yml:

spring:
  jpa:
    generate-ddl: false
    hibernate:
      ddl-auto: none
    properties:
      hibernate:
        cache:
          use_second_level_cache: false
          use_query_cache: false

Результаты теста:

1. Кэш L2 включен и ddl-auto: update

   INFO 5024 --- [restartedMain] o.s.web.context.ContextLoader : Root WebApplicationContext: initialization completed in 23331 ms
   INFO 5024 --- [restartedMain] b.n.spring.Application : Started Application in 54.251 seconds (JVM running for 63.766)

2. Кэш L2 выключен и ddl-auto: none

   INFO 10288 --- [restartedMain] o.s.web.context.ContextLoader : Root WebApplicationContext: initialization completed in 9863 ms
   INFO 10288 --- [restartedMain] b.n.spring.Application : Started Application in 32.058 seconds (JVM running for 37.625)

Теперь мне интересно, что я буду делать со всем этим свободным временем

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

• исключить каталоги разработки из антивирусного сканера:
  • каталог проекта
  • выходной каталог сборки (если он находится вне каталога проекта)
  • Каталог индексов IDE (например, ~ / .IntelliJIdea2018.3)
  • каталог развертывания (веб-приложения в Tomcat)
• обновить оборудование. используйте более быстрый процессор и оперативную память, лучшее подключение к Интернету (для загрузки зависимостей) и подключение к базе данных, переключитесь на SSD. видеокарта не имеет значения.

ПРЕДУПРЕЖДЕНИЯ

1. первый вариант обходится ценой снижения безопасности.
2. второй вариант стоит денег (очевидно).

Мне кажется, что вы используете неправильную настройку конфигурации. Начните с проверки myContainer и возможных конфликтов. Чтобы определить, кто использует больше всего ресурсов, вам нужно проверить карты памяти (увидеть объем данных!) Для каждой зависимости за раз - а это также занимает много времени ... (и привилегии SUDO). Кстати: вы обычно тестируете код на зависимости?