Aller au contenu
Accueil » Actualités » Au cœur du quotidien d’un éditeur logiciel : correction d’un bug de performance de Droid grâce à la communauté de la préservation numérique

Au cœur du quotidien d’un éditeur logiciel : correction d’un bug de performance de Droid grâce à la communauté de la préservation numérique

    Droid est une librairie open source d’identification des formats (https://www.nationalarchives.gov.uk/information-management/manage- information/policy-process/digital-continuity/file-profiling-tool-droid/) quasiment indispensable dans la panoplie de tout logiciel de préservation numérique (voir à ce sujet le guide https://arcsys-software.fr/formats-perennes-votre-guide-pratique/). A ce titre, nous l’intégrons dans le logiciel Arcsys.

    Lorsqu’un client nous a contacté pour nous signaler des performances dégradées pendant la chaîne d’archivage, nous ne soupçonnions pas que cela mènerait à une véritable épopée…qui allait amener les contributeurs de Droid à de longs débats sur les mécanismes d’identifications de certains formats, et bénéficier à toute la communauté !

    A la recherche du maillon faible

    Le client a ouvert un ticket en nous expliquant que le temps d’archivage de ses fichiers était bien trop long par rapport à ses attentes. Il s’agissait de fichiers très volumineux, atteignant plusieurs téraoctets. Mais on constatait qu’ils restaient bloqués pendant plusieurs dizaines d’heures dans une phase de leur traitement qui semblait toujours être la même. Cette phase, c’était…la phase de l’identification de format.

    Evidemment la première question qui s’est posée était : de quels types de fichiers s’agissait-il ? La réponse était qu’il s’agissait exclusivement de fichiers compressés au format ZIP.

    Munis de ces éléments, nous nous sommes attelés à l’incontournable étape que connaît tout développeur logiciel : la reproduction du problème.

    Une bande passante anormale

    Nous avons commencé à lancer l’archivage de fichiers ZIP de plusieurs gigaoctets. Et nous avons vite pu constater d’où venait cette lenteur de traitement. Elle venait bien de l’étape d’identification de format par la librairie Droid. En connectant un outil de profiling Java pour mesurer les bandes passantes de lecture, nous avons pu constater que cette lenteur s’expliquait par la lecture à deux reprises de l’intégralité du fichier !

    Quelle ne fut pas alors notre surprise de découvrir qu’en passant ce fichier sur l’outil « graphique » fourni par Droid pour identifier des fichiers, DroidUI, cette fois seule une partie infime du fichier était lue, en un temps par conséquent beaucoup plus court, pour aboutir au même résultat.

    Ouverture d’une anomalie sur GitHub

    Pourvus de ces données concrètes, nous avons ouvert une demande d’investigation à Droid (https://github.com/digital-preservation/droid/issues/906), tout en continuant nos recherches en parallèle. Nous avons réalisé que tout se jouait dans les combinaisons de « fichiers de signatures binaires et de signatures de container ».

    Pour résumer de façon rapide, pour reconnaître un type de fichier, Droid utilise un fichier de signature binaire qui décrit les séquences spécifiques de bits caractéristiques de chaque format. Mais ce qui complique les choses, c’est qu’il y a aussi des « containers » de fichiers, comme les ZIP…qui ont eux-mêmes leurs fichiers de signatures. Ces fichiers de signature évoluent dans le temps, chacun avec des versions (car les contributeurs y ajoutent des nouveaux formats en permanence par exemple).

    Dans notre cas, nous nous sommes rendu compte que suivant la combinaison de versions fichiers de signatures binaires et de fichiers de signatures de container que nous choisissions, le problème de lenteur ne se produisait plus. C’est pour cela que le client graphique DroidUI n’avait pas l’anomalie, car il n’avait pas la même combinaison !

    Rapidement, nous avons pu, avec la communauté, identifier les entrées précisément problématiques, et l’anomalie a été corrigée, les fichiers de signatures ayant été «nettoyés». En attendant, nous avons fait la modification chez notre client qui, soulagé, a pu immédiatement constater la résolution de son anomalie de performance.

    Une source de débats et de réflexions

    Mais ce qui est intéressant c’est que cela a suscité des débats et des réflexions. Le blog d’Andy Jackson (architecte technique à la Digital Preservation Coalition) est ainsi revenu sur cet épisode( https://anjackson.net/2023/03/21/speeding-up-format-identification/#signatures-going-wild, puis https://anjackson.net/2023/03/22/my- format-identification-misunderstandings/). Andy Jackson a ainsi réfléchi à une suggestion qui avait été faite par Martin Hoppenheit (https://martin.hoppenheit.info/blog/2017/minimizing-the-droid-signature-file/), consistant à « personnaliser » les fichiers de signatures suivant le contexte client pour optimiser les performances : si on sait qu’un client n’a que des fichiers TIFF et PNG dans son fonds d’archive, pourquoi laisser d’autres formats dans les fichiers de signatures, pénalisant ainsi les performances d’identification ? Pour Andy Jackson, après réflexion cela n’est pas forcément une bonne idée. En effet ce choix présente le risque de rendre les fichiers de signatures binaires et de container incompatibles (on peut penser aux futures mises à jour). Enfin, il a surtout mis en avant le fait que c’était à Droid d’éviter les combinaisons qui engendraient un «full scan » des fichiers.

    Quelques enseignements

    Je vous livre ci-dessous les quelques enseignements que j’ai personnellement tirés de ce processus de correction.

    • Si une lenteur se produit dans la phase d’identification de formats, il faut se pencher sur les bandes passantes de lecture et vérifier qu’on ne se retrouve pas avec des fichiers lus entièrement à plusieurs reprises lors de cette étape, ce qui est rarement normal !
    • Plus généralement, l’identification de formats n’est pas « magique » et peut représenter un coût important, surtout si les fichiers à identifier sont volumineux. Il faut en avoir conscience et réfléchir à son utilité réelle dans le contexte du projet client.
    • J’ai été impressionné par la réactivité de la communauté open source de la préservation numérique qui a su rapidement corriger l’anomalie de Droid.
    • J’ai pu découvrir la passion qui anime cette communauté, grâce au blog rédigé par Andrew Jackson. Cela rejoint mon article sur iPres (https://arcsys- software.fr/2024/10/15/fripres-2024-le-retour-dexperience/)

    Ce témoignage avait deux objectifs. Tout d’abord, vous décrire le quotidien des équipes de développement d’un éditeur logiciel en corrigeant un problème de performance détecté chez un client, et ensuite, vous montrer la puissance et l’engagement des communautés Open source, notamment celle de la préservation numérique.

    PS : je tiens à remercier ici mon collègue Raphaël Lample qui a mené l’essentiel de l’investigation technique décrite dans cet article, et a « aiguillé » la communauté vers l’origine du problème.

    Mikaël MECHOULAM