Прискорити час запуску весняного завантаження

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

Хоча це може бути не дуже порівняно з тим, до чого "звикли", я незадоволений тим, що це забирає стільки, в основному тому, що це порушує потік розвитку. Сам додаток на даний момент досить малий, тому я припускаю, що більша частина часу пов'язана з додатковими залежностями, а не самими класами програм.

Я припускаю, що проблема полягає в скануванні на уроці, але я не знаю, як:

• Підтвердьте, що це проблема (тобто як "налагодити" Spring Boot)
• Якщо це справді причина, то як я можу її обмежити, щоб вона стала швидшою? Наприклад, якщо я знаю, що якась залежність або пакет нічого не містить, що Spring повинен сканувати, чи є спосіб обмежити це?

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

Ця стаття:

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

Хоча націлений на інтеграційні тести, пропонує використовувати lazy-init=true, однак я не знаю, як застосувати це до всіх бобів у 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, відкритий для додавання інформації про терміни до оцінки стану, але, схоже, він не має конкретного еталону.

Найбільш корисним та методичним підходом для налагодження запуску Boot був здійснений Дейв Сайер. https://github.com/dsyer/spring-boot-startup-bench

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

Мої висновки такі:

1. Процесор має значення. Багато.
2. Починаючи JVM з -Xverify: жоден не допомагає суттєво.
3. Виключення непотрібних автоконфігурацій допомагає.
4. Дейв рекомендував аргумент JVM -XX: TieredStopAtLevel = 1 , але мої тести не показали значного покращення з цим. Також, -XX:TieredStopAtLevel=1ймовірно, сповільнить ваш перший запит.
5. Там було повідомлення про резолюцію імені хоста бути повільної, але я не знайшов , що це буде проблемою для додатків , які я тестував.

Spring Boot 2.2.M1 має додаткову функцію для підтримки лінивої ініціалізації у Spring Boot.

За замовчуванням, коли контекст програми оновлюється, кожен боб у контексті створюється та вводяться його залежності. Навпаки, коли визначення біна налаштовано на ліниву ініціалізацію, воно не створюватиметься і його залежності не будуть вводитись, поки це не потрібно.

Увімкнення значення "Ізольована ініціалізація" встановлено spring.main.lazy-initializationна " true"

Коли ввімкнути ліниву ініціалізацію, лінива ініціалізація може запропонувати значні покращення часу запуску, але є і деякі помітні недоліки, і важливо включити її обережно

Для отримання більш детальної інформації, будь ласка, перевірте Док

Як описано в цьому запитанні / відповіді, я думаю, що найкращим підходом є замість того, щоб додавати лише ті, які, на вашу думку, потрібні, виключати залежності, які ви знаєте, що вам не потрібно.

Дивіться: Мінімізуйте час запуску весняного завантаження

Підсумовуючи:

Ви можете бачити, що відбувається під кришками, і ввімкнути журнал налагодження так само просто, як і вказати --debug при запуску програми з командного рядка. Ви також можете вказати налагодження = true у своїй програмі.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-disabling-specific-auto-configuration

Приклад виглядає так:

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

Добре є весь список можливих дій, описаних тут: https://spring.io/blog/2018/12/12/how-fast-is-spring

Я поставлю найважливіші нотатки з весняного боку (трохи коригується):

• Винятки з Classpath з веб-пускачів Spring Boot:
  • Перевірка в сплячку
  • Джексон (але від цього залежать виконавчі механізми Spring Boot). Використовуйте Gson, якщо вам потрібна візуалізація JSON (працює лише з MVC поза коробкою).
  • Зворотний зв'язок: замість цього використовуйте slf4j-jdk14
• Використовуйте індекс-показник весна-контекст. Це не додасть багато, але кожен маленький допомагає.
• Не використовуйте пускачі, якщо ви не можете собі цього дозволити.
• Використовуйте Spring Boot 2.1 та Spring 5.1. Перейдіть на 2.2 та 5.2, коли вони доступні.
• Виправте розташування конфігураційних файлів Spring Boot за допомогою spring.config.location(аргумент командного рядка або властивість системи тощо). Приклад тестування в IDE:spring.config.location=file://./src/main/resources/application.properties .
• Вимкніть JMX, якщо він вам не потрібен spring.jmx.enabled=false(це значення за замовчуванням у Spring Boot 2.2)
• Зробіть визначення квасолі ледачими за замовчуванням. У 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);
      }
  }
}

Ви також можете використовувати (або написати своє - це просто) щось, щоб проаналізувати час ініціалізації бобів: https://github.com/lwaddicor/spring-startup-analysis

Сподіваюся, це допомагає!

У моєму випадку було дуже багато точок прориву. Коли я натиснув "Mute Breakpoints" і перезапустив програму в режимі налагодження, додаток запустилося в 10 разів швидше.

Якщо ви намагаєтеся оптимізувати розгортання розробки для ручного тестування, я настійно рекомендую використовувати devtools .

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

Просто перекомпілюйте - і сервер перезавантажиться (для 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). До речі: ти зазвичай тестуєш код на залежність?