Questions & Answers

re-lounge
I'm new here

Laufzeit Volldeployment

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

0 Kudos
10 Replies
Peter_Jodeleit
Crownpeak employee

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

Peter
0 Kudos

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

Peter
0 Kudos

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

0 Kudos

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?

0 Kudos

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?

Peter
0 Kudos

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

0 Kudos

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
0 Kudos

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).
Peter
0 Kudos
feddersen
Community Manager

Hallo,

mich wรผrde interessieren ob Sie mit den Hinweisen und Vorschlรคgen bei ihrem Problem weitergekommen sind?

Viele GrรผรŸe

Christoph Feddersen

0 Kudos

Type a product name