Questions & Answers

[dude]

Hallo,

wir haben im aktuellen Projekt einen Mechanismus gebaut, der bestimmte Medien für Anwendungen generiert, die, da sie nicht direkt im FS referenziert werden, sonst nicht auf den Webserver gelangen würden.

Dazu sammeln wir uns bestimmte Medien aus dem Mediastore (Pressemitteilungen) und und setzen diese als Startknoten für einen folgenden Teilgenerierungsauftrag.

Der generiert wie gewünscht all diese Medien - leider in allen Auflösungen - tatsächlich brauchen wir neben dem Original nur wenige der tatsächlich existierenden Auflösungen.

Bei der Teilprojektgenerierung kann leider nur die Sprache und der Präsentationskanal gewählt werden, mehr Einstellungsmöglichkeitet bietet das Admin-Interface hier leider nicht. Gibt es eine andere Möglichkeit, die zu generierenden Auflösungen einzuschränken?

Viele Güße,

mana

[feddersen]

Hallo,

in vielen Projekte wird das wie folgt gelöst:

1. Das Script passt nicht die Startknoten einer Mediengenerierung an, sondern befüllt eine Eingabekomponente (FS_LIST) mit Links. Also für jedes Medium einen Linkkomponente (FS_REFERENCE) befüllen.

2. In der Vorlage dann einfach per CMS_REF die gewünschten Auflösungen referenzieren.

3. Bei der Generierung nur diese eine technische Seite generieren, so werden implizit nur die benötigten Medien generiert.

[hoebbel]

Hallo mana,

• mana • schrieb:

Dazu sammeln wir uns bestimmte Medien aus dem Mediastore (Pressemitteilungen) und und setzen diese als Startknoten für einen folgenden Teilgenerierungsauftrag.

Der generiert wie gewünscht all diese Medien - leider in allen Auflösungen - tatsächlich brauchen wir neben dem Original nur wenige der tatsächlich existierenden Auflösungen.

wenn ich es richtig verstehe, sollen alle Bilder unter einem bestimmten Startknoten veröffentlicht werden.

Ich würde dies so lösen, dass auf einer Seite automatisch alle diese Medien in der/den gewünschten Auflösung(en) referenziert werden und anschließend diese Seite nicht veröffentlicht wird.

Die templatetechnische einfache Lösung würde so aussehen:

- Eingabekomponente CMS_INPUT_PICTURE, in der der Redakteur ein entsprechendes Bild aus dem Verzeichnis, welches veröffentlicht werden soll, auswählen muss

- Die Ausgabe erfolgt dann mittels

$CMS_FOR(pics,pic.medium.parent.getChildren(pic.medium.class))$
$CMS_IF(pics.type == pic.medium.type)$
$CMS_REF(pics,resolution:"xyz")$
$CMS_END_IF$
$CMS_END_FOR$

Wenn man es fest definieren will, kann man sich auch die Kinder von einem definierten Ordner holen (die medium.class bekommt man so: $CMS_SET(mediaClass,class("de.espirit.firstspirit.access.store.mediastore.Media"))$

Viele Grüsse aus Dortmund,

  Holger

[dude]

Diese Lösung habe ich auch schon gesehen und verwendet (in einem Projekt mit etwa 90 GB Bildern). Die Generierung war dort dementsprechend langsam.

Das Problem selbst kann also als gelöst angenommen werden, ich versuche jetzt nur aus den vielen möglichen Lösungen die optimale zu finden, die z. B. Medien nur generiert, wenn nötig; und vor allem auch nur Auflösungen erzeugt, die gebraucht werden.

Hier wäre für mich interessant, unter welchen Bedingungen ein Medium neu generiert wird, und wann FS bemerkt, dass das Medium (noch in einer aktuellen Version) bereits generiert vorliegt. Bei der Variante mit der Seite, die Medien referenziert habe ich das Gefühl, dass viel zu oft alle Medien neu generiert werden, oder liege ich da falsch?

[Peter_Jodeleit]

Bei der Variante mit der Seite, die Medien referenziert habe ich das Gefühl, dass viel zu oft alle Medien neu generiert werden, oder liege ich da falsch?

"Erzeugen" ist ja nur das Erstellen der Kopie im Generierungsverzeichnis. Ob dies dann beim Deployment übertragen wird, hängt dann auch von der Art des Deployments ab. Wenn es am Zielort bereits vorhanden ist, wird es beim Delta-Deployment nicht erneut übertragen. Wenn man eines der Standard-Deployments nimmt (sprich: nicht rsync) kann man die Kopie im Generierungs-Dateisystem sparen, indem man die Option "Medien im Generierungsverzeichnis erzeugen" abwählt. Übertragen werden die Dateien dann bei Bedarf trotzdem.

[dude]

Das ist doch schon mal ein interessantes Detail, dass ich nicht wusste. Es gibt also neben den Generierungsverzeichnissen (~/fs4staging/$project_id/$task_id nehme ich an) einen zentralen Ort, an dem die generierten Medien liegen und einfach nur an die entsprechenden Stellen kopiert werden?

Bisher dachte ich, dass Medien 'on demand' (neu) erzeugt werden, wenn man sie in bestimmten Auflösungen anfragt.

[hoebbel]

Die Medien werden nur bei der ersten Verwendung in der entsprechenden Auflösung berechnet. Danach werden Sie im Repository gespeichert und bei der Generierung auch daraus gestreamt.

[dude]

Hallo,

eine Frage noch zum Thema. Wenn man wie Peter empfiehlt, "Medien im Generierungsverzeichnis erzeugen" abwählt und stattdessen ein Dateisystemdeployment macht, warum schreibt FS die Dateien trotzdem alle neu?

Schön wäre es, wenn Dateien, die am Ziel bereits existieren nicht angefasst werden. Das könnte man z. B. über eine neue Option an der Veröffentlichung einstellen. I.d.R. ändert man ja am Generierungsverzeichnis nichts. Denkbar wäre ja, ähnlich wie rsync einen Abgleich von Quelle (FS) und Ziel (Dateisystem) anhand von last-modified, file-size und/oder checksum.

Danach liessen sich die Medien viel leichter an alle Webserver/container ausliefern.

Ein Delta-Abgleich ist mit rsync nur auf Basis der checksum (CRC) möglich. Diese checksum-Option ist leider sehr 'teuer' und muss für jeden Webserver neu berechnet werden. Bei 40GB Daten dauert das enorm lang.

Viel einfacher und schneller wäre das über die Zeitstempel zu regeln.

Mir ist schon klar, dass sich dadurch das Deployment verlängert, aber im Einzelfall kann das durch ein deutlich effizienteres rsync locker wieder ausgegelichen werden.

[hoebbel · Accepted solution]

Hallo mana,

hier muss man mehrere Dinge berücksichtigen, die sich teilweise widersprechen:

• Die Option Medien im Generierungsverzeichnis erzeugen, steuert, ob bei der Generierung Medien physikalisch erzeugt werden sollen oder nicht. Wenn Sie nicht erzeugt werden sollen, so werden sie intern "vorgemerkt", so dass eine Veröffentlichung, die auf FirstSpirit Mitteln beruht (Datei-, FTP-Deployment, CRC-Servlet) diese direkt aus der Datenbank streamen kann. Die dritte Möglichkeit berücksichtigt übrigens ob die Medien im Zielsystem in dieser Version vorhanden sind oder nicht.
• Die Verwendung externer Veröffentlichungsmechanismen (z.B: rsync) setzt zwingend voraus, dass die Medien physikalisch im Dateisystem vorliegen.
• Die Verwendung der ACL Datenbank bewirkt (unter anderem), dass Dateien immer den Timestamp bekommen, mit dem Sie das erste Mal mit dieser URL und diesem Checksum (CRC) erzeugt wurden.

Die Verwendung der ACL Datenbank zusammen mit dem Rsync, welches nur Timestamps prüft, würde also das Problem lösen. Allerdings werden dann die Medien im Staging-Verzeichnis erzeugt, was wiederum Plattenplatz braucht

Viele Grüsse aus Dortmund,

  Holger

[dude]

Sehr interessant,

sind deine Infos irgendwo dokumentiert? Ich habe mich immer schon gefragt, was genau die ACL bei einer Generierung tut. Vom Namen her klingt das nicht nach CRC und timestamps.

Danke!