Beschleunigen Sie die Startzeit von Spring Boot

Ich habe eine Spring Boot-Anwendung. Ich habe viele Abhängigkeiten hinzugefügt (leider brauche ich alle) und die Startzeit ist ziemlich hoch. Nur ein SpringApplication.run(source, args)dauert 10 Sekunden.

Das ist zwar nicht viel im Vergleich zu dem, was "gewohnt" ist, aber ich bin unglücklich, dass es so viel kostet, vor allem, weil es den Entwicklungsfluss unterbricht. Die Anwendung selbst ist zu diesem Zeitpunkt eher klein, daher gehe ich davon aus, dass die meiste Zeit mit den hinzugefügten Abhängigkeiten zusammenhängt, nicht mit den App-Klassen selbst.

Ich gehe davon aus, dass das Problem das Scannen von Klassenpfaden ist, bin mir aber nicht sicher, wie:

• Bestätigen Sie, dass dies das Problem ist (dh wie Sie Spring Boot "debuggen").
• Wenn es wirklich die Ursache ist, wie kann ich es begrenzen, damit es schneller wird? Wenn ich zum Beispiel weiß, dass eine Abhängigkeit oder ein Paket nichts enthält, was Spring scannen sollte, gibt es eine Möglichkeit, dies einzuschränken?

Ich gehe davon aus, dass die Erweiterung von Spring auf eine parallele Bean-Initialisierung während des Startvorgangs die Dinge beschleunigen würde, aber diese Erweiterungsanforderung ist seit 2011 ohne Fortschritte geöffnet. Ich sehe einige andere Bemühungen in Spring Boot selbst, wie z. B. die Verbesserung der Geschwindigkeit von Tomcat JarScanning untersuchen , aber das ist Tomcat-spezifisch und wurde aufgegeben.

Dieser Beitrag:

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

Obwohl auf Integrationstests ausgerichtet, schlägt die Verwendung vor lazy-init=true , aber ich weiß nicht, wie ich dies auf alle Beans in Spring Boot unter Verwendung der Java-Konfiguration anwenden soll - irgendwelche Hinweise hier?

Alle (anderen) Vorschläge wären willkommen.

Spring Boot führt viele automatische Konfigurationen durch, die möglicherweise nicht benötigt werden. Daher möchten Sie möglicherweise nur die für Ihre App erforderliche automatische Konfiguration eingrenzen. Um die vollständige Liste der enthaltenen automatischen Konfigurationen anzuzeigen, führen Sie einfach die Protokollierung org.springframework.boot.autoconfigureim DEBUG-Modus ( logging.level.org.springframework.boot.autoconfigure=DEBUGin application.properties) aus. Eine weitere Option ist das Ausführen der Spring Boot-Anwendung mit der folgenden --debugOption:java -jar myproject-0.0.1-SNAPSHOT.jar --debug

Es würde so etwas in der Ausgabe geben:

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

Überprüfen Sie diese Liste und geben Sie nur die erforderlichen Autokonfigurationen an:

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

Code wurde aus diesem Blog-Beitrag kopiert .

Die bisher am häufigsten gewählte Antwort ist nicht falsch, geht aber nicht in die Tiefe, die ich gerne sehe, und liefert keine wissenschaftlichen Beweise. Das Spring Boot-Team hat eine Übung zur Verkürzung der Startzeit für Boot 2.0 durchgeführt, und Ticket 11226 enthält viele nützliche Informationen. Es gibt auch ein Ticket 7939, das zum Hinzufügen von Zeitinformationen zur Zustandsbewertung geöffnet ist, aber es scheint keine spezifische ETA zu haben.

Der nützlichste und methodischste Ansatz zum Debuggen des Boot-Starts wurde von Dave Syer durchgeführt. https://github.com/dsyer/spring-boot-startup-bench

Ich hatte auch einen ähnlichen Anwendungsfall, also nahm ich Daves Ansatz des Mikro-Benchmarking mit JMH und lief damit. Das Ergebnis ist das Boot-Benchmark- Projekt. Ich habe es so konzipiert, dass es zum Messen der Startzeit für jede Spring Boot-Anwendung verwendet werden kann, indem das ausführbare JAR verwendet wird, das von der Gradle-Task bootJar(zuvor bootRepackagein Boot 1.5 genannt) erstellt wurde. Fühlen Sie sich frei, es zu verwenden und Feedback zu geben.

Meine Ergebnisse sind wie folgt:

1. CPU ist wichtig. Viel.
2. Starten der JVM mit -Xverify: Keine hilft wesentlich.
3. Das Ausschließen unnötiger Autokonfigurationen hilft.
4. Dave empfahl das JVM-Argument -XX: TieredStopAtLevel = 1 , aber meine Tests zeigten keine signifikante Verbesserung. Auch -XX:TieredStopAtLevel=1würde wahrscheinlich Ihre erste Anfrage verlangsamen.
5. Es wurde berichtet, dass die Auflösung von Hostnamen langsam ist, aber ich fand es nicht problematisch für die von mir getesteten Apps.

Spring Boot 2.2.M1 hat eine Funktion hinzugefügt, die die verzögerte Initialisierung in Spring Boot unterstützt.

Wenn ein Anwendungskontext aktualisiert wird, wird standardmäßig jede Bean im Kontext erstellt und ihre Abhängigkeiten eingefügt. Im Gegensatz dazu wird eine Bean-Definition, die so konfiguriert ist, dass sie träge initialisiert wird, nicht erstellt und ihre Abhängigkeiten werden erst eingefügt, wenn sie benötigt werden.

Aktivieren Verzögerte Initialisierung Set spring.main.lazy-initializationzu wahren

Wann die verzögerte Initialisierung aktiviert werden kann Die verzögerte Initialisierung kann die Startzeit erheblich verbessern, es gibt jedoch auch einige bemerkenswerte Nachteile, und es ist wichtig, sie sorgfältig zu aktivieren

Weitere Informationen finden Sie in Doc

Wie in dieser Frage / Antwort beschrieben, ist es meiner Meinung nach der beste Ansatz, anstatt nur diejenigen hinzuzufügen, die Sie für nötig halten, die Abhängigkeiten auszuschließen, von denen Sie wissen, dass Sie sie nicht benötigen.

Siehe: Startzeit des Spring Boot minimieren

Zusammenfassend:

Sie können sehen, was unter der Decke vor sich geht, und die Debug-Protokollierung aktivieren, indem Sie einfach --debug angeben, wenn Sie die Anwendung über die Befehlszeile starten. Sie können debug = true auch in Ihrer application.properties angeben.

Sie können die Protokollierungsstufe in application.properties auch so einfach festlegen wie:

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

Wenn Sie ein automatisch konfiguriertes Modul erkennen, das Sie nicht möchten, kann es deaktiviert werden. Die Dokumente dazu finden Sie hier: http://docs.spring.io/spring-boot/docs/current-SNAPSHOT/reference/htmlsingle/#using-boot-disabling-specific-auto-configuration

Ein Beispiel würde aussehen wie:

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

Nun, es gibt eine vollständige Liste möglicher Aktionen, die hier beschrieben werden: https://spring.io/blog/2018/12/12/how-fast-is-spring

Ich werde die wichtigsten Noten von der Frühlingsseite setzen (ein wenig angepasst):

• Klassenpfadausschlüsse von Spring Boot-Webstartern:
  • Validator für den Ruhezustand
  • Jackson (aber Spring Boot-Aktuatoren hängen davon ab). Verwenden Sie Gson, wenn Sie JSON-Rendering benötigen (funktioniert nur mit MVC ab Werk).
  • Logback: Verwenden Sie stattdessen slf4j-jdk14
• Verwenden Sie den Spring-Context-Indexer. Es wird nicht viel hinzufügen, aber jedes bisschen hilft.
• Verwenden Sie keine Aktuatoren, wenn Sie es sich leisten können, dies nicht zu tun.
• Verwenden Sie Spring Boot 2.1 und Spring 5.1. Wechseln Sie zu 2.2 und 5.2, wenn sie verfügbar sind.
• Korrigieren Sie den Speicherort der Spring Boot-Konfigurationsdatei (en) mit spring.config.location(Befehlszeilenargument oder Systemeigenschaft usw.). Beispiel zum Testen in IDE : spring.config.location=file://./src/main/resources/application.properties.
• Schalten Sie JMX aus, wenn Sie es nicht benötigen spring.jmx.enabled=false(dies ist die Standardeinstellung in Spring Boot 2.2).
• Machen Sie Bean-Definitionen standardmäßig faul. spring.main.lazy-initialization=trueIn Spring Boot 2.2 gibt es eine neue Flagge ( LazyInitBeanFactoryPostProcessorfür ältere Spring verwenden).
• Packen Sie das fette Glas aus und führen Sie es mit einem expliziten Klassenpfad aus.
• Führen Sie die JVM mit aus -noverify. Berücksichtigen Sie auch -XX:TieredStopAtLevel=1(dies verlangsamt die JIT später auf Kosten der gespeicherten Startzeit).

Die genannten LazyInitBeanFactoryPostProcessor(Sie können es für Spring 1.5 verwenden, wenn Sie das spring.main.lazy-initialization=trueab Spring 2.2 verfügbare Flag nicht anwenden können ):

public class LazyInitBeanFactoryPostProcessor implements BeanFactoryPostProcessor {

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

Sie können auch etwas verwenden (oder Ihr eigenes schreiben - es ist einfach), um die Initialisierungszeit von Beans zu analysieren: https://github.com/lwaddicor/spring-startup-analysis

Ich hoffe es hilft!

In meinem Fall gab es zu viele Haltepunkte. Als ich auf "Haltepunkte stumm schalten" klickte und die Anwendung im Debug-Modus neu startete, wurde die Anwendung zehnmal schneller gestartet.

Wenn Sie versuchen, die Entwicklungsabwicklung für manuelle Tests zu optimieren, empfehle ich dringend die Verwendung von devtools .

Anwendungen, die spring-boot-devtools verwenden, werden automatisch neu gestartet, wenn sich Dateien im Klassenpfad ändern.

Einfach neu kompilieren - und der Server startet sich selbst neu (für Groovy müssen Sie nur die Quelldatei aktualisieren). Wenn Sie eine IDE verwenden (z. B. 'vscode'), werden Ihre Java-Dateien möglicherweise automatisch kompiliert. Wenn Sie also nur eine Java-Datei speichern, kann indirekt ein Neustart des Servers eingeleitet werden - und Java wird in dieser Hinsicht genauso nahtlos wie Groovy.

Das Schöne an diesem Ansatz ist, dass der inkrementelle Neustart einige der Startschritte von Grund auf kurzschließt - so dass Ihr Dienst viel schneller wieder betriebsbereit ist!

Leider hilft dies nicht bei Startzeiten für die Bereitstellung oder automatisierten Komponententests.

WARNUNG: Wenn Sie Hibernate DDL nicht für die automatische Generierung von DB-Schemas verwenden und keinen L2-Cache verwenden, gilt diese Antwort NICHT für Sie. Scrollen Sie weiter.

Mein Ergebnis ist, dass der Ruhezustand den Start der Anwendung erheblich verlängert. Das Deaktivieren der L2-Cache- und Datenbankinitialisierung führt zu einem schnelleren Start der Spring Boot-App. Lassen Sie den Cache für die Produktion eingeschaltet und deaktivieren Sie ihn für Ihre Entwicklungsumgebung.

application.yml:

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

Testergebnisse:

1. L2-Cache ist eingeschaltet und 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 Cache ist AUS und 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)

Jetzt frage ich mich, was ich mit all dieser Freizeit anfangen soll

Ich finde es seltsam, dass noch niemand diese Optimierungen vorgeschlagen hat. Hier sind einige allgemeine Tipps zur Optimierung der Projekterstellung und des Starts bei der Entwicklung:

• Entwicklungsverzeichnisse vom Antivirenscanner ausschließen:
  • Projektverzeichnis
  • Ausgabeverzeichnis erstellen (wenn es außerhalb des Projektverzeichnisses liegt)
  • IDE-Indexverzeichnis (z. B. ~ / .IntelliJIdea2018.3)
  • Bereitstellungsverzeichnis (Webanwendungen in Tomcat)
• Hardware aktualisieren. Verwenden Sie schnellere CPU und RAM, bessere Internetverbindung (zum Herunterladen von Abhängigkeiten) und Datenbankverbindung, wechseln Sie zu SSD. Eine Grafikkarte spielt keine Rolle.

WARNHINWEISE

1. Die erste Option ist der Preis für reduzierte Sicherheit.
2. Die zweite Option kostet (offensichtlich) Geld.

Für mich klingt es so, als würden Sie eine falsche Konfigurationseinstellung verwenden. Überprüfen Sie zunächst myContainer und mögliche Konflikte. Um festzustellen, wer die meisten Ressourcen verwendet, müssen Sie die Speicherzuordnungen (siehe Datenmenge!) Für jede Abhängigkeit gleichzeitig überprüfen - und das nimmt auch viel Zeit in Anspruch ... (und SUDO-Berechtigungen). Übrigens: Testen Sie den Code normalerweise anhand der Abhängigkeiten?