Droid ist eine Open-Source-Bibliothek zur Formaterkennung (https://www.nationalarchives.gov.uk/information-management/manage-information/policy-process/digital-continuity/file-profiling-tool-droid/), die im Toolkit jeder Digital Preservation Software nahezu unverzichtbar ist. Aus diesem Grund haben wir sie in die Arcsys-Software integriert.
Als ein Kunde uns wegen der verminderten Leistung während des Archivierungsprozesses kontaktierte, ahnten wir nicht, dass dies zu einer epischen Reise führen würde… die lange Debatten unter den Droid-Mitwirkenden über die Mechanismen der Formatidentifikation auslösen und der gesamten Gemeinschaft zugute kommen würde!
Auf der Suche nach der Schwachstelle
Der Kunde eröffnete ein Ticket, in dem er erklärte, dass die Archivierungszeiten der Dateien im Vergleich zu den Erwartungen viel zu lang seien. Es handelte sich um sehr große Dateien, die mehrere Terabytes umfassten. Allerdings blieben die Dateien in einer bestimmten Phase des Prozesses, die immer die gleiche zu sein schien, für Dutzende von Stunden stecken: der Phase der Formatidentifizierung.
Die erste Frage war natürlich: Um welche Art von Dateien handelte es sich? Die Antwort war, dass es sich ausschließlich um komprimierte Dateien im ZIP-Format handelte.
Mit dieser Information machten wir uns an den wesentlichen Schritt, den jeder Softwareentwickler kennt: die Reproduktion des Problems.
Anomale Bandbreiten
Wir begannen mit dem Testen der Archivierung von ZIP-Dateien mit einer Größe von mehreren Gigabyte. Die Ursache für die langsame Verarbeitung war schnell gefunden: Es handelte sich tatsächlich um den Schritt der Formaterkennung, der von der Droid-Bibliothek durchgeführt wurde. Mit Hilfe eines Java-Profiling-Tools zur Messung der Lesebandbreite fanden wir heraus, dass die Langsamkeit dadurch verursacht wurde, dass die gesamte Datei zweimal gelesen wurde!
Zu unserer Überraschung stellten wir fest, dass bei der Ausführung derselben Datei durch das grafische Tool von Droid, DroidUI, nur ein minimaler Teil der Datei gelesen wurde, und das Ergebnis wurde viel schneller erzeugt.
Eröffnen eines Problems auf GitHub
Ausgestattet mit diesen konkreten Erkenntnissen eröffneten wir eine Untersuchungsanfrage auf Droids GitHub (https://github.com/digital-preservation/droid/issues/906) und setzten unsere Nachforschungen fort. Wir erkannten, dass sich das Problem um die Kombinationen von „binären Signaturdateien und Container-Signaturdateien“ drehte.
Zusammenfassend lässt sich sagen, dass Droid eine binäre Signaturdatei verwendet, um einen Dateityp zu identifizieren, der die spezifischen Bitfolgen beschreibt, die für jedes Format charakteristisch sind. Die Komplexität ergibt sich aus „Container“-Dateien wie ZIPs, die ebenfalls ihre eigenen Signaturdateien haben. Diese Signaturdateien entwickeln sich im Laufe der Zeit mit neuen Versionen weiter (z. B. wenn neue Formate hinzugefügt werden).
In unserem Fall haben wir festgestellt, dass das Problem der Langsamkeit in Abhängigkeit von der Kombination der Versionen der binären Signaturdateien und der Container-Signaturdateien verschwand. Dies erklärt, warum der grafische DroidUI-Client die Anomalie nicht aufwies: Er verwendete eine andere Kombination! In Zusammenarbeit mit der Community konnten wir die problematischen Einträge ausfindig machen, und die Anomalie wurde durch „Bereinigung“ der Signaturdateien behoben. In der Zwischenzeit haben wir die Lösung für unseren Kunden implementiert, der erleichtert war, dass das Leistungsproblem sofort behoben wurde.
Eine Quelle für Debatten und Überlegungen
Besonders interessant ist, dass dies Debatten und Überlegungen auslöste. Andy Jackson, ein technischer Architekt bei der Digital Preservation Coalition, diskutierte diese Episode in seinem Blog (https://anjackson.net/2023/03/21/speeding-up-format-identification/#signatures-going-wild; https://anjackson.net/2023/03/22/my-format-identification-misunderstandings/). Andy ging auf einen Vorschlag von Martin Hoppenheit (https://martin.hoppenheit.info/blog/2017/minimizing-the-droid-signature-file/) ein, der vorschlug, Signaturdateien je nach Kontext des Kunden „anzupassen“, um die Leistung zu optimieren. Wenn das Archiv eines Kunden beispielsweise nur TIFF- und PNG-Dateien enthält, warum sollten dann andere Formate in die Signaturdateien aufgenommen werden, die die Leistung beeinträchtigen?
Nach einigem Nachdenken kam Andy Jackson zu dem Schluss, dass dies keine gute Idee sei. Ein solcher Ansatz birgt die Gefahr, dass Binär- und Container-Signaturdateien inkompatibel werden (insbesondere bei zukünftigen Updates). Er betonte, dass es in der Verantwortung von Droid liege, Kombinationen zu vermeiden, die einen „Full Scan“ von Dateien verursachen.
Wichtige Erkenntnisse
Hier sind einige Lehren, die ich persönlich aus diesem Korrekturprozess gezogen habe:
- Wenn es in der Phase der Formaterkennung zu einer Verlangsamung kommt, sollten Sie die Lesebandbreite überprüfen und sicherstellen, dass die Dateien während dieses Schritts nicht mehrmals vollständig gelesen werden – das ist selten normal!
- Generell ist die Formaterkennung keine „Zauberei“ und kann kostspielig sein, insbesondere bei großen Dateien. Es ist wichtig, sich dessen bewusst zu sein und den tatsächlichen Nutzen im Kontext des Kundenprojekts zu bedenken.
- Ich war beeindruckt von der Reaktionsfähigkeit der Open-Source-Gemeinschaft für digitale Bewahrung, die die Anomalie des Droiden schnell behoben hat.
- Dank Andrew Jacksons Blog habe ich die Leidenschaft entdeckt, die diese Gemeinschaft antreibt. Dies deckt sich mit meinem Artikel über iPres (https://arcsys-software.com/2024/10/15/feedback-from-fripres22/).
Dieser Artikel verfolgte zwei Ziele. Erstens, den Alltag der Entwicklungsteams eines Softwareherstellers bei der Behebung eines von einem Kunden gemeldeten Leistungsproblems zu beschreiben, und zweitens, die Kraft und das Engagement von Open-Source-Gemeinschaften, insbesondere im Bereich der digitalen Bewahrung, hervorzuheben.
P.S.: Ich möchte mich bei meinem Kollegen Raphaël Lample bedanken, der den größten Teil der in diesem Artikel beschriebenen technischen Untersuchung leitete und die Gemeinschaft auf die Wurzel des Problems führte.
Mikaël MECHOULAM