Bonjour,
 
Je suis en train de développer une appli PHP dont le but est de traiter des données provenant de fichiers TXT pour les convertir en CSV. Je vous passe les détails...
 
Le problème que j'ai est que ces fichiers TXT peuvent être très gros (60Mo), et PHP sature généralement en mémoire. J'ai 512Mo de dispo sur les PC sur lesquels je travaille, et en poussant la limite de PHP à 420Mo, je traite tout juste des fichiers de 18Mo. Cela m'oblige à découper les fichiers TXT et les traiter séparément, pour ensuite regrouper les données, ce n'est pas vraiment pratique.
 
Ce que j'aimerais faire, est que je puisse sélectionner un gros fichier texte, et lorsque PHP atteint sa limite (que ce soit en temps, en mémoire ou en taille), alors il interrompt le traitement et demande d'appuyer sur un bouton pour poursuivre le traitement de la suite du fichier texte.
J'ai vu ce fonctionnement il y a peu sur PHPMyAdmin (lors d'un import de fichier contenant des requêtes), et j'ai été assez convaincu.
 
Cela dit, je ne vois pas trop comment m'y prendre pour reproduire le même système.
Avez-vous des idées là-dessus, voire une solution ?
 
Merci bien !
 
++

hello, les données sont de quelle type dans ton fichier txt ?

Quand tu lit ton fichier tu utilise quel méthode  
- chargement complet du fichier en mémoire ?
- lecture par bloc ?

Bonjour,
 
Les fichiers texte sont des exports de captures de Wireshark, un logiciel permettant de capturer le trafic sur un réseau. Par exemple :
 

 
Il y a des milliers de ces messages dans chaque fichier texte.
Le but final étant d'établir des statistiques, je commence par créer un fichier CSV contenant les données décodées dont j'ai besoin à partir des messages du fichier texte.
 
Merci.

Pardon, je n'avais pas vu le message de stef_doberman en postant...
 
Je lis par bloc, en déterminant par avant la longueur de la plus grande ligne du fichier et en utilisant cette longueur pour la lecture.
A chaque ligne lue, je remplis un array, et je finis par un fputcsv de chaque ligne de l'array.
 
++

wireshark enregistre direct en csv

Donc tu stock chaque ligne en mémoire ?
si ta réponse est oui, alors arrête, tu sais ou ce trouve ton problème de RAM.
solution (ou partie) traite chaque ligne puis écrit directement dans ton fichier de destination en faisant juste une ouverture du fichier au début de ton script et la fermeture à la fin.
j'ai utilisé cette technique sur des fichiers de bonne taille (3Mo de txt) et ça tourne correctement.

 
Seulement les entêtes, pas les données, malheureusement
 

 
OK, je tente ça, je vous tiens au courant

juste par curiosité, comment tu fait pour interpréter le fichier, enfin faire des stats dessus ?

 
Après avoir créé le CSV (qui contient des données décodées, donc pas de l'héxa), je place tout dans un array et utilise majoritairement des boucles pour compter les cas qui m'intéressent en parcourant l'array. Je me demande d'ailleurs si c'est la meilleure méthode...
 
Sinon, les premiers résultats suite à ta réponse sont assez convaincants
Le plus long est maintenant l'export en TXT depuis Wireshark, lol...
 
Merci !
 
++

ensuite pour optimiser plus tu peux aussi directement faire l'insertion en BDD sans passer par le fichier csv...
Edit : en faite ce que je voulais savoir, même après décodage, l'analyse à quel but ? les données analysé représente quoi ?
un analyse de trame ça j'ai compris mais c'est quoi la finalité ?

Ouep, j'y ai pensé, mais je préfère éviter tant que je suis +/- en période de tests et que la gestion du CSV seul n'est pas encore parfaite ; mais c'est certainement ce que je ferai à terme.

Pour info, j'ai codé en php un programme de stats qui manipule des matrices de grosse taille (genre 3500x5000). Le stockage des matrices est effectué dans MySQL. Certains calculs aussi (du reste, faire du calcul matriciel avec MySQL, c'est assez fun ). Par contre, à un moment, je dois calculer le produit d'une matrice par sa transposée. Là, MySQL est trop lent : je fais un export en CSV de la matrice puis de sa transposée (ça me fait 2 fichiers d'environ 300 Mo!) et j'utilise un petit exe codé en C et basé sur la lib GSL pour calculer le produit. Le résultat est un CSV qui j'importe ensuite dans MySQL. Ca prend 10 mins pour faire toutes ces opérations Tout ça pour dire que quand faut manipuler de grosses données, un SGBD peut se montrer bien plus performant que php.

OK. Vu que l'appli est certainement destinée à être développée plus profondément dans le futur, je passerai par une base MySQL
 
Merci des infos !

c'est cool, mais ca sert à quoi ? quel en est le but final ?
je sais que je suis lourd...

t'a choisies quelles options au moment de ton export ?

 
Le but final est vraiment un but de statistiques, dans le but d'envisager la mise à jour d'un système à mon boulot.
 

 
Il n'y a pas de réglage d'option dispo lors de l'export en CSV : le seul qui est accessible (la liste déroulante "as displayes", "all collapsed" ou "all expanded" ) n'a aucun effet sur le fichier exporté

je parlais pas du CSV mais de ton export type txt, ta regarder du coté du pdml ? ca serais plus simple de parser

 
En TXT, j'exporte toutes les indos de tous les paquets en héxa.
 
Si tu as des infos sur le PDML, je suis preneur, notamment sur leur traitement en PHP : j'y avais jeté un œil mais comme je ne connaissais pas et que j'avais besoin que ça fonctionne rapidement (même si l'appli était lente), je ne me suis pas plus penché dessus. Maintenant que j'ai un peu plus de temps pour la peaufiner, passer par un autre format pourrait être envisageable...

la PDML c'est du XML, donc du parcourir ton arbre par paquet et tu récupère les info que tu veux

 
OK, mais je n'ai jamais fait non plus de traitement de XML. N'est-ce pas plus long ? N'est-on pas obligé de tout stocker en mémoire ?

Tiens, je connaissais pas PDML, ça a l'air pas mal du tout et assez puissant

regarde d'hab si y'a toute les info que tu veux dedan, apres ton XML est convertis direct en Array donc tu fais ton traitement, tu peux meme direct prendre uniquement les donnée qui t'intéresse (par exemple prendre que les Ip qui se sont connectés via UDP)

Si t'utilise un parser SAX et pas DOM, tu peut parser un XML de 10To si tu veux sans consommer plus que quelques Ko.
 
Par contre faut interpréter les données à la volée.

Bonjour,
 
Désolé, mais n'ayant jamais touché au XML, me parler de "parser SAX ou DOM", c'est me parler en chinois

 
Il me semblait que DOM chargeait en entier le fichier xml en mémoire?

 
Google est ton ami. Ne pas savoir n'est pas un pb. Ne pas chercher à savoir quand on en a besoin, ça, c'est un pb