Insbesondere bei großen Websites bewirken manche Änderungen an Dateien, dass die Template Engine viele andere Dateien als veraltet betrachtet, weil sie von der geänderten Datei abhängig sind. Dies führt dazu, dass der Veröffentlichungsvorgang länger dauert, weil sehr viele Dateien neu exportiert werden müssen.
Große Auswirkungen haben:
Änderungen an Layoutdateien. Sie führen dazu, dass der Teilbaum, in dem das Layout wirksam ist, veraltet ist und neu exportiert werden muss. Dies gilt unabhängig davon, ob das Layout während des Exports tatsächlich verwendet wird oder nicht.
Namensänderungen bei Ordnern. Sie führen ebenfalls dazu, dass alle Dateien in diesem Teilbaum und darüber hinaus alle Dateien mit Links, die auf eine Datei in diesem Teilbaum verweisen, neu exportiert werden müssen, weil sich der Pfad der im Ordner enthaltenen Dateien geändert hat.
Geringere Auswirkungen haben:
Änderungen der Dateiendung. Sie haben zur Folge, dass alle Dateien mit Links auf die betreffende Datei neu exportiert werden müssen.
Größenänderungen bei Bildern. Sie führen ebenfalls dazu, dass alle Datein mit Links auf die betreffende Datei neu exportiert werden müssen, weil die Links Größenangaben enthalten können.
Änderungen am Feld suppressExport . Referenzen
(wie Links) auf die betreffende Datei werden beim Export sichtbar gemacht
oder nicht, abhängig vom Wert dieses Feldes. Seinen Wert zu ändern,
bedeutet deshalb, dass die Dateien, die die Referenzen enthalten, neu
exportiert werden müssen.
Werden Dateien angelegt oder Dateien gelöscht, so veralten
alle Dateien, die Inhaltsübersichten (toclist) der
betreffenden Ordner enthalten.
Änderungen an den meisten Versionsfeldern führen dazu, dass neben der betreffenden Datei alle Dateien veralten, bei deren Export Feldwerte aus der ursprünglichen Datei abgefragt werden.
Wenn Sie Inhalte statisch mit includetext einbinden, ist
es empfehlenswert, die Inhalte stattdessen dynamisch mit
insertvalue = "dynamiclink" einzubinden. Ferner sollten In
Layoutdateien die Werte hasSuperLinks,
superLinks und superObjects sehr vorsichtig
eingesetzt werden, da sie eine Abhängigkeit der gefragten Datei von allen
anderen Dateien erzeugen.
Die Exportzeit resultiert demnach nicht allein aus der Anzahl der
exportierten Dateien, sondern auch aus der Komplexität der Layoutstruktur und
dem Berechnungsaufwand, der je exportierter Datei entsteht. Dieser Aufwand
ergibt sich vor allem aus der Häufigkeit und der Art der Werte, die in
Layoutdateien abgefragt werden. So ist es beispielsweise wesentlich
zeitaufwändiger, Datei- oder Linklisten zu generieren als einzelne Feldwerte
wie title zu ermitteln.
Ob die Abhängigkeiten die Ursache eines langsam laufenden Exports sind, lässt sich folgendermaßen ermitteln.
Führen Sie im Content Manager den Befehl incrExport
reset aus und übertragen Sie Ihren Content mit job withName
systemTransferUpdates exec zur Template Engine.
Achtung: Während dieser Befehl ausgeführt wird, dürfen keine Update-Records erzeugt werden. Der Befehl incrExport reset darf nur im Single-Modus verwendet werden und nur ausgeführt werden, wenn mit Sicherheit keine schreibenden Zugriffe auf den Datenbestand stattfinden, da andernfalls die exportierten Daten unvollständig sind oder zerstört werden. Stellen Sie daher sicher, dass während der Ausführung des Befehls der CM nicht als Server läuft und keine anderen CMs im Single-Modus gestartet werden oder laufen.
Nachdem alle Update Records übertragen wurden, führen Sie in
der Template Engine den Befehl app export aus.
Untersuchen Sie unmittelbar nach dem Export die erzeugten
Abhängigkeiten vom Typ usesAll.
Sie können hierfür den Befehl
statistics
compute name all verwenden sowie die Protokolldatei der
Template Engine untersuchen (jedes Mal, wenn eine Abhängigkeit dieses
Typs erzeugt wird, wird eine Warnung ins Protokoll geschrieben).
Stellen Sie fest, weshalb die betreffenden Dateien von sehr
vielen anderen Dateien abhängen. Zu diesem Zweck kann der Wert des
Systemkonfigurationseintrags tuning.export.usesAllThreshold
vergrößert (die Template Engine muss danach neu gestartet werden) und
können anschließend einige der betreffenden Dateien aktualisiert werden
(obj touch und obj updateCache). Werden für die
Dateien nun keine usesAll-Abhängigkeiten mehr erzeugt, so
erhalten Sie mit obj withId id get
dependencies auch die IDs der Dateien, von denen die betreffenden
Dateien abhängen.
Möchten Sie wissen, welche Layoutdatei und welche NPSOBJ-Anweisung
daraus für die Erzeugung einer bestimmten Abhängigkeit verantwortlich
ist, so erhöhen Sie im Systemkonfigurationseintrag server.log.logger
mit dem Namen info den Wert für das Attribut
level auf 3. Starten Sie anschließend die Template Engine
neu. Aktualisieren Sie eine der betreffenden Dateien mittels obj
withPath path updateCache). Sie können nun
dem info.log die oben genannten Details zum Export dieser
Datei entnehmen.
Um die Anzahl der Abhängigkeiten zu reduzieren, gehen Sie bitte wie oben beschrieben vor, d. h. verringern Sie die Komplexität Ihrer Layoutstruktur und den Berechnungsaufwand in den Vorlagen.