Questions & Answers

[re-lounge]

Hallo Community,

wir stehen bei unserem Kunden aktuell vor der Herausforderungen, dass die Laufzeit des Volldeployments monatlich immer länger wird. Der Kunde arbeitet mit einem RemoteMedia-Umfeld (d.h. ein Projekte für Globale Medien und eines für Globale Datenquellen) in welchem stetig neue Medien, Datenquellen und Applikationen hinzukommen. An die Globalen Projekte sind zwei externe Projekte und ein großes Intranet angedockt.

Während das nächtliche Volldeploment vor zwei Jahren noch zwischen 1 und 2 Stunden lief, haben wir aktuell für den externen Auftritt die 5-Stunden-Grenze durchbrochen:

Volldeployment Gesamt: 5h 11mn

deployGlobaleMedien: 3h 58m 9sn

Generate: 1h 12m 5sn

Es ist davon auszugehen, dass sowohl die Anzahl der Medien im Globalen Medien Projekt wie auch die Anzahl der eingesetzten Datenquellen im Rahmen von bereits geplanten Applikation kontinuierlich weiter steigen werden. Wir befürchten schon bald eine Laufzeit von 7 oder mehr Stunden zu erreichen.

=> Dies führt zu einer starken Unflexibilität insbesondere bei GoLives, welche kontrolliert wahrend der Arbeitszeiten durchgeführt werden sollen und über ein Teildeployment nicht oder nur schwer zu realisieren sind, weil die alten Inhalte dabei nicht gelöscht werden.

Daher unsere Frage:

Welche Möglichkeiten sehen Sie, die Laufzeit des Volldeployments zu reduzieren bzw. welche Alternativen zum sperrigen Volldeployment existieren?

Version:

FirstSpirit Client 4.2.432.43881
Server: xxx:80 (HTTP)
Projekt: xxx
Benutzer: rl_haefele (Häfele, Stefan)
Gruppen (Projekt): Administrators, Everyone
Gruppen (Extern): 
Version Server: 4.2.432.43881
Lizensiert für: xxx
Speicher: 45,96 von 494,94 MByte belegt
Java Version: 1.6.0_20 32bit Sun Microsystems Inc.
Betriebssystem: Windows 7 6.1 x86
Projektladezeit: 7,02 s  21,49 KByte/s

Auf Rückmeldung hoffend,

Stefan Häfele // re-lounge

[Peter_Jodeleit]

Die Differenz zwischen Generierung und Deployment ist ja ziemlich hoch. Wie wird denn deployed?

[Peter_Jodeleit]

Und noch etwas: Müssen wirklich alle Medien deployed werden?

[re-lounge]

Hallo Herr Jodeleit,

vielen Dank erst einmal für Ihre schnelle Rückmeldung!

Es werden aktuell gar nicht alle Medien deployt. Es werden lediglich alle Medien durchgegangen und es wird je Medium geprüft, ob dieses ausgehende Referenzen zum jeweiligen Projekt hat. Wenn ja wird das Medium in eine Seite geschrieben und später deployt, wenn nein, entsprechend nicht. Es wird aber jeder Medium durchgegangen und davon gibt es mittlerweile sehr sehr viele ...

PS.: Es handelt sich bei dem Volldeployment-Auftrag, welcher aktuell im Einsatz ist um die initial von e-Spirit erstellte Version. Wir haben an diesem Auftrag bisher noch keine Änderungen vorgenommen.

Beste Grüße,

Stefan Häfele // re-lounge

[feddersen]

Auf welche Art deployen sie denn? Rsync, FTP, CRC, Dateisystem?

Um wieviele Medien geht es?

Sind das sehr viele kleine Medien oder sind auch sehr große Dateien dabei?

Vermutlich wird das Skript über alle Medien iterieren. Da würden natürlich alle Medien reichen, die Seit der letzten Generierung hinzugefügt oder geändert wurden. Das kann man über die Revisionshistorie ermitteln.

Enthält die Generierungszeit (1Std und 12Min) das Skript was die zu generierenden Medien ermittelt? Falls ja, wie lange braucht das Skript einzeln?

Ist "deployGlobaleMedien"  der Deploymenttask oder verbirgt sich dahinter noch etwas anderes?

[Peter_Jodeleit]

Der Weg über die Revisionshistorie (in der API RevisionMetaData) ist eine gute Möglichkeit. Eine weitere Alternative wäre es, die benötigten Remote-Medien bei der Generierung der Seiten aufzusammeln (Stichwort ausgehende Referenzen). Dabei braucht man Medien, die sich seit der letzten Generierung nicht geändert haben, auch nicht aufsammeln. Allerdings muss man dann die Reihenfolge Generierung, Deployment der aufgesammelten Medien, Deployment der Seiten einhalten.

Den Weg über die Revisionshistorie kann dann auch beim Inhalte-Projekt anwenden, Volldeployments kann man dann z.B. noch einmal die Woche durchführen.

Eventuell gibt es auch Optimierungspotential innerhalb der Templates. Wie sind denn da die durchschnittlichen Generierungszeiten pro Seite und um wieviel Seiten handelt es sich insgesamt?

[sarahfinkel]

Hey zusammen,

hier ein paar ausführlichere Details zum Volldeployment:

• es wird über RSYNC deployed
• die Skripte (30s) und der RSYNC (~4min) sind nicht das Problem
• das Problem sind die beiden Generate-Aufträge: Generate Medien (~ 4h), Generate Seiten (~ 1,5h)
• Generate-Auftrag der Seiten: 2752 pages produced, ~2059 ms per page
• Generate-Auftrag der Medien: 1 pages produced, ~13915424 ms per page (Hinweis: Hier werden alle verwendete Medien in eine Seite geschrieben, welche dann deployed wird).

Bei dem Generate-Auftrag der Medien, wäre der Weg über die Revisionshistorie eine gute Möglichkeit. Die benötigten Medien über ausgehende Referenzen aufzusammeln, würde vermutlich nicht wirklich eine

Verbesserung bringen, da es sich an der Generierung (Anzahl der Medien) nichts ändert.

Allerding werden immer alle Auflösungen der Medien generiert und deployed. Kann man hier steuern, dass nur die verwendeten Auflösungen generiert werden?

Bei den Seiten sollten immer alle generiert werden, da es sich meistens um eine Strukturänderung handelt und dadurch die Navigation in allen Seiten neu generiert werden muss.

Bei diesen könnte durchaus eine Optimierung der Templates helfen. Gibt es hier irgendwelche "Do's" and "Dont's" hinsichtlich der Generierungsdauer?

Hinweis: Wir haben ziemlich komplexe Templates, da bei diesem Kunden eine Produtkdatenbank verwendet wird, bei der Seiten automatisch erstellt werden. Hier werden auch Skripte verwendet. Desweiteren wurden viele "Einzelelemente" (z.B. Linkgenerierung oder Medienausgabe), welche oft gebraucht werden in Formatvorlagen ausgelagert (Übersichtlichkeit, Änderungen an zentraler Stelle).

Viele Grüße

Sarah Finkel // re-lounge

[Peter_Jodeleit]

Bei 2 Sekunden Generierungszeit pro Seite lohnt es sich, auf die Templates zu schauen. Eventuell kann man Skripte durch Templatecode ersetzen. Wenn das nicht geht, durch eine plain-Java-Lösung. Die Auslagerung in Formatvorlagen ist für die Optimierung ja vorteilhaft.

Ansonsten muss man versuchen, die "Hot-Spots" zu identifzieren, um diese zuerst angezugehen. Hilfreich dafür ist bestimmt der Beitrag simple template profiling von Christoph.

Das alle Auflösungen generiert werden lässt sich bei einer "Mediengenerierung" nicht ändern,  da ja nicht klar ist, welche Auflösungen referenziert werden.

Die benötigten Medien über ausgehende Referenzen aufzusammeln, würde vermutlich nicht wirklich eine

Verbesserung bringen, da es sich an der Generierung (Anzahl der Medien) nichts ändert.

Wenn man sich nur die seit der letzten Generierung geänderten Medien merkt, dann würde das schon einiges bringen.

[Peter_Jodeleit]

Noch ein Nachtrag, wie man relativ einfach Generierungszeiten "drücken" kann:

• Aufteilung in parallele Tasks für disjunkte Teile der Site (z.B. wenn es fünf Top-Level Ordner in der Struktur gibt, für jeden Ordner eine eigene Generierungstask anlegen). Nachteil: Die Last während der Generierung ist auf dem Server dann maximal 5 so hoch (bei 5 parallelen Tasks). Wegen des I/O ist die Last in der Realität aber nicht so viel höher. Und da interaktive Anfragen an den Server priorisiert behandelt werden, wirkt sich der Effekt für den Redakteur auch nicht so stark aus.
• Man kann bei Mediengenerierungen einstellen, das die Dateien nicht auf die Platte des Servers geschrieben werden. Dabei wird ein virtuelles "in-memory" Dateisystem erzeugt, das beim anschliessenden Deployment genutzt wird. Allerdings kann das nur bei den "internen" Deployment-Mechanismen genutzt werden, nicht bei rsync (das je einen eigenen Prozess startet, und daher keinen Zugriff auf das "in-memory" Dateiystem hat).

[feddersen]

Hallo,

mich würde interessieren ob Sie mit den Hinweisen und Vorschlägen bei ihrem Problem weitergekommen sind?

Viele Grüße

Christoph Feddersen