Scheduling in JAVA EE

[beta20]

Hallo zusammen,

ich habe eine Frage was das Scheduling in JAVA EE angeht.
Ich verwende als Applikationsserver WildFly.
In JAVA EE ist es möglich verschiedene Schedules einzurichten:
@Schedule

Es lässt sich auch einstellen, wie oft der Schedule laufen soll.
Soweit so gut - das funktioniert auch.

Meine größere Sorge ist nun aber:
- Ich habe eine Applikation und es sollen stündlich 10.000 Schedules, also demnach 10.000 Datenbankabfragen geschehen.

Kann das nicht zum Problem meiner DB werden?
Was kann man dagegen tun? Mehr RAM, mehr CPU etc. einrichten?

Prinzipiell kann man dazu sagen, dass das i.d.R. dann INSERT Statements sind.
Anschließend können noch weitere Aktionen durchgeführt werden:
- Email senden
- Payment Provider kontaktieren und Payment anstoßen
- ....

Anwendungsfälle sind:
1) Automatisierte Rechnungen
- Ich habe Kunden, die ein Abo abschließen
- Jeden Monat sollen alle Rechnungen automatisiert versendet werden.

2) Erinnerungen versenden
- Ein User richtet sich Erinnerungen ein.
- Eintrag in DB wird erstellt, dann die Erinnerung versendet wird
- Schedule läuft jede Minute und prüft, ob es ausstehende Einträge gibt
- Wenn ja: Email wird versendet
-> Problem hier: dies habe ich selbst ja nicht mehr im Griff. Ein User kann sich ja zig Erinnerungen erstellen...

Danke für Ratschläge

 

[mihe7]

Wozu brauchst Du 10.000 Schedules?

 

[beta20]

Wozu brauchst Du 10.000 Schedules?

Falsch ausgedrückt:

Ich habe 1 Schedule, der jede Minute läuft.
Der eine Schedule feuert 10.000 Datenbankabfragen ab...

 

[mrBrown]

Und wozu sind automatisiert minütlich 10.000 Datenbankabfragen nötig?
(Wenn die alle nacheinander laufen, darf jede grad mal 6ms dauert, das ist nicht grad viel Zeit...)

 

[mihe7]

Ich habe 1 Schedule, der jede Minute läuft.

Warum?

 

[beta20]

Warum?

Prüfung, ob Erinnerungen versendet werden etc.
Es geht doch einfach nur um die Machbarkeit... Und ob das zu Performance Problemen führen kann bzw. was man dagegen machen kann....

 

[mrBrown]

Miss einfach mal, wie lange ein Datenbank-Request dauert, und dann überleg dir, wie das mit 10.000 aussieht.

Machbar ist irgendwie alles, irgendwann führt aber auch alles zu Performance-Problemen.
Lösen kann man das meist, in dem man das anders designed

 

[beta20]

Ich glaube das updaten / insert in die DB wird eher nicht das Problem sein, sondern die Aktion die dann ausgeführt werden soll
- Email verschicken
- Angebot verschicken
- ....

Diese Aktionen dauern ja länger, als ein INSERT oder UPDATE....

 

[mrBrown]

Miss einfach mal nach 😉

Wie kommst du denn auf 10.000? Du wirst wohl kaum 10.000 verschiedene hartcodierte Abfragen drin haben, vermutlich ist das N?

 

[mihe7]

Es geht doch einfach nur um die Machbarkeit... Und ob das zu Performance Problemen führen kann bzw. was man dagegen machen kann....

Ja, eben. Dazu muss man sich ansehen: warum, was passiert, muss das so sein oder kann das weg? Geht es auch anders usw.

Die erste Erklärung war: 10.000 Schedules. Nehmen wir mal an, Du hättest Dich nicht verschrieben, sondern es wären wirklich 10.000 Schedules gewesen. Dann hätte man gesagt: WTF?!? Pack die 10.000 in eine "Runde".

Dann schreibst Du: 1 Schedule á 10.000 Aufgabenblöcke und das jede Minute. Die Frage: warum jede Minute?

Zweck: Prüfung ob Erinnerungen versendet werden müssen. Äh?!? Wozu brauchst Du 10.000 INSERTS um zu prüfen, ob Erinnerungen verschickt werden müssen? Und warum musst Du das minütlich prüfen?

Rein von der Machbarkeit: wenn die Grenzen eines Systems erreicht werden, lässt sich manches auf mehrere Systeme verteilen.

 

[beta20]

Ok, also ich fasse es nochmal kurz zusammen, da es ja doch ein paar Verwirrungen gibt.

Beispiel: Erinnerungen versenden:
- Ich erstelle einen Termin und hake die Option an, dass ich z.B. 5h davor erinnert werden möchte
- Ich schreibe einen Eintrag in eine Tabelle (ScheduledObjects) mit dem plannedExecutionDate
- Mein Schedule (nur 1 Schedule!) prüft nun jede Minute, ob es Einträge in der Tabelle ScheduledObjects gibt, die fällig sind (plannedExecutionDate < currentDate)
- Wenn ja: dann wird eben z.B. eine Email versendet.

Wie ich nun entnehmen konnte, meint ihr, dass das Insert / Update NICHTdas Problem sein sollte

OK - wenn ich das richtig verstehe, dann könnte ich das dann auf mehreren Server verteilen?
- Also auf den Applikationsserver werden dann die Aktionen ausgeführt (zB. Email versenden)

Wo ich eher das bottleneck gesehen habe, war die DB ansich, da ich ja nur eine Datenbank habe.
Aber ich denke ihr habt Recht:
- Die Aktionen laufen ja dann eher auf dem Applikationsserver ab (Email versenden etc.)

Oder sehe ich es falsch?

 

[mrBrown]

Ok, also ich fasse es nochmal kurz zusammen, da es ja doch ein paar Verwirrungen gibt.

Beispiel: Erinnerungen versenden:
- Ich erstelle einen Termin und hake die Option an, dass ich z.B. 5h davor erinnert werden möchte
- Ich schreibe einen Eintrag in eine Tabelle (ScheduledObjects) mit dem plannedExecutionDate
- Mein Schedule (nur 1 Schedule!) prüft nun jede Minute, ob es Einträge in der Tabelle ScheduledObjects gibt, die fällig sind (plannedExecutionDate < currentDate)
- Wenn ja: dann wird eben z.B. eine Email versendet.

Zumindest ich hab das auch so verstanden...

Die Frage ist allerdings immer noch, warum 10.000 Datenbank-Requests?

Wie ich nun entnehmen konnte, meint ihr, dass das Insert / Update NICHTdas Problem sein sollte

Wo konntest du das denn entnehmen? 😵

OK - wenn ich das richtig verstehe, dann könnte ich das dann auf mehreren Server verteilen?
- Also auf den Applikationsserver werden dann die Aktionen ausgeführt (zB. Email versenden)

Ja, wobei Verteilung auf mehrere Server immer auch manche Dinge komplizierter macht.

Wo ich eher das bottleneck gesehen habe, war die DB ansich, da ich ja nur eine Datenbank habe.
Aber ich denke ihr habt Recht:
- Die Aktionen laufen ja dann eher auf dem Applikationsserver ab (Email versenden etc.)

Die DB (bzw. das Netzwerk) *kann* je nach Latenz durchaus auch zum Bottleneck werden, wenn du 10.000 Requests nacheinander absetzt.

 

[mihe7]

OK - wenn ich das richtig verstehe, dann könnte ich das dann auf mehreren Server verteilen?

Könntest Du, aber aktuell sehe ich aber noch keinen Grund dazu.

Das eigentliche Problem ist noch immer nicht identifiziert.

In welchen Zeitspannen werden wie viele Zeilen von Deinem SELECT geliefert? Gibt es zeitliche Verteilungen?

Wenn Du jetzt sagst, dass der SELECT jede Minute 10.000 Zeilen liefert und Du daher jede Minute 10.000 E-Mails rausschicken musst und das ganze 24 Stunden am Tag, dann wird es lustig, denn 14,4 Mio. Mails am Tag zu verschicken, könnte problematisch werden.

 

[beta20]

Zumindest ich hab das auch so verstanden...
Die Frage ist allerdings immer noch, warum 10.000 Datenbank-Requests
Wo konntest du das denn entnehmen? 😵
Ja, wobei Verteilung auf mehrere Server immer auch manche Dinge komplizierter macht.
Die DB (bzw. das Netzwerk) *kann* je nach Latenz durchaus auch zum Bottleneck werden, wenn du 10.000 Requests nacheinander absetzt.

Es war nun nur einfach ein Beispiel mit 10.000 Requests.
Möglich wäre das z.B.

• Anfang des Monats
  • -> 10.000 Rechnungen werden automatisiert verschickt

Dass jede Minute 10.000 DB-Requests stattfinden, ist natürlich auch übertrieben....
Aber ja, es kann zu so Spitzenzeiten kommen (wie oben: anfang des Monats)

 

[mihe7]

Wenn Anfang des Monats 10.000 Rechnungen verschickt werden, dann passiert das doch nicht minütlich sondern einmalig. D. h. wenn Du um 00:00 Uhr 10.000 neue Rechnungen hast, hast Du um 00:01 Uhr keine neuen Rechnungen mehr (vermutlich um 01:00 Uhr immer noch keine). Du hast also Zeit ohne Ende.