29/12/12 17:50
Welke alternatieven zijn er voor het uitlezen van grote XML-files, zonder tegen geheugen problemen aan te lopen?
Het verhogen van 'memory_limit' is niet altijd mogelijk.
Het gebruik van de constante LIBXML_PARSEHUGE kan pas vanaf Libxml >= 2.7.0 (as of PHP >= 5.3.2 and PHP >= 5.2.12)
http://nl3.php.net/manual/en/libxml.constants.php
Ook al geprobeerd om met fread kleinere delen in te lezen. Dit heeft als gevolg dat het gedeelte afbreekt midden in een regel.
29/12/12 18:01
Je zult als programmeur altijd rekening moeten houden met de hardware. Je kunt niet (altijd) van je afnemer verwachten dat het script wordt geïnstalleerd op een dedicated server met 64GB aan vrij te gebruiken geheugen. Soms is er slechts 512MB (of zelfs minder) voorhanden. Al gedacht om het bestand eerst lokaal te uploaden en er daarna bewerkingen op te laten uitvoeren?
DreamHost.nl Web hosting - cPanel hosting om bij weg te dromen.
29/12/12 18:09
Dat klopt. Daarom dat ik al aangaf dat de opties van de parameter memory_limit en de constante LIBXML_PARSEHUGE niet (altijd) mogelijk zijn.
De te verwerken xml-file ligt al lokaal.
Heb ook kleinere delen met de php functie fread ingelezen. Dit gaat goed zolang er niet halverwege afgebroken worden door het limiet dat je aan fread meegegeven hebt.
29/12/12 18:19
De betreffende PHP versies (of nieuwer) lijken mij te eisen voor iets dat nieuw ontwikkeld wordt. Heb je al gedacht aan de optie om met fread blokken in te lezen en vervolgens te zoeken naar </iets> en zo te bepalen tot waar je in die keer verwerkt en de rest daarna mee te nemen in de volgende keer? Het is mogelijk even denken, maar iets dergelijks zou mogelijk moeten zijn (en 4mb geheugen lijkt mij wel te eisen vandaag de dag). Dan kun je hoogstens met zeer lange blokken zonder dat deze afgesloten worden een probleem hebben.
Waar je in de XML zit zul je natuurlijk ook moeten bepalen en ergens moeten verwerken om de structuur te bewaren ook als je maar een deel van het XML bestand hebt, dit kan echter een structuur zonder "overbodige" inhoud zijn.
Tools die handig zjn voor ISPs vind je natuurlijk bij Tools 4 ISP.
29/12/12 19:01
Als je zegt grote xml-files. Over welke formaten hebben we 't dan?
29/12/12 20:42
Dat moet je via http://nl3.php.net/xml doen.
29/12/12 21:35
Inplaats van fread kan je ook fgets gebruiken, die gaat door tot het einde van de regel als je geen lengte opgeeft.
Als je de xml bestanden zelf genereert of beschikbaar stelt dan is het het makkelijkst hem op te delen in kleinere bestanden.
30/12/12 09:01
Dat is inderdaad degene die je moet hebben. Niet exact de gemakkelijkste in gebruik, maar is wel de enige die geschikt is voor grote bestanden. Hij zal de file stuk voor stuk sequentieel inlezen en bij elke open en close tag (of bij een content deel) een callback functie aanroepen. Je moet dus zelf bij houden waar je ergens in je tree zit.Oorspronkelijk geplaatst door systemdeveloper
30/12/12 14:42
Dat is een slimmere optie inderdaad. Je kunt het zelf wel na gaan doen als je niet van deze PHP optie gebruikt wenst te maken.
overigens is het handiger om nl.php.net te gebruiken ipv nl3.php.net, deze eerste link is stabieler en verwijst naar alle php.net mirrors in Nederland.
Tools die handig zjn voor ISPs vind je natuurlijk bij Tools 4 ISP.
01/01/13 20:19
Aller eerst de beste wensen voor iedereen.
Bedankt voor jullie reacties. Ik zal er mee aan de slag gaan.
01/01/13 21:38
Wat is groot? Ik heb nog leuke snelle scripts liggen.
01/01/13 22:04
Het gaat om bestanden van verschillende omvang, tot ongeveer 70MB als grootste.
02/01/13 21:14
De oorzaak is gevonden. Heeft niet te maken met het uitlezen van de xml-file zelf, maar bij de verdere verwerking. Hierbij word een multi-dimensionaal array gebruikt die uiteindelijk te veel geheugen nodig heeft.
Likes: 
Quote