Accelera il tempo di avvio di Spring Boot

Ho un'applicazione Spring Boot. Ho aggiunto molte dipendenze (sfortunatamente, sembra che mi servano tutte) e il tempo di avvio è aumentato parecchio. Basta fare un SpringApplication.run(source, args)richiede 10 secondi.

Anche se potrebbe non essere molto rispetto a ciò a cui sono "abituato", non sono contento che ci voglia così tanto, soprattutto perché interrompe il flusso di sviluppo. L'applicazione stessa è piuttosto piccola a questo punto, quindi presumo che la maggior parte delle volte sia correlata alle dipendenze aggiunte, non alle classi dell'app stesse.

Presumo che il problema sia la scansione del percorso di classe, ma non sono sicuro di come:

• Conferma che è questo il problema (ad esempio, come eseguire il "debug" di Spring Boot)
• Se è davvero la causa, come posso limitarla, in modo che diventi più veloce? Ad esempio, se so che alcune dipendenze o pacchetti non contengono nulla che Spring dovrebbe sottoporre a scansione, c'è un modo per limitarlo?

Presumo che migliorare Spring per avere l'inizializzazione del bean parallelo durante l'avvio velocizzerebbe le cose, ma la richiesta di miglioramento è stata aperta dal 2011, senza alcun progresso. Vedo alcuni altri sforzi nello stesso Spring Boot, come i miglioramenti della velocità di Investigate Tomcat JarScanning , ma questo è specifico di Tomcat ed è stato abbandonato.

Questo articolo:

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

sebbene mirato a test di integrazione, suggerisce di utilizzare lazy-init=true , tuttavia non so come applicarlo a tutti i bean in Spring Boot utilizzando la configurazione Java - qualche puntatore qui?

Qualsiasi (altro) suggerimento sarebbe il benvenuto.

Spring Boot esegue molte operazioni di configurazione automatica che potrebbero non essere necessarie. Quindi potresti voler restringere solo la configurazione automatica necessaria per la tua app. Per vedere l'elenco completo delle configurazioni automatiche incluse, basta eseguire la registrazione org.springframework.boot.autoconfigurein modalità DEBUG ( logging.level.org.springframework.boot.autoconfigure=DEBUGin application.properties). Un'altra opzione è eseguire l'applicazione di avvio primaverile con l' --debugopzione:java -jar myproject-0.0.1-SNAPSHOT.jar --debug

Ci sarebbe qualcosa di simile nell'output:

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

Ispeziona questo elenco e includi solo le configurazioni automatiche necessarie:

@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 {

Il codice è stato copiato da questo post del blog .

La risposta più votata finora non è sbagliata, ma non va nella profondità che mi piace vedere e non fornisce prove scientifiche. Il team di Spring Boot ha svolto un esercizio per ridurre il tempo di avvio per Boot 2.0 e il ticket 11226 contiene molte informazioni utili. C'è anche un ticket 7939 aperto per aggiungere informazioni sui tempi per la valutazione delle condizioni, ma non sembra avere un ETA specifico.

L'approccio più utile e metodico per il debug dell'avvio di avvio è stato eseguito da Dave Syer. https://github.com/dsyer/spring-boot-startup-bench

Avevo anche un caso d'uso simile, quindi ho preso l'approccio di Dave al micro-benchmarking con JMH e l'ho seguito. Il risultato è il progetto boot benchmark . L'ho progettato in modo che possa essere utilizzato per misurare il tempo di avvio di qualsiasi applicazione Spring Boot, utilizzando il jar eseguibile prodotto da Gradle task bootJar(precedentemente chiamato bootRepackagein Boot 1.5). Sentiti libero di usarlo e di fornire feedback.

I miei risultati sono i seguenti:

1. La CPU è importante. Un sacco.
2. Avviare la JVM con -Xverify: nessuno aiuta in modo significativo.
3. L'esclusione di autoconfigurazioni non necessarie aiuta.
4. Dave ha consigliato l'argomento JVM -XX: TieredStopAtLevel = 1 , ma i miei test non hanno mostrato miglioramenti significativi con quello. Inoltre, -XX:TieredStopAtLevel=1probabilmente rallenterebbe la tua prima richiesta.
5. Ci sono state segnalazioni di lentezza nella risoluzione del nome host, ma non ho riscontrato che fosse un problema per le app che ho testato.

Spring Boot 2.2.M1 ha aggiunto funzionalità per supportare l'inizializzazione pigra in Spring Boot.

Per impostazione predefinita, quando un contesto dell'applicazione viene aggiornato, ogni bean nel contesto viene creato e le sue dipendenze vengono iniettate. Al contrario, quando una definizione di bean è configurata per essere inizializzata pigramente, non verrà creata e le sue dipendenze non verranno inserite finché non sarà necessario.

Abilitazione dell'inizializzazione lenta Impostare spring.main.lazy-initializationsu true

Quando abilitare l'inizializzazione pigra

l'inizializzazione pigra può offrire miglioramenti significativi nel tempo di avvio, ma ci sono anche alcuni svantaggi notevoli ed è importante abilitarlo con cura

Per maggiori dettagli, consultare Doc

Come descritto in questa domanda / risposta, penso che l'approccio migliore sia invece di aggiungere solo quelli di cui pensi di aver bisogno, escludere le dipendenze che sai di non aver bisogno.

Vedere: Ridurre al minimo il tempo di avvio di Spring Boot

In sintesi:

Puoi vedere cosa sta succedendo sotto le coperte e abilitare la registrazione del debug semplice come specificare --debug quando si avvia l'applicazione dalla riga di comando. È inoltre possibile specificare debug = true in application.properties.

Inoltre, puoi impostare il livello di registrazione in application.properties in modo semplice come:

logging.level.org.springframework.web: DEBUG logging.level.org.hibernate: ERRORE

Se rilevi un modulo configurato automaticamente che non desideri, può essere disabilitato. I documenti per questo sono disponibili qui: http://docs.spring.io/spring-boot/docs/current-SNAPSHOT/reference/htmlsingle/#using-boot-disabling-specific-auto-configuration

Un esempio potrebbe essere:

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

Bene, c'è l'intero elenco di possibili azioni descritte qui: https://spring.io/blog/2018/12/12/how-fast-is-spring

Metterò le note più importanti dal lato della primavera (aggiustate un po '):

• Esclusioni del percorso di classe dagli avviatori Web Spring Boot:
  • Validatore di ibernazione
  • Jackson (ma gli attuatori Spring Boot dipendono da questo). Usa Gson se hai bisogno del rendering JSON (funziona solo con MVC out of the box).
  • Logback: usa invece slf4j-jdk14
• Usa l'indicizzatore del contesto primaverile. Non aggiungerà molto, ma ogni piccolo aiuta.
• Non usare gli attuatori se puoi permetterti di non farlo.
• Usa Spring Boot 2.1 e Spring 5.1. Passa a 2.2 e 5.2 quando sono disponibili.
• Correggere la posizione dei file di configurazione di Spring Boot con spring.config.location(argomento della riga di comando o proprietà di sistema ecc.). Esempio per verificare in IDE: spring.config.location=file://./src/main/resources/application.properties.
• Disattiva JMX se non ne hai bisogno con spring.jmx.enabled=false(questa è l'impostazione predefinita in Spring Boot 2.2)
• Rendi pigre le definizioni dei bean per impostazione predefinita. C'è un nuovo flag spring.main.lazy-initialization=truein Spring Boot 2.2 (da usare LazyInitBeanFactoryPostProcessorper i precedenti Spring).
• Decomprimere il fat jar ed eseguire con un classpath esplicito.
• Esegui la JVM con -noverify. Considera anche -XX:TieredStopAtLevel=1(ciò rallenterà il JIT in seguito a scapito del tempo di avvio risparmiato).

Il menzionato LazyInitBeanFactoryPostProcessor(puoi usarlo per Spring 1.5 se non puoi applicare il flag spring.main.lazy-initialization=truedisponibile dalla 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);
      }
  }
}

Puoi anche usare (o scrivere il tuo - è semplice) qualcosa per analizzare il tempo di inizializzazione dei bean: https://github.com/lwaddicor/spring-startup-analysis

Spero che sia d'aiuto!

Nel mio caso, c'erano troppi punti di interruzione. Quando ho fatto clic su "Mute Breakpoints" e ho riavviato l'applicazione in modalità di debug, l'applicazione è stata avviata 10 volte più velocemente.

Se stai cercando di ottimizzare il turn-around dello sviluppo per i test manuali, consiglio vivamente l'uso di devtools .

Le applicazioni che usano spring-boot-devtools si riavvieranno automaticamente ogni volta che i file sul classpath cambiano.

Basta ricompilare e il server si riavvierà (per Groovy devi solo aggiornare il file sorgente). se stai usando un IDE (ad esempio 'vscode'), potrebbe compilare automaticamente i tuoi file java, quindi il semplice salvataggio di un file java può avviare un riavvio del server, indirettamente - e Java diventa altrettanto semplice come Groovy a questo proposito.

La bellezza di questo approccio è che il riavvio incrementale mette in cortocircuito alcuni dei passaggi di avvio da zero, quindi il tuo servizio sarà di nuovo attivo e funzionante molto più rapidamente!

Sfortunatamente, questo non aiuta con i tempi di avvio per la distribuzione o il test di unità automatizzato.

AVVERTENZA: se non utilizzi Hibernate DDL per la generazione automatica dello schema DB e non utilizzi la cache L2, questa risposta NON è applicabile a te. Scorri avanti.

La mia scoperta è che Hibernate aggiunge tempo significativo all'avvio dell'applicazione. La disabilitazione della cache L2 e dell'inizializzazione del database determina un avvio più rapido dell'app Spring Boot. Lascia la cache attiva per la produzione e disabilitala per il tuo ambiente di sviluppo.

application.yml:

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

Risultati del test:

1. La cache L2 è attiva e 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. La cache L2 è disattivata e 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)

Ora mi chiedo cosa farò di tutto questo tempo libero

Trovo strano che nessuno abbia suggerito prima queste ottimizzazioni. Ecco alcuni suggerimenti generali sull'ottimizzazione della creazione e dell'avvio del progetto durante lo sviluppo:

• escludere le directory di sviluppo dallo scanner antivirus:
  • directory del progetto
  • costruire la directory di output (se è al di fuori della directory del progetto)
  • Directory degli indici IDE (ad esempio ~ / .IntelliJIdea2018.3)
  • directory di distribuzione (webapp in Tomcat)
• aggiornare l'hardware. utilizzare CPU e RAM più veloci, una migliore connessione Internet (per scaricare le dipendenze) e una connessione al database, passare a SSD. una scheda video non ha importanza.

AVVERTENZE

1. la prima opzione arriva al prezzo di una sicurezza ridotta.
2. la seconda opzione costa denaro (ovviamente).

A me sembra che tu stia utilizzando un'impostazione di configurazione sbagliata. Inizia controllando myContainer e possibili conflitti. Per determinare chi sta usando la maggior parte delle risorse devi controllare le mappe di memoria (vedi la quantità di dati!) Per ogni dipendenza alla volta - e anche questo richiede molto tempo ... (e privilegi SUDO). A proposito: di solito stai testando il codice contro le dipendenze?