info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
XML speicherschonend analysieren
2 views
Skip to first unread message
Stefan Froehlich
Jun 7, 2022, 5:04:04 AM6/7/22
to
Ich habe ein paar Klassen, die unterschiedliche XML-Standards
erkennen (und in Abhängigkeit davon dann die passende
Weiterverarbeitung anstoßen, teilweise in PHP, teilweise extern).
Das läuft über DOMDocument und relativ simpel durch Abfrage der
obersten Elemente, Attribute u/o Namespaces.
Gerade eben ist mir einer dieser Jobs um die Ohren geflogen mit:
| Allowed memory size of 12582912000 bytes exhausted (tried to allocate 13801920612 bytes)
Für den konkreten Fall habe ich das Speicherlimit halt von 12
auf 15GB erhöht - aber es ist abzusehen, dass auch das über kurz
oder lang gesprengt werden wird, und irgendwann kommen dann
physikalische Grenzen.
Und jetzt? Von DOMDocument auf Stringverarbeitung umstellen, die
ersten paar kB einlesen und mit regulären Ausdrücken darauf
herumhacken? So unelegant war die Software schon einmal, dorthin
möchte ich nur ungern zurück.
Gibt es Alternativen, die auf XML-Dokumenten arbeiten können, ohne
das Dokument vollständig im Speicher halten zu müssen?
Servus,
Stefan
--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike
Nur bezierpsen ist gehängter als küssen! Stefan: Für alte Gauner!
(Sloganizer)
erkennen (und in Abhängigkeit davon dann die passende
Weiterverarbeitung anstoßen, teilweise in PHP, teilweise extern).
Das läuft über DOMDocument und relativ simpel durch Abfrage der
obersten Elemente, Attribute u/o Namespaces.
Gerade eben ist mir einer dieser Jobs um die Ohren geflogen mit:
| Allowed memory size of 12582912000 bytes exhausted (tried to allocate 13801920612 bytes)
Für den konkreten Fall habe ich das Speicherlimit halt von 12
auf 15GB erhöht - aber es ist abzusehen, dass auch das über kurz
oder lang gesprengt werden wird, und irgendwann kommen dann
physikalische Grenzen.
Und jetzt? Von DOMDocument auf Stringverarbeitung umstellen, die
ersten paar kB einlesen und mit regulären Ausdrücken darauf
herumhacken? So unelegant war die Software schon einmal, dorthin
möchte ich nur ungern zurück.
Gibt es Alternativen, die auf XML-Dokumenten arbeiten können, ohne
das Dokument vollständig im Speicher halten zu müssen?
Servus,
Stefan
--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike
Nur bezierpsen ist gehängter als küssen! Stefan: Für alte Gauner!
(Sloganizer)
Stefan Froehlich
Jun 7, 2022, 5:37:36 AM6/7/22
to
On Tue, 07 Jun 2022 11:04:01 Stefan Froehlich wrote:
> Gerade eben ist mir einer dieser Jobs um die Ohren geflogen mit:
>
> | Allowed memory size of 12582912000 bytes exhausted (tried to allocate 13801920612 bytes)
> Für den konkreten Fall habe ich das Speicherlimit halt von 12 auf
> 15GB erhöht - aber es ist abzusehen, dass auch das über kurz oder
> lang gesprengt werden wird, und irgendwann kommen dann
> physikalische Grenzen.
Die nächste Grenze kam noch während des Absenden des letzten
> Gerade eben ist mir einer dieser Jobs um die Ohren geflogen mit:
>
> | Allowed memory size of 12582912000 bytes exhausted (tried to allocate 13801920612 bytes)
> Für den konkreten Fall habe ich das Speicherlimit halt von 12 auf
> 15GB erhöht - aber es ist abzusehen, dass auch das über kurz oder
> lang gesprengt werden wird, und irgendwann kommen dann
> physikalische Grenzen.
Postings:
| DOMDocument::loadXML(): Input string is too long in [...]
Offenbar habe ich DOMDocument fertig durchgespielt :-(
Servus,
Stefan
--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike
(Sloganizer)
Karl Pflästerer
Jun 7, 2022, 6:20:01 AM6/7/22
to
Stefan...@Froehlich.Priv.at (Stefan Froehlich) writes:
> On Tue, 07 Jun 2022 11:04:01 Stefan Froehlich wrote:
>> Gerade eben ist mir einer dieser Jobs um die Ohren geflogen mit:
>>
>> | Allowed memory size of 12582912000 bytes exhausted (tried to allocate 13801920612 bytes)
>
>> Für den konkreten Fall habe ich das Speicherlimit halt von 12 auf
>> 15GB erhöht - aber es ist abzusehen, dass auch das über kurz oder
>> lang gesprengt werden wird, und irgendwann kommen dann
>> physikalische Grenzen.
>
> Die nächste Grenze kam noch während des Absenden des letzten
> Postings:
>
> | DOMDocument::loadXML(): Input string is too long in [...]
>
> Offenbar habe ich DOMDocument fertig durchgespielt :-(
Muss es denn DOM sein? DOM hat das gesamte Dokument im Speicher.
> On Tue, 07 Jun 2022 11:04:01 Stefan Froehlich wrote:
>> Gerade eben ist mir einer dieser Jobs um die Ohren geflogen mit:
>>
>> | Allowed memory size of 12582912000 bytes exhausted (tried to allocate 13801920612 bytes)
>
>> Für den konkreten Fall habe ich das Speicherlimit halt von 12 auf
>> 15GB erhöht - aber es ist abzusehen, dass auch das über kurz oder
>> lang gesprengt werden wird, und irgendwann kommen dann
>> physikalische Grenzen.
>
> Die nächste Grenze kam noch während des Absenden des letzten
> Postings:
>
> | DOMDocument::loadXML(): Input string is too long in [...]
>
> Offenbar habe ich DOMDocument fertig durchgespielt :-(
Mit https://www.php.net/manual/en/class.xmlreader.php bearbeiten wir
auch sehr große XML Dokumente; diese Klasse ist deutlich
speicherschonender. Der Ansatz ist (IMHO) schöner als SAX. das wäre dann
mein nächster Vorschlag: https://www.php.net/manual/en/book.xml.php
Auch mit SAX kannst du nahezu beliebig große Dokumente verarbeiten.
KP
Stefan Froehlich
Jun 7, 2022, 7:16:52 AM6/7/22
to
On Tue, 07 Jun 2022 12:19:59 Karl Pflästerer wrote:
> Stefan...@Froehlich.Priv.at (Stefan Froehlich) writes:
>> On Tue, 07 Jun 2022 11:04:01 Stefan Froehlich wrote:
>> | DOMDocument::loadXML(): Input string is too long in [...]
>>
>> Offenbar habe ich DOMDocument fertig durchgespielt :-(
> Muss es denn DOM sein?
Müssen nicht, es ist vor allem eine Frage der Bequemlichkeit: Im
> Stefan...@Froehlich.Priv.at (Stefan Froehlich) writes:
>> On Tue, 07 Jun 2022 11:04:01 Stefan Froehlich wrote:
>> | DOMDocument::loadXML(): Input string is too long in [...]
>>
>> Offenbar habe ich DOMDocument fertig durchgespielt :-(
> Muss es denn DOM sein?
Lauf der Jahre habe ich die gesamte Infrastruktur darauf umgestellt,
das ist inzwischen ein wesentlicher Bestandteil einner
Klassenhierarchie zur Analyse weitgehend beliebiger Files.
Nützt aber nichts, wird sich ändern müssen.
> Mit https://www.php.net/manual/en/class.xmlreader.php bearbeiten
> wir auch sehr große XML Dokumente; diese Klasse ist deutlich
> speicherschonender. Der Ansatz ist (IMHO) schöner als SAX. das
> wäre dann mein nächster Vorschlag:
> https://www.php.net/manual/en/book.xml.php
ja auch nur für die Formaterkennung, die Verarbeitung so großer
Files erfolgt dann eh durch eigene CLI-Programme, mit PHP würde das
ewig und ein Jahr dauern.
Servus,
Stefan
--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike
(Sloganizer)
Arno Welzel
Jun 8, 2022, 8:03:26 AM6/8/22
to
Stefan Froehlich:
> Ich habe ein paar Klassen, die unterschiedliche XML-Standards
> erkennen (und in Abhängigkeit davon dann die passende
> Weiterverarbeitung anstoßen, teilweise in PHP, teilweise extern).
> Das läuft über DOMDocument und relativ simpel durch Abfrage der
> obersten Elemente, Attribute u/o Namespaces.
>
> Gerade eben ist mir einer dieser Jobs um die Ohren geflogen mit:
>
> | Allowed memory size of 12582912000 bytes exhausted (tried to allocate 13801920612 bytes)
>
> Für den konkreten Fall habe ich das Speicherlimit halt von 12
> auf 15GB erhöht - aber es ist abzusehen, dass auch das über kurz
> oder lang gesprengt werden wird, und irgendwann kommen dann
> physikalische Grenzen.
Was nicht überraschend ist, wenn das zugrundeliegende Dokument
entsprechend umfangreich ist.
> Und jetzt? Von DOMDocument auf Stringverarbeitung umstellen, die
> ersten paar kB einlesen und mit regulären Ausdrücken darauf
> herumhacken? So unelegant war die Software schon einmal, dorthin
> möchte ich nur ungern zurück.
>
> Gibt es Alternativen, die auf XML-Dokumenten arbeiten können, ohne
> das Dokument vollständig im Speicher halten zu müssen?
Am ehesten das hier: <https://www.php.net/manual/en/book.xmlreader.php>
Siehe auch:
<https://stackoverflow.com/questions/911663/parsing-huge-xml-files-in-php>
--
Arno Welzel
https://arnowelzel.de
> Ich habe ein paar Klassen, die unterschiedliche XML-Standards
> erkennen (und in Abhängigkeit davon dann die passende
> Weiterverarbeitung anstoßen, teilweise in PHP, teilweise extern).
> Das läuft über DOMDocument und relativ simpel durch Abfrage der
> obersten Elemente, Attribute u/o Namespaces.
>
> Gerade eben ist mir einer dieser Jobs um die Ohren geflogen mit:
>
> | Allowed memory size of 12582912000 bytes exhausted (tried to allocate 13801920612 bytes)
>
> Für den konkreten Fall habe ich das Speicherlimit halt von 12
> auf 15GB erhöht - aber es ist abzusehen, dass auch das über kurz
> oder lang gesprengt werden wird, und irgendwann kommen dann
> physikalische Grenzen.
entsprechend umfangreich ist.
> Und jetzt? Von DOMDocument auf Stringverarbeitung umstellen, die
> ersten paar kB einlesen und mit regulären Ausdrücken darauf
> herumhacken? So unelegant war die Software schon einmal, dorthin
> möchte ich nur ungern zurück.
>
> Gibt es Alternativen, die auf XML-Dokumenten arbeiten können, ohne
> das Dokument vollständig im Speicher halten zu müssen?
Siehe auch:
<https://stackoverflow.com/questions/911663/parsing-huge-xml-files-in-php>
--
Arno Welzel
https://arnowelzel.de
Stefan Froehlich
Jun 9, 2022, 6:26:04 AM6/9/22
to
On Tue, 07 Jun 2022 13:16:50 Stefan Froehlich wrote:
> On Tue, 07 Jun 2022 12:19:59 Karl Pflästerer wrote:
>> Mit https://www.php.net/manual/en/class.xmlreader.php bearbeiten
>> wir auch sehr große XML Dokumente; diese Klasse ist deutlich
>> speicherschonender. Der Ansatz ist (IMHO) schöner als SAX. das
>> wäre dann mein nächster Vorschlag:
>> https://www.php.net/manual/en/book.xml.php
> Merci, da wird sich hoffentlich etwas machen lassen; ich brauche es
> ja auch nur für die Formaterkennung, die Verarbeitung so großer
> Files erfolgt dann eh durch eigene CLI-Programme, mit PHP würde das
> ewig und ein Jahr dauern.
War dann gar nicht einmal so kompliziert, danke. Ein komplettes
> On Tue, 07 Jun 2022 12:19:59 Karl Pflästerer wrote:
>> Mit https://www.php.net/manual/en/class.xmlreader.php bearbeiten
>> wir auch sehr große XML Dokumente; diese Klasse ist deutlich
>> speicherschonender. Der Ansatz ist (IMHO) schöner als SAX. das
>> wäre dann mein nächster Vorschlag:
>> https://www.php.net/manual/en/book.xml.php
> Merci, da wird sich hoffentlich etwas machen lassen; ich brauche es
> ja auch nur für die Formaterkennung, die Verarbeitung so großer
> Files erfolgt dann eh durch eigene CLI-Programme, mit PHP würde das
> ewig und ein Jahr dauern.
Dokument möchte ich damit nicht parsen müssen, dafür ist es mir zu
rustikal; zur Formaterkennung reicht es aber ganz ausgezeichnet.
Servus,
Stefan
--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike
(Sloganizer)
Karl Pflästerer
Jun 10, 2022, 4:50:57 AM6/10/22
to
Stefan...@Froehlich.Priv.at (Stefan Froehlich) writes:
> On Tue, 07 Jun 2022 13:16:50 Stefan Froehlich wrote:
>> On Tue, 07 Jun 2022 12:19:59 Karl Pflästerer wrote:
>>> Mit https://www.php.net/manual/en/class.xmlreader.php bearbeiten
>>> wir auch sehr große XML Dokumente; diese Klasse ist deutlich
>>> speicherschonender. Der Ansatz ist (IMHO) schöner als SAX. das
>>> wäre dann mein nächster Vorschlag:
>>> https://www.php.net/manual/en/book.xml.php
>
>> Merci, da wird sich hoffentlich etwas machen lassen; ich brauche es
>> ja auch nur für die Formaterkennung, die Verarbeitung so großer
>> Files erfolgt dann eh durch eigene CLI-Programme, mit PHP würde das
>> ewig und ein Jahr dauern.
>
> War dann gar nicht einmal so kompliziert, danke. Ein komplettes
> Dokument möchte ich damit nicht parsen müssen, dafür ist es mir zu
> rustikal; zur Formaterkennung reicht es aber ganz ausgezeichnet.
Da sieht man, wie sich die Geschmäcker unterscheiden. Bei DOM stellen
> On Tue, 07 Jun 2022 13:16:50 Stefan Froehlich wrote:
>> On Tue, 07 Jun 2022 12:19:59 Karl Pflästerer wrote:
>>> Mit https://www.php.net/manual/en/class.xmlreader.php bearbeiten
>>> wir auch sehr große XML Dokumente; diese Klasse ist deutlich
>>> speicherschonender. Der Ansatz ist (IMHO) schöner als SAX. das
>>> wäre dann mein nächster Vorschlag:
>>> https://www.php.net/manual/en/book.xml.php
>
>> Merci, da wird sich hoffentlich etwas machen lassen; ich brauche es
>> ja auch nur für die Formaterkennung, die Verarbeitung so großer
>> Files erfolgt dann eh durch eigene CLI-Programme, mit PHP würde das
>> ewig und ein Jahr dauern.
>
> War dann gar nicht einmal so kompliziert, danke. Ein komplettes
> Dokument möchte ich damit nicht parsen müssen, dafür ist es mir zu
> rustikal; zur Formaterkennung reicht es aber ganz ausgezeichnet.
sich mir immer die Nackenhaare auf; es ist für meinen Geschmack zu
javaesque. Wer Lisp kennt, weiß, wie man auf Bäume auch einacher
zugreifen kann.
Mein Lieblings-Rant dazu
http://harmful.cat-v.org/software/xml/s-exp_vs_XML (Erik Naggum schrieb
sehr pointiert, was nicht jedem gefällt)
KP
Stefan Froehlich
Jun 10, 2022, 6:15:09 AM6/10/22
to
On Fri, 10 Jun 2022 10:50:55 Karl Pflästerer wrote:
> Stefan...@Froehlich.Priv.at (Stefan Froehlich) writes:
>> On Tue, 07 Jun 2022 13:16:50 Stefan Froehlich wrote:
>>> On Tue, 07 Jun 2022 12:19:59 Karl Pflästerer wrote:
>>>> Mit https://www.php.net/manual/en/class.xmlreader.php bearbeiten
>>>> wir auch sehr große XML Dokumente; diese Klasse ist deutlich
>>>> speicherschonender. Der Ansatz ist (IMHO) schöner als SAX. das
>>>> wäre dann mein nächster Vorschlag:
>>>> https://www.php.net/manual/en/book.xml.php
>>> Merci, da wird sich hoffentlich etwas machen lassen; ich brauche
>>> es ja auch nur für die Formaterkennung, die Verarbeitung so
>>> großer Files erfolgt dann eh durch eigene CLI-Programme, mit PHP
>>> würde das ewig und ein Jahr dauern.
>> War dann gar nicht einmal so kompliziert, danke. Ein komplettes
>> Dokument möchte ich damit nicht parsen müssen, dafür ist es mir
>> zu rustikal; zur Formaterkennung reicht es aber ganz
>> ausgezeichnet.
> Da sieht man, wie sich die Geschmäcker unterscheiden. Bei DOM
> stellen sich mir immer die Nackenhaare auf; es ist für meinen
> Geschmack zu javaesque.
Ich mag Java überhaupt nicht, aber DOM ist für den einen oder
> Stefan...@Froehlich.Priv.at (Stefan Froehlich) writes:
>> On Tue, 07 Jun 2022 13:16:50 Stefan Froehlich wrote:
>>> On Tue, 07 Jun 2022 12:19:59 Karl Pflästerer wrote:
>>>> Mit https://www.php.net/manual/en/class.xmlreader.php bearbeiten
>>>> wir auch sehr große XML Dokumente; diese Klasse ist deutlich
>>>> speicherschonender. Der Ansatz ist (IMHO) schöner als SAX. das
>>>> wäre dann mein nächster Vorschlag:
>>>> https://www.php.net/manual/en/book.xml.php
>>> Merci, da wird sich hoffentlich etwas machen lassen; ich brauche
>>> es ja auch nur für die Formaterkennung, die Verarbeitung so
>>> großer Files erfolgt dann eh durch eigene CLI-Programme, mit PHP
>>> würde das ewig und ein Jahr dauern.
>> War dann gar nicht einmal so kompliziert, danke. Ein komplettes
>> Dokument möchte ich damit nicht parsen müssen, dafür ist es mir
>> zu rustikal; zur Formaterkennung reicht es aber ganz
>> ausgezeichnet.
> Da sieht man, wie sich die Geschmäcker unterscheiden. Bei DOM
> stellen sich mir immer die Nackenhaare auf; es ist für meinen
> Geschmack zu javaesque.
anderen Standard sehr praktisch. Ich habe da z.B. einen, wo in einem
Element via XPath auf den eigentlichen Inhalt referenziert wird.
Dafür, dass das so ist, kann ich nichts, aber mit DOM ist das
(naheliegenderweise) sehr einfach gelöst. Zu Fuß? Ich weiss nicht.
Ich habe mit vielen, unterschiedlichen Formaten zu tun und mir im
Lauf der letzten zwei Jahre eine (noch längst nicht fertig
ausgerollte) Mapping-Engine geschrieben. Da kann ich dann (bei
kleineren Dateien, als die, um die es in diesem Thread ging) für ein
Format Dinge tun wie:
#v+
# basispfade
$responseInfo = '/opentrans:ORDERRESPONSE/opentrans:ORDERRESPONSE_HEADER/opentrans:ORDERRESPONSE_INFO/';
# mapping
$mapping = [
OrderResponse::FIELD_ORDER_NUMBER => $responseInfo . 'opentrans:ORDER_ID',
OrderResponse::FIELD_ALT_ORDER_NUMBER => $responseInfo . 'opentrans:ALT_CUSTOMER_ORDER_ID',
OrderResponse::FIELD_SUPPLIER_ORDER_NUMBER => $responseInfo . 'opentrans:SUPPLIER_ORDER_ID',
[...]
];
#v-
Dieses Mapping stecke ich dann gemeinsam mit der Definition der
zugehörigen Eingabefelder und dem (in diesem Fall XML-) Dokument in
eine verarbeitende Klasse und erhalte die fix-fertigen Datenwerte
als Ergebnis, inklusive Prüfung und ggf. Fehlermeldungen. Mit DOM
ist das dank XPath halbwegs einfach (wenn auch bei komplexeren
Strukturen natürlich nicht halb so übersichtlich, wie in den obigen
paar Zeilen), mit xmlreader sähe ich ad hoc keinen guten Zugang.
> Mein Lieblings-Rant dazu
> http://harmful.cat-v.org/software/xml/s-exp_vs_XML (Erik Naggum
> schrieb sehr pointiert, was nicht jedem gefällt)
a) ich habe die Standards nicht erfunden, sondern muss damit
arbeiten. Das ist zwar korrekt, allerdings ein bisschen feig, denn
ich mag XML ja. Daher
b) Overhead und Ressourcenverbrauch sind mir (leider mit Grenzen,
wie dieser Thread gezeigt hat) weitgehend egal, ich muss zum einen
sehr einfach korrekte Dokumente erzeugen können und, wichtiger noch,
sehr einfach fehlerhafte Dokumente korrigieren können, um sie
anschließend zu verarbeiten.
Ich bekomme andauernd XML-Dokumente, die Feher enthalten - weniger
im XML selber (auch das gibt's), sondern vor allem in den Nutzdaten.
Ungültige Codes, verletzte Längenbeschränkungen und Randbedingungen,
oder Fehler auf einer sehr hohen Ebene (Rechnungen, die auf falsche
Bestellungen Bezug nehmen etc). Mit XML kann ich die Datei in einem
Texteditor aufmachen, trivial korrigieren und danach verarbeiten; im
Anschluss gibt es einen Rüffel per Mail, der in der Regel wenig bis
gar nichts bewirkt. Mit anderen Datenformaten (die bekomme ich ja
auch) ist das ungleich komplizierter, sowohl was meine Analyse
betrifft, als auch schon überhaupt die Korrektur durch den
Ersteller. Da können all die Kritikpunkte noch so zutreffen; viele
davon sind (aus meiner Sicht) lediglich Feinheiten, während der
zentrale Vorteil von XML einfach unübertroffen ist.
Auch bei der oben genannten Mapping-Engine ist z.B. die abstrakte
Formulierung der Position eines Datums in EDIFACT ungleich
komplexer als in jedem mir bekannten XML-Standard mit Ausnahme von
IDOC, das aber eher als Persiflage von XML zu betrachten ist.
Servus,
Stefan
--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike
(Sloganizer)
0 new messages