У меня есть приложение Spring Boot. Я добавил много зависимостей (к сожалению, похоже, все они мне нужны), и время запуска значительно увеличилось. Просто выполнение SpringApplication.run(source, args)
занимает 10 секунд.
Хотя это может быть немного по сравнению с тем, к чему «привыкли», я недоволен тем, что это занимает так много времени, в основном потому, что это нарушает процесс разработки. Само приложение на данный момент довольно мало, поэтому я предполагаю, что большую часть времени он связан с добавленными зависимостями, а не с самими классами приложения.
Я предполагаю, что проблема заключается в сканировании пути к классам, но я не знаю, как:
- Подтвердите, что это проблема (например, как «отладить» Spring Boot)
- Если это действительно причина, как я могу ее ограничить, чтобы она стала быстрее? Например, если я знаю, что какая-то зависимость или пакет не содержат ничего, что Spring должен сканировать, есть ли способ ограничить это?
Я предполагаю, что расширение Spring для параллельной инициализации bean-компонентов во время запуска ускорит процесс, но этот запрос на улучшение был открыт с 2011 года, без какого-либо прогресса. Я вижу некоторые другие усилия в самой Spring Boot, такие как Исследование улучшений скорости Tomcat JarScanning , но это специфично для Tomcat, и от него отказались.
Эта статья:
хотя и нацелен на интеграционные тесты, предлагает использовать lazy-init=true
, однако я не знаю, как применить это ко всем bean-компонентам в Spring Boot с использованием конфигурации Java - здесь есть указатели?
Любые (другие) предложения приветствуются.
источник
@ComponentScan
них, также будут сканироваться. Другое дело - убедиться, что вы не включили отладку или ведение журнала трассировки, поскольку обычно ведение журнала происходит медленно, очень медленно.Ответы:
Spring Boot выполняет множество автоматических настроек, которые могут не понадобиться. Поэтому вы можете сузить круг автоконфигурации, которая необходима вашему приложению. Чтобы увидеть полный список включенных автоконфигураций, просто запустите логирование
org.springframework.boot.autoconfigure
в режиме DEBUG (logging.level.org.springframework.boot.autoconfigure=DEBUG
inapplication.properties
). Другой вариант - запустить приложение весенней загрузки с--debug
опцией:java -jar myproject-0.0.1-SNAPSHOT.jar --debug
На выходе будет что-то вроде этого:
Изучите этот список и включите только необходимые автоконфигурации:
Код был скопирован из этого сообщения в блоге .
источник
Ответ, получивший наибольшее количество голосов до сих пор, не является неправильным, но он не входит в ту глубину, которую я хотел бы видеть, и не содержит научных доказательств. Команда 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. Не стесняйтесь использовать его и оставлять отзывы.Мои выводы таковы:
-XX:TieredStopAtLevel=1
вероятно, замедлит ваш первый запрос.источник
minimal
, или баночка может быть просто поставлена? Я попытался сделать первое, но не продвинулся далеко.-Xverify:none
в производственной среде, поскольку это нарушает проверку кода, и вы можете столкнуться с проблемами.-XX:TieredStopAtLevel=1
в порядке, если вы запускаете приложение в течение небольшого времени (несколько секунд), в противном случае оно будет менее продуктивным, так как обеспечит JVM длительной оптимизацией.Use of -Xverify:none is unsupported.
что это значит?В 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
Пример мог бы выглядеть так:
источник
Вот полный список возможных действий, описанных здесь: https://spring.io/blog/2018/12/12/how-fast-is-spring
Я поставлю самые важные замечания со стороны Spring (немного скорректировано):
spring.config.location
(аргумент командной строки или свойство System и т. Д.). Пример для тестирования в IDE:spring.config.location=file://./src/main/resources/application.properties
.spring.jmx.enabled=false
(это значение по умолчанию в Spring Boot 2.2)spring.main.lazy-initialization=true
Spring Boot 2.2 появился новый флаг (используетсяLazyInitBeanFactoryPostProcessor
для более старых версий Spring).-noverify
. Также учтите-XX:TieredStopAtLevel=1
(это замедлит JIT позже за счет сэкономленного времени запуска).Упомянутое
LazyInitBeanFactoryPostProcessor
(вы можете использовать его для Spring 1.5, если вы не можете применить флаг,spring.main.lazy-initialization=true
доступный из Spring 2.2):Вы также можете использовать (или написать свое собственное - это просто) что-нибудь для анализа времени инициализации beans: https://github.com/lwaddicor/spring-startup-analysis
Надеюсь, поможет!
источник
В моем случае было слишком много точек останова. Когда я нажал кнопку «Mute Breakpoints» и перезапустил приложение в режиме отладки, приложение запустилось в 10 раз быстрее.
источник
Если вы пытаетесь оптимизировать цикл разработки для ручного тестирования, я настоятельно рекомендую использовать инструменты разработчика .
Просто перекомпилируйте - и сервер перезапустится (для Groovy вам нужно только обновить исходный файл). если вы используете IDE (например, vscode), она может автоматически компилировать ваши java-файлы, поэтому простое сохранение java-файла может косвенно инициировать перезапуск сервера - и в этом отношении Java становится такой же простой, как Groovy.
Прелесть этого подхода в том, что инкрементный перезапуск сокращает некоторые этапы запуска с нуля, поэтому ваша служба будет восстановлена и запущена намного быстрее!
К сожалению, это не помогает сократить время запуска для развертывания или автоматического модульного тестирования.
источник
ПРЕДУПРЕЖДЕНИЕ: Если вы не используете Hibernate DDL для автоматического создания схемы БД и не используете кеш L2, этот ответ к вам НЕ применим. Прокрутите вперед.
Я пришел к выводу, что Hibernate значительно увеличивает время запуска приложения. Отключение кеша L2 и инициализации базы данных приводит к более быстрому запуску приложения Spring Boot. Оставьте кеш включенным для производства и отключите его для своей среды разработки.
application.yml:
Результаты теста:
Кэш L2 включен и
ddl-auto: update
Кэш L2 выключен и
ddl-auto: none
Теперь мне интересно, что я буду делать со всем этим свободным временем
источник
Мне кажется странным, что раньше никто не предлагал эту оптимизацию. Вот несколько общих советов по оптимизации сборки проекта и запуска при разработке:
ПРЕДУПРЕЖДЕНИЯ
источник
Мне кажется, что вы используете неправильную настройку конфигурации. Начните с проверки myContainer и возможных конфликтов. Чтобы определить, кто использует больше всего ресурсов, вам нужно проверить карты памяти (увидеть объем данных!) Для каждой зависимости за раз - а это также занимает много времени ... (и привилегии SUDO). Кстати: вы обычно тестируете код на зависимости?
источник