Interne Derivatgenerierung unbrauchbar?

[aetherfaerber]

Kitodo bietet eine interne Funktion zum generieren von Derivaten. Als wir mit dem Einsatz von Kitodo begannen, haben wir diese ausprobiert und dann schnell davon abgelassen. Das Generieren der Bilder hat viele Ressourcen gefressen und war sehr langsam. Auch haben wir keinerlei Einstellungsmöglichkeiten, sowohl bzgl. der Performance als auch hinsichtlich der Vorgaben für die Derivate gefunden.
Daher haben wir die Funktion in entsprechenden Workflowschritten deaktiviert und sprechen statt dessen über automatische Workflowschritte unser schon vorher vorhandenes selbstgebasteltes Python-Skript an, welches wesentlich schneller, mit weniger Ressourcen und vielen optionalen Parametern läuft.

Es gibt aber auch Stellen, wo ein Ausbau nicht ohne weiteres möglich erscheint. Werden z.B. über den Metadateneditor Bilder hochgeladen, erstellt Kitodo die Derivate dazu selbst und nutzt die interne Funktion.

Soweit ich weiß, verwendet Kitodo ImageMagick, weshalb ich schon darüber nachgedacht habe, die entsprechende Binärdatei auf unserem Server durch einen Wrapper zu unserem Skript zu ersetzen. Es ist aber natürlich sehr fraglich, ob dies dann effizienter wäre und die Ineffizienz tatsächlich bei ImageMagick und nicht doch eher bei Kitodo liegt.

Wie ist das bei euch? Habt ihr Probleme mit der internen Lösung und wenn ja, wie geht ihr damit um?

[henning-gerhardt]

Allgemein: Die Parameter für die Generierung der Vorschaubilder müssen in den jeweiligen Folder Information / Unterordner Einstellungen pro Projekt definiert werden und sollten dann theoretisch an den Generierungsprozess übergeben werden.

An der SLUB verwenden wir die Kitodo.Production interne Lösung nicht. Die Generierung der Vorschaubilder mit der Anwendung war uns zu langsam, zu ressourcen-intensiv, nicht verteilbar und ein Monitoring über Fehlerfälle nur schwer umsetzbar. Die Konfiguration ist bzw. die Parameter sind bei uns einheitlich und Änderungen an der Konfiguration sollen einfach zentral durchführbar sein. Theoretisch kann man die Generierung auch auf andere Systeme via ssh Kommando auslagern, jedoch fehlt uns bei der lokalen Ausführung als auch der Ausführung auf einen externen System die Kontrolle über den Ausführungszeitpunkt (Wartung, Haverie, ...). Es gab auch Fälle in denen die interne Lösung die Derivate nicht erneuert hat, obwohl sich in den Bilddaten Änderungen vorhanden waren.

Unsere eingesetzte, selbst entwickelte Lösung

• nutzt eine zentrale Konfiguration für die Erstellung der Bildderivate
  • bei Änderungen an der Konfiguration werden nur neue Derivate mit den neuen Einstellungen erzeugt, bestehende werden nicht geändert sofern dies nicht erzwungen wird
  • Änderungen gab es seit dem Start im September 2023 nur einmalig. Hier wurde der gleiche bestehende Mechanismus erneut genutzt, der schon bei der Migration von 2.x auf 3.x zum Einsatz gekommen ist, da die Vorschaubilder für bestehende Vorgänge nach geniert werden mussten
• nutzt Prüfsummen Vergleiche (SHA512 Prüfsummen), so dass nur Derivate für geänderte Dateien erstellt werden oder wenn die Derivate nicht vorhanden sind
• kann auf beliebig vielen Systemen verteilt werden, da über ActiveMQ sich jedes System jeweils eine Aufgabe abholt und abarbeitet. ActiveMQ wird ebenfalls zum Schließen der jeweiligen Aufgabe genutzt
• wird via CronJobs gestartet und kann so im Wartungs- und Haveriefall kontrolliert beendet werden
• nutzt in Kombination mit unseren regulären Überwachungssystem die erzeugten Logdateien, um in Fehlerfällen die Administratoren zu informieren

[aetherfaerber]

Vielen Dank für die ausführliche Antwort! Wir erwägen gerade den weiteren Ausbau unserer Lösung und das gibt uns definitiv Hinweise auf wichtige Anforderungen.