Dimensionierung der Sprin-Boot Software

D

danielmaann

Mitglied
Hallo zusammen

Ich habe in der letzten Zeit eine mittelgrosse Software geschrieben, welche in Zukunft auf Docker laufen soll. Die Software wird als Spring-Boot Applikation gestartet und im Hintergrund sollte eine MySQL Datenbank laufen. Nun habe ich folgendes Problem.

Die Dimensionierung der Software bereitet mir grosse Probleme.
Wie kann ich herausfinden wie viele CPU's Kernels eine Docker-Instanz haben soll (ich möchte mind. 2 Docker-Instanzen auch schon wegem dem Load-Balancer). Wie kann ich die ideale Anzahl der Pool-Connections pro Instanz herausfinden und auch seitens der Datenbank, wie viele Connections die insgesamt zur Verfügung stellen soll (für alle Instanzen gemeinsam). Wie werden diese Connections gemessen, wie viele ich maximal pro RAM,CPU,... haben kann?
 
H

httpdigest

Top Contributor
Im Endeffekt kannst du das nur mit Hilfe eines Lasttests messen. Fange mit einer Instanz, mit einer geringen Anzahl an Datenbank Connections und wenigen Threads an und messe das Laufzeitverhalten der Anwendung, z.B. den Roundtrip von Requests, wenn es sich um eine Webanwendung handelt. Dann verändere sukzessive die Parameter (Anzahl Instanzen, Connections, Threads) und messe, ob sich dadurch etwas verbessert hat. Irgendwann wirst du sicherlich "diminishing returns" haben, also 100 Anwendungs-Instanzen sind wahrscheinlich noch 0.1% besser als 99 Instanzen, aber die Verbesserung steht in keiner Relation mehr zu den Kosten.
Letztendlich hast du hier ein Optimierungsproblem, das du nur mittels Sampling und definierten Maximalgrenzen lösen kannst.
Der erste Schritt ist also: Definiere dir erstmal eine Messmethodik mit einem repräsentativen Lasttest.
 
D

danielmaann

Mitglied
httpdigest hat gesagt.:
Im Endeffekt kannst du das nur mit Hilfe eines Lasttests messen. Fange mit einer Instanz, mit einer geringen Anzahl an Datenbank Connections und wenigen Threads an und messe das Laufzeitverhalten der Anwendung, z.B. den Roundtrip von Requests, wenn es sich um eine Webanwendung handelt. Dann verändere sukzessive die Parameter (Anzahl Instanzen, Connections, Threads) und messe, ob sich dadurch etwas verbessert hat. Irgendwann wirst du sicherlich "diminishing returns" haben, also 100 Anwendungs-Instanzen sind wahrscheinlich noch 0.1% besser als 99 Instanzen, aber die Verbesserung steht in keiner Relation mehr zu den Kosten.
Letztendlich hast du hier ein Optimierungsproblem, das du nur mittels Sampling und definierten Maximalgrenzen lösen kannst.
Der erste Schritt ist also: Definiere dir erstmal eine Messmethodik mit einem repräsentativen Lasttest.
Zum Vergrößern anklicken....

Un mithilfe welchen Tools kann ich dann die Lasttest testen? Ein JProfiles hat ja kein Zugriff auf die Laufzeit-Anwendung der Instanz innerhalb von Docker, schon nur weil es kein JAR/WAR mehr ist sondern eine Image.
 
H

httpdigest

Top Contributor
JProfiler ist für das Laufzeitverhalten einer Anwendung unter Realbedingungen auch nicht das richtige Tool, da es zum Beispiel die Performanceoptimierungen der JVM durch die Instrumentierung stark einschränkt. Nichtsdestotrotz kannst du natürlich auch einfach den JProfiler Port aus dem Container heraus exposen. Dass die Anwendung in einem Docker-Container läuft, hindert dich in keinster Weise daran, trotzdem per IP auf die Anwendung zuzugreifen. Was du willst, ist erstmal der Einfachheit halber eine Messung der Request/Response-Roundtrips. Sowas macht man nicht mit JProfiler, sondern z.B. mit einem Lasttest-Tool wie Apache JMeter. Für OS Metriken könntest du einfach Betriebssystem-Tools verwenden, um die Speicherauslastung und CPU-Auslastung des Prozesses zu messen. Der Docker-Daemon bietet hier auch Möglichkeiten.
 
D

danielmaann

Mitglied
httpdigest hat gesagt.:
JProfiler ist für das Laufzeitverhalten einer Anwendung unter Realbedingungen auch nicht das richtige Tool, da es zum Beispiel die Performanceoptimierungen der JVM durch die Instrumentierung stark einschränkt. Nichtsdestotrotz kannst du natürlich auch einfach den JProfiler Port aus dem Container heraus exposen. Dass die Anwendung in einem Docker-Container läuft, hindert dich in keinster Weise daran, trotzdem per IP auf die Anwendung zuzugreifen. Was du willst, ist erstmal der Einfachheit halber eine Messung der Request/Response-Roundtrips. Sowas macht man nicht mit JProfiler, sondern z.B. mit einem Lasttest-Tool wie Apache JMeter. Für OS Metriken könntest du einfach Betriebssystem-Tools verwenden, um die Speicherauslastung und CPU-Auslastung des Prozesses zu messen. Der Docker-Daemon bietet hier auch Möglichkeiten.
Zum Vergrößern anklicken....

Super ausgedrückt und verständlich. Danke dir für die Antwort. Ich weiss nun aber nicht wie sich die Connections der Datenbanken verhalten (ich weiss, dass es kein Thema von Spring oder Java ist sondern ein DB-Thema). Woher weiss ich, wie viele Connections meine DB total zur Verfügung stellen darf/kann (Hardwarespezifisch).
 
H

httpdigest

Top Contributor
Genau, der Punkt ist, dass es eigentlich irrelevant ist, bzw. du keine genaue Aussage darüber treffen kannst, ob nun 10 Datenbankverbindungen "viel" oder "wenig" oder "genau richtig" sind, ohne vorher deine Anwendung selbst in ihrem Antwortverhalten (also Ende-zu-Ende Tests) zu testen und gegen deine Erwartungen, die du an dieses Verhalten hast, zu validieren. Es hängt ja stark davon ab, wie die Anwendung selbst geschrieben ist. Nutzt sie zum Beispiel Thread-per-Request Modell oder Non-Blocking I/O, sowohl bei der Verarbeitung der Requests als auch bei der Verarbeitung der Datenbank-Anfragen (es gibt auch Non-Blocking Datenbanken/-treiber).
Letztlich musst du dir im Klaren darüber sein, was du genau testen willst und in welchen Ressourcen du beschränkt bist. Und da zählt eigentlich meistens weniger die CPU-Auslastung oder die Anzahl der Threads, sondern das Antwort-Verhalten der Anwendung selbst auf Requests (z.B. Time-to-first-Byte bei Webanwendungen). Und genau das willst du messen und dementsprechend die vertikale (mehr CPU, mehr Speicher, ...) und horizontale Skalierung (mehr parallel Instanzen) anpassen.
Bezüglich, wie viele Datenbankverbindungen die Datenbank nun verträgt: Es gibt ja Connection Pools, und diese haben auch Defaults bzw. in Dokumentationen beschriebene Einstellungen.
 
D

danielmaann

Mitglied
Hört sich gut an. Ich werde es mal ausprobieren und ansonsten werde ich mich wieder melden. Ich danke ihnen beiden und wünsche noch einen schönen Tag :)
 

Aktuelle Jobs

Neue Themen


Oben