Hallo,
einer kleinen armen Schnittstelle wird über die Jahre immer mehr Last aufgebürded. Mittlerweile bekommt Sie XMLs zum verdauen vorgesetzt, die schon mal an die 60MB gross sind. Mittels libxml und libxslt wird das Ganze unter Perl verarbeitet und in kleinen überschaubaren Häppchen an die Datenbank einer Web-Applikation verfüttert. Prinzipiell funktioniert das auch prima, allerdings der Speicherhunger der XSLT-Transformation wächst proportional zur Dateigrösse des XML und macht mir langsam Sorgen. Inkl. Footprint konsumiert der Prozess ein schlappes GB RAM.
Ich will das gerne optimieren - zumal abzusehen ist, dass der Datenumfang noch zunimmt. Dabei gehe ich von 2 Ansätzen aus: 1. libxml/xslt sind evtl. nicht optimal für derartige Datenmengen ausgelegt. Welche Perl-tauglichen Alternativen gibt es? 2. Das Stylesheet selber mag auch nicht von des Virtuosen Hand stammen. (Wie) kann kann man sowas profilen?
Danke für eure Hinweise!
Mit freundlichen Grüßen
Jens Puruckherr
Am 09.05.2008 um 13:56 schrieb Jens Puruckherr:
XMLs
<rant>Naja. Wie wärs mit nem Technologiewechsel? XML ist Schrott.</rant>
- libxml/xslt sind evtl. nicht optimal für derartige Datenmengen
ausgelegt. Welche Perl-tauglichen Alternativen gibt es?
Xalan/Xerces vom apache-Projekt, SaxonB von saxonica. Die nehmen allerdings Java. Wird daher nicht schneller, vermute ich.
- Das Stylesheet selber mag auch nicht von des Virtuosen Hand
stammen. (Wie) kann kann man sowas profilen?
oxygenXML ist die einzige mir bekannte kostenlos erhältliche SW, mit der man XSLTs in einer halbwegs anständigen GUI debuggen kann. Profiling... keine Ahnung.
Weitere Optionen: * Das XSLT kompilieren, das Kompilat benutzen. Saxon und Xalan/Xerces können das, soweit ich weiß. * SAX statt DOM? 1GB Speicherverbrauch klingt nach DOM. Schonmal versucht auf SAX umzustellen?
MfG Sebastian -- Jeder ist notwendigerweise der Held seiner eigenen Lebensgeschichte.
Hi Sebastian,
vielleicht erinnerst Du Dich an meinen Geburtstag letztes Jahr. Du warst der Überraschungsgast ;)
<rant>Naja. Wie wärs mit nem Technologiewechsel? XML ist Schrott.</rant>
Ist es nicht, weil das ein sauberes Format ist. Das ist kein Binärklumpen, in dem man mit diversen Programmen rumwühlen muss. Und in manchen Firmen ist es echt eine Alternative zu handgeschriebenen Java Script Code, bei dem man tiefergehende Probleme nicht mehr mit try und catch mitbekommt.
- libxml/xslt sind evtl. nicht optimal für derartige Datenmengen
ausgelegt. Welche Perl-tauglichen Alternativen gibt es?
Xalan/Xerces vom apache-Projekt, SaxonB von saxonica. Die nehmen allerdings Java. Wird daher nicht schneller, vermute ich.
Das ist egal, ob es perl oder xslt ist. Ich hatte selber mal die Wahl und hatte mich vor 4J für xslt entschieden, weil es mir einfach besser lag, als ständig auf Einrückungen meines Textes zu achten. Das ist einfach nur eine Geschmacksfrage.
- Das Stylesheet selber mag auch nicht von des Virtuosen Hand
stammen. (Wie) kann kann man sowas profilen?
oxygenXML ist die einzige mir bekannte kostenlos erhältliche SW, mit der man XSLTs in einer halbwegs anständigen GUI debuggen kann. Profiling... keine Ahnung.
Zum debuggen brauch man keine GUI, aber das kann jeder selbst wählen.
Weitere Optionen:
- Das XSLT kompilieren, das Kompilat benutzen. Saxon und Xalan/Xerces
können das, soweit ich weiß.
- SAX statt DOM? 1GB Speicherverbrauch klingt nach DOM. Schonmal
versucht auf SAX umzustellen?
Mal ne andere Frage, wie lange braucht das Script um durchzulaufen? ... kann man sich da einen Kaffee aus der Küche holen, oder die Möhre mit den Jungs auf der Rauchpause essen?
Jeder ist notwendigerweise der Held seiner eigenen Lebensgeschichte.
Wie wahr, wie wahr! Wenn ich dann technische Dokumentation studieren gehe, dann sag ich rechtzeitig bescheidt.
Ciao, Jana.
Hi Jens,
Gibt es eine DTD?
... Hast Du eine debugfähige Version erstellt? ... Gab es gegenseitiges Codereading, bevor es in die Produktion ging? ... Sollte man mal eine Beratung über eine Consulting-Firma ansetzen, bevor alles in 3-4J in die Luft geht?
Ansonsten hoffe ich nicht, dass Du bei der Firma arbeitest, wo ich nicht ins Team gepasst habe. - deren Hauptanwendung hatte den günstigen Namen "Schnittstelle", - verwendet Datenbanken im Textformat mit immer länger werdenden Schwänzen, - nutzt ältere Office-Dokumente als Archivierungsformat, - schreibt einfach gestrickte Excelabfragen über den Driver als komplizierte PHP-Programmkonstrukte, die auch noch immer wieder neu erfunden werden müssen ... und so weiter ...
Das wär jetzt aber zu verrückt, um wahr zu sein.
Ciao, Jana.
-------- Original-Nachricht --------
Datum: Fri, 09 May 2008 13:56:51 +0200 Von: "Jens Puruckherr" jpuruckherr@cyberport.de An: "DD Lug" lug-dd@mailman.schlittermann.de Betreff: Verarbeitung grosser XMLs
Hallo,
einer kleinen armen Schnittstelle wird über die Jahre immer mehr Last aufgebürded. Mittlerweile bekommt Sie XMLs zum verdauen vorgesetzt, die schon mal an die 60MB gross sind. Mittels libxml und libxslt wird das Ganze unter Perl verarbeitet und in kleinen überschaubaren Häppchen an die Datenbank einer Web-Applikation verfüttert. Prinzipiell funktioniert das auch prima, allerdings der Speicherhunger der XSLT-Transformation wächst proportional zur Dateigrösse des XML und macht mir langsam Sorgen. Inkl. Footprint konsumiert der Prozess ein schlappes GB RAM.
Ich will das gerne optimieren - zumal abzusehen ist, dass der Datenumfang noch zunimmt. Dabei gehe ich von 2 Ansätzen aus:
- libxml/xslt sind evtl. nicht optimal für derartige Datenmengen
ausgelegt. Welche Perl-tauglichen Alternativen gibt es? 2. Das Stylesheet selber mag auch nicht von des Virtuosen Hand stammen. (Wie) kann kann man sowas profilen?
Danke für eure Hinweise!
Mit freundlichen Grüßen
Jens Puruckherr
Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd
Am Freitag, den 09.05.2008, 13:56 +0200 schrieb Jens Puruckherr:
Hallo,
einer kleinen armen Schnittstelle wird über die Jahre immer mehr Last aufgebürded. Mittlerweile bekommt Sie XMLs zum verdauen vorgesetzt, die schon mal an die 60MB gross sind. Mittels libxml und libxslt wird das Ganze unter Perl verarbeitet und in kleinen überschaubaren Häppchen an die Datenbank einer Web-Applikation verfüttert. Prinzipiell funktioniert das auch prima, allerdings der Speicherhunger der XSLT-Transformation wächst proportional zur Dateigrösse
DOM? Kann man das evtl. auf SAX umstellen? JFTR: Es gibt da ein IMHO kleines aber feines Buch: Perl & XML (O'Reilly, auch bei der SLUB erhältlich), das hier beim Optimieren und Überblicken der Perl-basierten Software-Lösungen helfen könnte.
des XML und macht mir langsam Sorgen. Inkl. Footprint konsumiert der Prozess ein schlappes GB RAM.
Ich will das gerne optimieren - zumal abzusehen ist, dass der Datenumfang noch zunimmt. Dabei gehe ich von 2 Ansätzen aus:
- libxml/xslt sind evtl. nicht optimal für derartige Datenmengen
ausgelegt. Welche Perl-tauglichen Alternativen gibt es?
Einige. S.o. Es gab auch mal einen kurzen Artikel von Mike Schilli, in dem er für das Linux-Magazin unterschiedliche Parser vorgestellt hat. Dann gibt es eine sehr umfangreiche FAQ auf http://perl-xml.sourceforge.net/faq/. Da wird auch das Problem sehr großer Dateien angesprochen.
- Das Stylesheet selber mag auch nicht von des Virtuosen Hand
stammen. (Wie) kann kann man sowas profilen?
Zum debuggen im FOSS-Bereich kenne ich nur xsltdbg mit QT-GUI (vom KDE-Projekt gepflegt). War das letzte Mal aber eher buggy (Speicherzrgriffsfehler beim Testen des Beispiels). Kommerzielle Software mag hier besser sein.
MfG Daniel
On Fri, May 09, 2008 at 01:56:51PM +0200, Jens Puruckherr wrote:
Hallo,
einer kleinen armen Schnittstelle wird über die Jahre immer mehr Last aufgebürded. Mittlerweile bekommt Sie XMLs zum verdauen vorgesetzt, die schon mal an die 60MB gross sind. Mittels libxml und libxslt wird das Ganze unter Perl verarbeitet und in kleinen überschaubaren Häppchen an die Datenbank einer Web-Applikation verfüttert. Prinzipiell funktioniert das auch prima, allerdings der Speicherhunger der XSLT-Transformation wächst proportional zur Dateigrösse des XML und macht mir langsam Sorgen. Inkl. Footprint konsumiert der Prozess ein schlappes GB RAM.
Ich vermute mal, dass das XML folgenden Aufbau hat:
<container> <item>...</item> <item>...</item> ... </container>
Du kannst auf SAX umsteigen, wenn das erste item bearbeitet werden kann, ohne dass die folgenden items gelesen werden müssen. Bei DOM (XSLT) wird in der Regeln der gesamte XMl-Baum eingelesen. Das ist aber vermutlich nicht nötig. Du kannst sicherlich ein item nach dem anderen bearbeiten.
Ich würde dabei noch von Perl zu einer andere P-Scriptsprache umsteigen ...
Hier ein SAX-Beispiel, bei dem TreeBuilder der eigentlicher Parser ist. http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/534109
Für Python gibt es in aktuellen Version etree (für andere als externes Paket). Das ließt zwar auch den gesamten XML-Baum, wird aber sicherlich nicht so viel Hauptspeicher benötigen.
Gruß, Thomas
lug-dd@mailman.schlittermann.de
-
Daniel Leidert -
dejane -
Jens Puruckherr -
Sebastian Hegler -
Thomas Guettler