Vielleicht ist es ja für einen von euch mehr oder weniger Interessant:
blog.depon.net/index.php?/archives/209-1-Millionen-Xml-Dokumente.html
Für mein zukünftiges Projekt wird für den Webserver pro Seite eine Xml-Datei verarbeitet. Es stellte sich für mich in der Frage ob die Template-Engine selbst Xml-Dokumente verarbeiten sollte oder ob ich mir etwas anderes überlegen muss.
Daher habe ich einen kurzen Mikrobenchmark geschrieben, der eigentlich immer das gleiche erledigt.
Durchgeführt wurde der Test auf einem Athlon X2 4000+ Dualcore unter Vista 64 Bit, allerdings nur singlethreaded (ergo, 50% des Rechners lagen lahm).
Rückmeldung: Xml-Performance
gepostet vor 17 Jahre, 1 Monat von TheUndeadable
gepostet vor 17 Jahre, 1 Monat von raufaser
Ich muss gestehen, dass ich den Test nicht für besonders repräsentativ halte, weil das was du da als XML Dokument verwendest total an der Realität vorbei geht.
Ein richtiger Test sollte mit einer komplexen XML Struktur stattfinden, und nicht nur mit einer Node und einem Element.
Mir scheint, als wolltest du unbedingt ein positives Ergebnis haben...
Ich habe die Erfahrung gemacht, dass das parsen von komplexen XML Daten Performancefresser sind. Und das steigt mit der Tiefe der Verschachtelung und Größe des Dokuments...
Gruß,
Marc
Ein richtiger Test sollte mit einer komplexen XML Struktur stattfinden, und nicht nur mit einer Node und einem Element.
Mir scheint, als wolltest du unbedingt ein positives Ergebnis haben...
Ich habe die Erfahrung gemacht, dass das parsen von komplexen XML Daten Performancefresser sind. Und das steigt mit der Tiefe der Verschachtelung und Größe des Dokuments...
Gruß,
Marc
gepostet vor 17 Jahre, 1 Monat von TheUndeadable
Ein richtiger Test sollte mit einer komplexen XML Struktur stattfinden, und nicht nur mit einer Node und einem Element
In meinem konkreten Fall geht es nur um ein sehr simples Element von eins bis zwei Knoten. Es soll nur das grobe Layout einer Seite getestet werden.
Mir scheint, als wolltest du unbedingt ein positives Ergebnis haben...
Nicht wirklich ;-) Ich kann aber auch gerne mal ein komplizierteres Dokument durchparsen, wenn Interesse daran besteht.
Der Test sollte kein Referenztest sein, sollte mir nur eine Größenordnung aufzeigen...
gepostet vor 17 Jahre, 1 Monat von raufaser
Also ich fänd's gut wenn du's mal mit einem komplexeren XML Dokument probierst. Bin an den Ergebnissen auf jeden Fall interessiert.
Gruß,
Marc
Gruß,
Marc
gepostet vor 17 Jahre, 1 Monat von None
Du unterliegst einen kleinen aber gemeinen Denkfehler!
* File-IO verbraucht unmengen an Zeit. Kannst du mit Caching teilweise abfagen.
* Du legst 1 MIO mal ein Objekt vom Typ String an. ABU! Der Stiefel bitte! Ok, Testsource, aber aua! ;-)
* Du hast 1 Node nur.
Wenn du sowas testen willst, dann verwende unterschiedlich große XML Files, mit unterschiedlichem Inhalt und leg sie auf die Platte. Willst du den IO niedrig halten, dann installiere dir eine 64 MB RamDisk. Treiber dafür gibt es.
Aus Erfahrung würde ich sagen, daß du hier das Komma um eine Stelle verschieben solltests und zwar nach Links.
* File-IO verbraucht unmengen an Zeit. Kannst du mit Caching teilweise abfagen.
* Du legst 1 MIO mal ein Objekt vom Typ String an. ABU! Der Stiefel bitte! Ok, Testsource, aber aua! ;-)
* Du hast 1 Node nur.
Wenn du sowas testen willst, dann verwende unterschiedlich große XML Files, mit unterschiedlichem Inhalt und leg sie auf die Platte. Willst du den IO niedrig halten, dann installiere dir eine 64 MB RamDisk. Treiber dafür gibt es.
Aus Erfahrung würde ich sagen, daß du hier das Komma um eine Stelle verschieben solltests und zwar nach Links.
gepostet vor 17 Jahre, 1 Monat von TheUndeadable
Scheiß Forum... Frisst einfach Postings...
Daher kurz und schmerzlos:
@MrMarco: Das Herausschieben der Stringerstellung hat keinen Performancegewinn gebracht
@raufaser:
blog.depon.net/index.php?/archives/210-64-Xml-Dokumente.html
Xml 1 (1 KB);
Xml 2 (2.185 KB);
Xml 3 (13 KB);
Folgende Ergebnisse kamen heraus:
Xml1: 184.510 mal eingeladen in 10 Sekunden: 54 Mikrosekunden pro Ladevorgang
Xml2: 64 mal eingeladen in 10 Sekunden: 156.000 Mikrosekunden pro Ladevorgang
Xml3: 25.662 mal eingeladen in 10 Sekunden: 389 Mikrosekunden pro Ladevorgang
Wie du schon sagtest: Die Performance wird bitter, wenn man sehr große Dokumente einliest, allerdings finde ich es noch im Rahmen. Für mein Projekt ist es allerdings irrelevant, da ich 100 Byte-Xml-Ausschnitte nur parsen muss.
www.depon.net/downloads/xmldocumenttest.zip <- Falls es jmd selbst ausführen möchte.
Daher kurz und schmerzlos:
@MrMarco: Das Herausschieben der Stringerstellung hat keinen Performancegewinn gebracht
@raufaser:
blog.depon.net/index.php?/archives/210-64-Xml-Dokumente.html
Als Xml-Dateien wurden folgende Xml-Dateien genommen:
Xml 1 (1 KB);
Xml 2 (2.185 KB);
Xml 3 (13 KB);
Folgende Ergebnisse kamen heraus:
Xml1: 184.510 mal eingeladen in 10 Sekunden: 54 Mikrosekunden pro Ladevorgang
Xml2: 64 mal eingeladen in 10 Sekunden: 156.000 Mikrosekunden pro Ladevorgang
Xml3: 25.662 mal eingeladen in 10 Sekunden: 389 Mikrosekunden pro Ladevorgang
Wie du schon sagtest: Die Performance wird bitter, wenn man sehr große Dokumente einliest, allerdings finde ich es noch im Rahmen. Für mein Projekt ist es allerdings irrelevant, da ich 100 Byte-Xml-Ausschnitte nur parsen muss.
www.depon.net/downloads/xmldocumenttest.zip <- Falls es jmd selbst ausführen möchte.
gepostet vor 17 Jahre, 1 Monat von raufaser
Danke für die Rückmeldung.
Also ich denke repräsentativ ist der dritte Test, das ist schon ein recht "typisches" XML Dokument. Und das ist von der Performance ja absolut okay. Hätte ich ehrlich gesagt nicht gedacht, aber um so besser, wenn mein Bedenken nicht bestätigt werden.
Gruß,
Marc
Also ich denke repräsentativ ist der dritte Test, das ist schon ein recht "typisches" XML Dokument. Und das ist von der Performance ja absolut okay. Hätte ich ehrlich gesagt nicht gedacht, aber um so besser, wenn mein Bedenken nicht bestätigt werden.
Gruß,
Marc