# Spring-Boot und Spring Data Programmstart zu langsam



## grindelaner (10. Mai 2017)

Hallo ich verwende Spring Boot und Spring Data.
Meine Datenbank hat etwas über 2.000 Tabellen.

Wenn ich meine Anwendung starte dauert das gefühlt über zwei Minuten, da Spring Data immer die Datenbank und deren ORM-Bäume initialisiert...

Für die Entwicklung ist das etwas nervig, wenn man häufig die Anwendung neu starten muss...

Kenn jemand eine Möglichkeit die Startprozedur von Spring Boot zu verschnellern?


----------



## stg (10. Mai 2017)

Mit Spring Boot wird das vermutlich weniger zu tun haben, sondern dein Problem vermute ich eher in deiner Vorgehensweise bei der Entwicklung. Du wirst ja kaum immer an allen Ecken gleichzeitig arbeiten. Wenn du eine UI entwickelst, dann ist es dieser z.B. egal, wo die Daten herkommen und den ganzen Rest der Anwendung brauchst du dann auch nicht. Wenn du also in kleinen Abständen "selbst immer mal gucken willst", wie das Ergebnis nun aussieht, dann betrachte also auch nur diesen kleinen Ausschnitt, an dem du gerade arbeitest. Für das große ganze gibt es dann Build-Server, automatisierte Tests usw. Da ist es dann auch egal, wenn so ein Build mal ne halbe Stunde dauert.
Auf der anderen Seite läuft vermutlich was schief, wenn gleich zu Beginn der Anwendung der gesamte Datenbestand ausgelesen werden muss. Was du da gebastelt hast, kann man aber nicht mal erraten, ohne einen Blick in deinen Anwendung geworfen zu haben.


----------



## mrBrown (10. Mai 2017)

stg hat gesagt.:


> Auf der anderen Seite läuft vermutlich was schief, wenn gleich zu Beginn der Anwendung der gesamte Datenbestand ausgelesen werden muss. Was du da gebastelt hast, kann man aber nicht mal erraten, ohne einen Blick in deinen Anwendung geworfen zu haben.


Ich denke, dass ist die Validierung von Entitys und Datenbank, das dürfte doch bei jedem Start passieren?

Allerdings klingt eine Anwendung, die 2000 Tabellen braucht nicht grad nach einer Anwendung, sondern nach ziemlich vielen, die einfach in ein Projekt gesteckt wurden...


----------



## Blender3D (10. Mai 2017)

stg hat gesagt.:


> Auf der anderen Seite läuft vermutlich was schief, wenn gleich zu Beginn der Anwendung der gesamte Datenbestand ausgelesen werden muss. Was du da gebastelt hast, kann man aber nicht mal erraten, ohne einen Blick in deinen Anwendung geworfen zu haben.



Ich denke auch, dass Du Deinen Zugriff auf die Daten überdenken solltest. Stichwort Proxy Pattern.
https://de.wikipedia.org/wiki/Stellvertreter_(Entwurfsmuster)

https://de.wikipedia.org/wiki/Stellvertreter_(Entwurfsmuster)


----------



## mrBrown (10. Mai 2017)

Blender3D hat gesagt.:


> Ich denke auch, dass Du Deinen Zugriff auf die Daten überdenken solltest. Stichwort Proxy Pattern.
> https://de.wikipedia.org/wiki/Stellvertreter_(Entwurfsmuster)


Etwas OT, aber was sollen Proxys da bringen (die Spring btw zu genüge nutzt)?


----------



## grindelaner (10. Mai 2017)

Ich hoffe, dass Spring-Boot etwas von Haus aus mitbringt. Die Persistenzschicht ist ja über die sogenannten "Repository-Interfaces" gekapselt... 
Ich habe an so etwas gedacht wie Spring DEV-Tools, dem du dann sagen kannst schalte alle Prüfungen aus und starte dann die Anwendung schneller...


----------



## grindelaner (10. Mai 2017)

Ich versuche meine Frage noch einmal anders zu stellen:
Weiß jemand wie man die Startprozedur von Spring Boot mit Spring Data für die Entwicklung schneller machen kann?

Gibt es da irgendwelche Optionen an den man schrauben kann?


----------



## mrBrown (10. Mai 2017)

`spring.jpa.properties.javax.persistence.validation.mode=none` in den properties sollte die Validierung abschalten


----------



## dennisbauer (10. Mai 2017)

Das klingt nach einem Konfigurationsfall nach diesem hier: 
https://docs.spring.io/spring-boot/docs/current/reference/html/howto-database-initialization.html

Speziell die beiden in 78.1 genannten Parameter solltest du, für so eine große Datenbank ersteinmal ausschalten und lieber mit einem inkrementellen Tool arbeiten, dass deine Datenbank mittels Änderungen erweitert. Da kann ich Liquitbase empfehlen, Änderungen an Tabellen werden als "Changelog" definiert und angewandt bei Start. Das lässt sich auch in Spring integrieren.

Wenn Spring erstmal für 2000 Tabellen Anfragen an die Datenbank schicken muss, um die zu überprüfen, das kann durchaus mal eine Weile dauern, zumindest würde ich das so erwarten.


----------



## grindelaner (11. Mai 2017)

Danke für die Hinweise.
Vielleicht stelle ich mich blöd an, aber die Zeit zum Hochfahren der Anwendung hat sich nicht geändert.
_Started ServletInitializer in 57.524 seconds (JVM running for 63.972)_
Es dauert also ca. 60 Sekunden, bis die Anwendung gestartet ist.

Ich habe es mit folgenden Parametern in der application.properties ausprobiert.
_spring.jpa.properties.javax.persistence.validation.mode=none
spring.jpa.generate-ddl=false_

Zu DatabaseInitialization:
Ich starte eine bestehende Datenbank. Das Datenbankschema ist also schon da...

Kennt sich vielleicht jemand mit Spring-boot-devtools aus?
Da soll es so etwas geben wie schnelleres Neustarten den Anwendung:
https://docs.spring.io/spring-boot/...to-hotswapping.html#howto-reload-fast-restart


----------



## dzim (16. Mai 2017)

Nur so eine Idee, die mir gerade in den Sinn kommt: Worauf startest du eigentlich die Anwendung? Linux? Windows? 

Sie enthält ja sicher auch einen Tomcat/etc. Unter Linux muss (bzw. sollte man) man beim Start noch einen Parameter mitgeben: 

```
-Djava.security.egd=file:/dev/./urandom
```
Das Problem ist, das eventuell nicht genug Entropy für die Initialisierung zur Verfügung steht, dann wartet man auf den Start der Anwendung (auch von kleinen Anwendungen) mitunter recht lang.


----------



## JuKu (1. Jun 2017)

Spring an sich gehört auch nicht gerade zu den performantesten Frameworks...
Aber bei 2000 Tabellen hast du irgendwas falsch gemacht.
Entweder zu viel normalisiert oder du solltest deine Anwendung aufteilen.


----------



## mrBrown (1. Jun 2017)

JuKu hat gesagt.:


> Spring an sich gehört auch nicht gerade zu den performantesten Frameworks...


Welches vergleichbare ist denn performanter?


----------



## dzim (1. Jun 2017)

mrBrown hat gesagt.:


> Welches vergleichbare ist denn performanter?


z.B. wenn man es minimalitischer angeht mit Guice.

#edit: Vielleicht auch vert.x... Noch nie Probiert, aber wenigstens vom Anbieten der Daten her scheint es ja performant zu sein.

Dann muss man aber eben schauen, wie man die DB-Sache hinbekommt. Bei einer existierenden Struktur wie hier, würde ich wohl mal jOOQ ausprobieren. Steht auf meiner TODO-Liste, hatte bisher aber noch kein passendes Projekt.


----------



## mrBrown (1. Jun 2017)

dzim hat gesagt.:


> z.B. wenn man es minimalitischer angeht mit Guice.
> 
> #edit: Vielleicht auch vert.x... Noch nie Probiert, aber wenigstens vom Anbieten der Daten her scheint es ja performant zu sein.
> 
> Dann muss man aber eben schauen, wie man die DB-Sache hinbekommt. Bei einer existierenden Struktur wie hier, würde ich wohl mal jOOQ ausprobieren. Steht auf meiner TODO-Liste, hatte bisher aber noch kein passendes Projekt.


Aber von denen ist ja auch keins wirklich vergleichbar mit dem Spring-Framework, da muss man ja schon alle 3 kombinieren, und das würde kaum an das ran kommen, was Spring Boot + Spring Data bietet...


----------



## thecain (1. Jun 2017)

dzim hat gesagt.:


> Dann muss man aber eben schauen, wie man die DB-Sache hinbekommt. Bei einer existierenden Struktur wie hier, würde ich wohl mal jOOQ ausprobieren. Steht auf meiner TODO-Liste, hatte bisher aber noch kein passendes Projekt.


Kommt von der Einfachheit niemals an Spring Data ran (will es ja auch nicht). Als alternative sähe ich Apache DeltaSpike. Aber ich würde das Problem jetzt nicht auf die Spring Performance schieben.


----------



## dzim (2. Jun 2017)

Ich denke auch eher, dass es weniger an Spring liegt (trotz etwas langsamerer Startzeiten), sondern eher an Hibernate, wenn es das Model verifiziert (Modell-Klassen gegen DDL - auch wenn ich die Interna zu wenig kenne, was Hibernate da eigentlich macht).

Ich wollte ja nur Alternativen zeigen - auch wenn sie vielleicht etwas unzulänglich sein mögen. Wobei Vert.x sicher ein Ersatz für den Web-Teil sein könnte, aber mehr eben auch nicht.

Muss denn die Applikation alle Modelle beinhalten? Könnte man denn nicht mehr dem Mikroservice-Ansatz folgen und alles etwas nach "Themen" aufspalten?


----------



## mrBrown (2. Jun 2017)

dzim hat gesagt.:


> Muss denn die Applikation alle Modelle beinhalten? Könnte man denn nicht mehr dem Mikroservice-Ansatz folgen und alles etwas nach "Themen" aufspalten?


Das war auch mein erster Gedanke...2000 Tabellen klingt sehr danach, dass es möglich und auch nötig ist...


----------



## JuKu (14. Jun 2017)

mrBrown hat gesagt.:


> Welches vergleichbare ist denn performanter?



Wenn man erstmal nur HTTP ausliefern will, ist Jersey oder Jetty oder Grizzly zu empfehlen.
Letzteres soll laut diesem Artikel sogar mit zu den schnellsten HTTP Server Libraries zählen.
An die Daten kommt man am schnellsten ohne Object Mapper, indem man direkte MySQL Queries schreibt und ausführt.


----------



## dzim (14. Jun 2017)

Dennoch würde ich eher Micro-Services verwenden, die nur das enthalten, was sie brauchen. Nicht alles. Und in dem Fall dieser DB würde vielleicht jOOQ sich anbieten - das kann die DB "scannen" und den Client generieren. Unter der Haube "native" Queries, kein ORM im Sinne vom Hibernate, sondern ein automatisches Konvertieren, das man sonst selbst und von Hand schreiben müsste.


----------



## mrBrown (14. Jun 2017)

JuKu hat gesagt.:


> Wenn man erstmal nur HTTP ausliefern will, ist Jersey oder Jetty oder Grizzly zu empfehlen.
> Letzteres soll laut diesem Artikel sogar mit zu den schnellsten HTTP Server Libraries zählen.
> An die Daten kommt man am schnellsten ohne Object Mapper, indem man direkte MySQL Queries schreibt und ausführt.


Das ist dann aber kaum mit dem Spring Boot-Stack vergleichbar


----------



## dzim (14. Jun 2017)

Spring Boot und andere Server sind i.d.R. kein Problem (jetty, undertow, …) - Grizzly kenn ich nicht.
Und auch jOOQ ist IMHO kein Problem. Also wahrscheinlich alles integrierbar.


----------

