[Clarence]

Ursprungligen postat av dAEk

Grundproblemet är att du verkar har en lösning som nått sin gräns i sin nuvarande miljö.

Antagligen tar minnet slut när du läser in Xml-filen. Vet inte exakt hur det är i PHP men i andra programmeringsspråk kan det handla om filens storlek * 3 eller 4 för att läsa in hela Xml:ns DOM i minnet. Även om det funkar ibland är det inte hållbart i längden. Vem vill använda ett system där det funkar att ladda upp filer ibland? Vad händer om leverantören börjar leverera en lite större fil? Det du säkerligen behöver kika på är att streama filen. När man gör det läser Xml-parsern in filen en bit i taget och det kräver inte i närheten av samma minnesmängd. Tänk att en stream har en fast minnesförbrukning medan att läsa in hela DOM korrelerar med filens storlek, antalet noder samt innehållet i dessa. Man kan hantera filer filer från några få hundra kilobytes till gigabytes med en stream. Det är med andra ord mer skalbart vad gäller minnesförbrukningen. Det är säkert lite bökigare även i PHP men är det givet om man vill få ett väl fungerande system och inte kan styra över filerna som man läser in.

Timeouterna borde du undersöka vad de beror på. Ett tips är att börja logga dina funktionsanrop när det sker fel (läs exceptions). Finns det stacktrace i PHP är de himla användbara att få med i loggarna eftersom de mer eller mindre berättar vad som gått fel. I dokumentationen för anropen borde du se vilka metoder som kan kasta exceptions och vilka typer det kan handla om.

Det dAEK skriver är väldigt läsvärt och hjälpande. Ville mest bara fylla på med lite mer specifik info.

Den typen av XML parser som brukar användas för streaming i de flesta språk kallas SAX parser. Den är lite jobbigare att komma igång med just pga dess event-baserade modell. Men som vanligt finns det på php.net exempel och ordentligt med dokumentation: se http://www.php.net/manual/en/book.xml.php

Är du säker på att dina XML-filer inte växer och du har en server som klarar av det är det ingen fara att köra ett enklare API som laddar in hela filen. Men annars bör du verkligen titta på att streama parsingen. Jonas exempel med 50->150mb är inte ens så illa som det kan gå, det beror på datamängd vs attribut och nästling hur mycket minne som behövs.

Sedan bara en amärkning på det om en "riktig relationsdatabas" är ju svårt att ta på. Antagligen så menas en relationsdatabas med tabelltyp som stödjer foreign key constraints, då det kan anses vara "riktiga" relationer. Tipset du fått här är dock att använda en transaktion och rollback om den inte gått igenom. Jag skulle vilja varna lite för att använda det på en delad webhost. För det allra mesta får du på dessa mycket bättre och pålitligare prestanda med MyISAM (båda pga att du med innodb "tävlar" med andra kunder om RAM-cachen men även att de ofta brukar vara så dåligt eller sparsamt konfigurerade för innodb) medans det på dedikerade servers/VPS ofta är precis tvärtom. Ett alternativ är att du skriver till en temporär tabell först, kör samma kontroll och sedan rensar tabellen istället för rollback och ersätter den riktiga tabellen istället för commit. Inte fullt lika säkert, men mer konsekvent resultat.

[jonssondesign]

Tack för alla tips! Jag ska kolla på vad jag klarar av att göra, och återkommer om eventuella frågor.

Tack igen!

[dAEk]

Ursprungligen postat av Clarence

Det dAEK skriver är väldigt läsvärt och hjälpande. Ville mest bara fylla på med lite mer specifik info.
[...]

Tack för de vänliga orden.