Discussion :

[El Riiico]

Bonjour,

Je travaille un framework perso qui lance des opérations php de maintenance en cron.

Certaines opérations réclament plus de mémoire que celle configurée par défaut (8 Mo si je me souviens bien), j'ai placé @ini_set('memory_limit', '500M'); dans le __construct de mes classes de maintenance.


Je n'avais jamais eu trop de problèmes avec ça.

Jusqu'ici.


Parce qu'avec le succès de mon site (Youpi !), j'ai dû commencer à développer des exports de notre base avec nos partenaires sous forme fichiers XML (oui, un web service est aussi en dév).


Tous les matins, je fais un dumb de mes données dans un fichier XML qui me sert de référence. Là, pas de problème.
Seulement ensuite, comme chacune de nos passerelles partenaires demande un format spécifique (sinon ce serait pas drôle) :

• Je charge avec simplexml_load_file() le fichier le fichier XML de référence (plusieurs centaines de milliers d'enregistrements)
• Je scanne le fichier en mémoire avec un foreach
• Je transforme chaque enregistrement en fonction des besoins et je forme progressivement le fichier XML à envoyer

Et là problème : la consommation de mémoire du processus Php lancé (en cron donc, pas par Apache) est telle que le serveur entier plante lamentablement.
Il faut dire que mon système en place demande de charger en mémoire à la fois le fichier de référence (qu'il faut bien parcourir) et le fichier d'export (en cours de construction).
Ca fait une sacrée consommation de mémoire.

Mes Questions :

• Est-il possible de scanner (ou de construire) un fichier XML sans placer son contenu en mémoire ?
• Mettons que je réduise le memory_limit de 500M à 32M. Quand le script Php aura besoin de plus (ce sera ici le cas), va-t'il y a voir un plantage ou Php va-t'il ruser (en utilisant le DD pour compenser par exemple) ?
• Ma méthodologie, mes fonctions utilisées sont-elles mauvaises ?
• Et vous, pour ce genre d'opération d'export, vous faites comment, vous ?

[kaymak]

Salut,

Est-il possible de scanner (ou de construire) un fichier XML sans placer son contenu en mémoire ?

A priori XMLReader, ou XML serait plus aproprié que simpleXML pour ton problème.
cf
http://fr2.php.net/manual/fr/ref.xmlreader.php
http://fr2.php.net/manual/fr/ref.xml.php

Ce sont deux parseurs qui analysent le fllux au fur et à mesure. Ce que dom ne fait pas (simpleXML à l'air de fonctionner comme DOM, mais pas moyen d'avoir la confirmation dans la doc...). Puisque celui ci charge l'intégralité du document, l'analyse et enfin te fournit un objet pour travailler avec ton document XML.

Mettons que je réduise le memory_limit de 500M à 32M. Quand le script Php aura besoin de plus (ce sera ici le cas), va-t'il y a voir un plantage ou Php va-t'il ruser (en utilisant le DD pour compenser par exemple) ?

Malheureusement non. PHP n'à pas la charge de ce type d'opération. la swap est réalisé de manière transparente par le système afin de palier le manque de mémoire vive dispo.
Donc une fois dépassé la limite, c'est fichu. Que se soit de la swap ou non.

Ma méthodologie, mes fonctions utilisées sont-elles mauvaises ?

Mauvaise, non, sa a fonctionné pendant un temps.
Par contre elle semble inadapté à tes nouveaux besoins, c'est certain.

Et vous, pour ce genre d'opération d'export, vous faites comment, vous ?

Je n'ai personnellement jamais rencontré ce genre de problèmatique jusqu'à présent. En tout cas pas au point de saturer la mémoire à un tel point.

Mais par rapport à ce que décris ton poste, le flux xml à fournir semble être sauvegarder dans un objet, ou une chaine.
Et lorsque le flux est complétement généré, il est alors écrit dans un fichier.

Par rapport à cela, peut être pourrais tu écrire plus souvent dans ton fichier afin de libérer la mémoire.
Et puis comme je te le proposais plus haut utiliser XMLReader.


Sinon une solution comme une autre, mais qui ne me semble pas très perreine.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

ini_set("memory_limit",-1);

bye

[s.n.a.f.u]

Et là problème : la consommation de mémoire du processus Php lancé (en cron donc, pas par Apache) est telle que le serveur entier plante lamentablement.
Il faut dire que mon système en place demande de charger en mémoire à la fois le fichier de référence (qu'il faut bien parcourir) et le fichier d'export (en cours de construction).
Ca fait une sacrée consommation de mémoire.

Quand tu parles de serveur, c'est le serveur web ou la machine serveur ?

Mes Questions :

• Ma méthodologie, mes fonctions utilisées sont-elles mauvaises ?
• Et vous, pour ce genre d'opération d'export, vous faites comment, vous ?

Je répondrais (plus ou moins au deux).
Est-ce que c'est mauvais, très honnêtement, je n'en sais rien. Je n'ai pas les compétences pour juger ta façon de faire en php, je n'ai même pas tout compris.
Est-ce que je ferais autrement ? Oui.
A mon avis, php n'est pas fait pour ces tâches de maintenance récurrentes.
Tu es sur Unix/Linux, tu cherches de la performance pour traiter de gros volumes de données : Perl est-là pour toi. Ou Python, qui a des fonctions de bdd berkeley intéressantes (les shelves) qui pourraient résoudre ton problème mémoire. Mais contrairement à Perl, Python est encore assez rarement installé par défaut.

[JeitEmgie]

Bonjour,

• Je charge avec simplexml_load_file() le fichier le fichier XML de référence (plusieurs centaines de milliers d'enregistrements)
• Je scanne le fichier en mémoire avec un foreach
• Je transforme chaque enregistrement en fonction des besoins et je forme progressivement le fichier XML à envoyer

et tout cela ne serait-il pas un bon candidat pour une transformation XSLT ?

y avait-il une raison pour partir en PHP et éviter XSLT ?

[s.n.a.f.u]

y avait-il une raison pour partir en PHP et éviter XSLT ?

Bah parce qu'il ne va pas faire le boulot des sites abonnés qui auront chacun une transformation XSLT propre à leurs besoins. Il me semble que le fichier XML doit être en place pour y appliquer une transfo XSLT. Donc ce fichier doit quand même être extrait.
De plus, s'il y a déjà des problèmes de perf pour établir le fichier XML, il ne faut pas en rajouter avec un processus XSLT par dessus.

[JeitEmgie]

Bah parce qu'il ne va pas faire le boulot des sites abonnés qui auront chacun une transformation XSLT propre à leurs besoins.

le coût du travail sera essentiellement la première transformation : en XSLT le plus délicat est souvent le parcours de la source, une fois celui-ci au point, faire varier l'output est généralement d'un ordre de grandeur moins coûteux…

Il me semble que le fichier XML doit être en place pour y appliquer une transfo XSLT. Donc ce fichier doit quand même être extrait.

et ce n'est pas la partie qui lui pose problème :

Tous les matins, je fais un dumb de mes données dans un fichier XML qui me sert de référence. Là, pas de problème.

cela ne change donc rien à la question : le problème concerne le passage d'un format XML à l'autre…

De plus, s'il y a déjà des problèmes de perf pour établir le fichier XML, il ne faut pas en rajouter avec un processus XSLT par dessus.

vous croyez vraiment que "xsltproc" est moins efficace que simpleXML dans un job PHP aussi bien en CPU qu'en mémoire ?