mscholz3
I'm new here

Vollgenierung vermeiden (Delta-Generierung

Jump to solution

Hallo Cummunity,

wir sind dabei die Einführung der Delta-Generierung zu planen. Beim damaligen Einführen des Systems gab es die Delta-Generierung noch nicht.

Diese Delta-Generierung wurde bereits auf einer Entwicklungsumgebung von einem externen FirstSpirit-Experten eingerichtet und per Content-Transport für das Produktiv-System zur Verfügung gestellt.

Laut Externer ist zuvor eine Vollgenerierung des Produktiv-Systems vonnöten, um das Delta zu berechnen.

Das Problem ist, dass eine Vollgenerierung auf dem Produktiv-System mehrere Tag in Anspruch nimmt und das System signifikant verlangsamt.

Ist eine Vollgenerierung unumgänglich oder lässt sich FirstSpirit ggf. auch anderweitig dazu bewegen, initial das Delta zur letzten Generierung zu ermitteln?

Weitere Informationen:

Bisher werden lediglich Teilprojektgenerierungen durchgeführt.

>hmm, also es lief doch schon mal eine Vollgenerierung oder wie kommt man darauf, dass diese mehrere tage dauern könnte?

Im letzten Release haben wir eine Vollgenerierung durchgeführt. Diese ging über 14 Stunden und ist bedingt durch den Festplattenspeicher abgebrochen. In dieser Zeit war das System komplett ausgelastet und konnte kaum bis gar nicht genutzt werden. Darum wollen wir eine Vollgenerierung auf dem Produktivsystem möglichst vermeiden.

Wir haben bereits dem FS-Support unser Problem geschildert. Der Support hat uns auf ein Skript hier in der Community verwiesen, mit dem man "ordnerweise" Vollgenieren kann: Delta-Generation

Das Problem ist nur, dass wir das Skript nicht wirklich einsetzten können, da schon eine Datenquelle (News) unmengen an Daten besitzt. Alleine diese Datenquelle mittels Skript einzeln zu vollzugenerierung würde wahrscheinlich zu lange dauern.

Gibt es da nicht vllt. einen anderen Trick um die Vollgenerierung zu vermeiden?

Vielleicht in der Datenbank das Delta manuell setzten? (Wenn die erste Delta-Generierung ein paar Stunden laufen müsste, wäre das kein

Liebe Grüße

Marcel

(Delta-Generierung

0 Kudos
1 Solution

Accepted Solutions
mbergmann
Crownpeak employee

Hallo Marcel,

grundsätzlich ist es so, dass sich die Delta-Generierung den Zeitpunkt bzw. genauer die Revision der letzten Delta-Generierung im Auftrag merkt. Das passiert über die Auftragsvariable #deltaGeneration.last_execution. Wird diese Variable nicht gefunden, wird von einer Vollgenerierung ausgegangen.

Man kann nun allerdings diese Information "manipulieren", indem man die Variable durch ein Skript im Auftrag selbst auf eine bestimmte Revision setzt:

context.setVariable("#deltaGeneration.last_execution", revisionId);

revisionId ist dabei vom Typ "long".

Auftragsvariablen haben im Gegensatz zu Properties die Eigenschaft, dass sie am jeweiligen Auftrag persistiert werden, d.h. beim nächsten Lauf desselben ( ! ) Auftrages wieder mit dem zuletzt gesetzten Wert verfügbar sind.

Ihr müsstet also letztlich schauen / entscheiden, welche Revision ihr als "bereits generiert" betrachten wollt und könnt dann die Variable entsprechend setzen. Das geht allerdings nicht "von außen", sondern nur "innerhalb" des Auftrages. Am einfachsten wäre wohl schlicht, temporär alle anderen Tasks zu deaktivieren und nur diesen einen "Manipulations-Task" aktiv zu lassen. Der muss danach natürlich wieder deaktiviert werden.

Ein paar Tipps: Da die Variable pro Auftrag gilt, müsst ihr je nach Projekt- bzw. Auftrags-Struktur noch weitere Anpassungen vornehmen. Außerdem überschreibt die Deltagenerierung die zuletzt generierte Revision gleich zu Beginn. Falls ihr unter bestimmten Umständen das Deployment nicht durchführt (z.B. abhängig von der Anzahl der Generierungsfehler), solltet ihr euch die #deltaGeneration.last_execution vor dem Aufruf der Deltagenerierung im Auftrag merken und sie in diesen Fällen wieder zurücksetzen. An die Variable kommt man per context.getVariable("#deltaGeneration.last_execution"). Falls ihr auch Aufträge für sog. "historische Generierungen" habt, sind diese auch entsprechend anzupassen.

Ob das bei euch alles direkt so funktioniert, kann ich allerdings nicht sagen - es kann sein, dass ihr noch weitere Anpassungen vornehmen müsst abhängig davon, wie eure Aufträge aussehen. Also unbedingt vorher testen 😉

Viele Grüße

Michael

View solution in original post

0 Kudos
5 Replies
mbergmann
Crownpeak employee

Hallo Marcel,

grundsätzlich ist es so, dass sich die Delta-Generierung den Zeitpunkt bzw. genauer die Revision der letzten Delta-Generierung im Auftrag merkt. Das passiert über die Auftragsvariable #deltaGeneration.last_execution. Wird diese Variable nicht gefunden, wird von einer Vollgenerierung ausgegangen.

Man kann nun allerdings diese Information "manipulieren", indem man die Variable durch ein Skript im Auftrag selbst auf eine bestimmte Revision setzt:

context.setVariable("#deltaGeneration.last_execution", revisionId);

revisionId ist dabei vom Typ "long".

Auftragsvariablen haben im Gegensatz zu Properties die Eigenschaft, dass sie am jeweiligen Auftrag persistiert werden, d.h. beim nächsten Lauf desselben ( ! ) Auftrages wieder mit dem zuletzt gesetzten Wert verfügbar sind.

Ihr müsstet also letztlich schauen / entscheiden, welche Revision ihr als "bereits generiert" betrachten wollt und könnt dann die Variable entsprechend setzen. Das geht allerdings nicht "von außen", sondern nur "innerhalb" des Auftrages. Am einfachsten wäre wohl schlicht, temporär alle anderen Tasks zu deaktivieren und nur diesen einen "Manipulations-Task" aktiv zu lassen. Der muss danach natürlich wieder deaktiviert werden.

Ein paar Tipps: Da die Variable pro Auftrag gilt, müsst ihr je nach Projekt- bzw. Auftrags-Struktur noch weitere Anpassungen vornehmen. Außerdem überschreibt die Deltagenerierung die zuletzt generierte Revision gleich zu Beginn. Falls ihr unter bestimmten Umständen das Deployment nicht durchführt (z.B. abhängig von der Anzahl der Generierungsfehler), solltet ihr euch die #deltaGeneration.last_execution vor dem Aufruf der Deltagenerierung im Auftrag merken und sie in diesen Fällen wieder zurücksetzen. An die Variable kommt man per context.getVariable("#deltaGeneration.last_execution"). Falls ihr auch Aufträge für sog. "historische Generierungen" habt, sind diese auch entsprechend anzupassen.

Ob das bei euch alles direkt so funktioniert, kann ich allerdings nicht sagen - es kann sein, dass ihr noch weitere Anpassungen vornehmen müsst abhängig davon, wie eure Aufträge aussehen. Also unbedingt vorher testen 😉

Viele Grüße

Michael

0 Kudos

Hallo Michael,

vielen Dank für die schnelle Antwort!

Nach Neujahr werden wir auf jeden Fall versuchen deinen Vorschlag umzusetzen!

Dir schon mal ein schönes Weihnachtsfest Smiley Happy

Liebe Grüße

Marcel

0 Kudos
NMc
Crownpeak employee
Crownpeak employee

Hallo Marcel,

benötigst Du noch weitere Hilfe oder haben Dir die Antworten von Michael bereits geholfen?

In diesem Fall wäre es super, wenn Du die "richtige Antwort" entsprechend markierst, damit auch andere

Community-Teilnehmer diese auf den ersten Blick finden. Solltest Du zwischenzeitlich eine eigene Lösung

gefunden haben, wäre es nett, wenn Du diese hier bereitstellst.

Viele Grüße

Nico

0 Kudos

Hallo Michael,

das mit der Auftragsvariabel hat klappt super geklappt!

Vielen Dank nochmal für deinen Tipp!

Liebe Grüße

Marcel

0 Kudos

Die Variable "#deltaGeneration.last_execution" gibt es überging nun als Konstante:

DeltaGeneration.DELTA_GENERATION_LAST_EXECUTION

(in "de.espirit.firstspirit.access.schedule.DeltaGeneration")

0 Kudos