[SPIP Zone] [Spip-zone-commit] r87939 - _plugins_/extraire_documents/trunk/inc

Hello,

je reviens là-dessus : actuellement il y a donc une vérification de la taille mémoire disponible vs la taille du document pour décider si on tente l’extraction ou pas.

Cette vérification est faite dans la fonction générique inc/extraire_document, mais il me semble que cette question de la mémoire nécessaire est très dépendante de la technologie de l’extracteur ET du format du fichier.

Si je prends l’exemple d’un fichier texte, l’extraction peut se faire par un readfile et ne consommera en mémoire pas plus que 1 fois la taille du fichier.

Idem si j’utilise un parser en ligne de commande : la consommation mémoire lors de l’extraction n’impactera pas PHP qui n’aura à gérer que le stockage en mémoire du contenu texte final. Dans le cas d’un PDF ce texte final peut-être beaucoup plus petit que la taille initiale du fichier.

D’où ma question :
1/ avec quel extracteur ce besoin de 2 à 3 fois la taille du fichier a-t-il été déterminé ?
2/ est-ce qu’on mettrait pas ça dans une fonction générique qui prendrait en argument la mémoire nécessaire et serait appelée éventuellement par chaque extracteur en fonction de son besoin qu’il saura mieux estimer ?

--
Cédric

On 13 mars 2015 à 16:57 +0100, cam.lafit@azerttyu.net, wrote:

Author: cam.lafit@azerttyu.net
Date: 2015-03-13 16:57:29 +0100 (Fri, 13 Mar 2015)
New Revision: 87939

Modified:
_plugins_/extraire_documents/trunk/inc/extraire_document.php
Log:
Avant de traiter le fichier vérifions que nous avons une chance de le traiter

* Le parser des documents doit charger 2 à 3 fois l'équivalent du fichier
* Il ne sert à rien de traiter si on est quasi sur de faire *Max Allowed Memory*

Details: Connexion · GitLab

_______________________________________________
Spip-zone-commit@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone-commit

Salut

Je te dis ça de mémoire, ce n'est plus tout jeune :slight_smile:

C'est le parseur PDF qui demandait ça. Le script extrait plusieurs
fois les données, et grosso modo le ratio était entre 2 et 3 sur le
jeu de test à ma disposition. Cela a été fait sur une base de quelque
milliers de fichiers.

On pourrait basculer ça dans une fonction propre à chaque extracteur.
Le cas pdf n'est pas optimum que ce soit du fait du format en lui même
et du script php utilisé.
Ce serait en effet plus optimum.

Super, merci Camille !
Je me doutais que c’était le parseur PDF, en effet.

J’ai donc modifié dans Connexion · GitLab et Connexion · GitLab en deplaçant le test au niveau de chaque parseur, et je présume que pour Tika on doit pouvoir faire sauter ce test (ou passer à 1x la taille fichier ?) puisque c’est une requette http sur l’API

Au moins en l’état ça ne change rien et on pourra affiner parseur par parseur

--
Cédric

On 20 juin 2018 à 12:21 +0200, cam.lafit@azerttyu.net <cam.lafit@azerttyu.net>, wrote:

Salut

Je te dis ça de mémoire, ce n'est plus tout jeune :slight_smile:

C'est le parseur PDF qui demandait ça. Le script extrait plusieurs
fois les données, et grosso modo le ratio était entre 2 et 3 sur le
jeu de test à ma disposition. Cela a été fait sur une base de quelque
milliers de fichiers.

On pourrait basculer ça dans une fonction propre à chaque extracteur.
Le cas pdf n'est pas optimum que ce soit du fait du format en lui même
et du script php utilisé.
Ce serait en effet plus optimum.