2010-03-19 8 views
8

Ich habe JAXB Marshaller sowie meine eigenen Marshaller zum Marshalling pure Java-Objekte in XML verwendet. Es wurde beobachtet, dass beide fast die gleiche Zeit benötigen, um zu marshalen. Die Leistung ist nicht akzeptabel und muss verbessert werden. Welche Möglichkeiten gibt es, um die Leistung des Marshallers zu verbessern? Wie threading?Java Marshaller Leistung

+2

Wie ist es nicht akzeptabel? Was ist dein Maßstab? Teilen Sie es – Bozho

+0

Es gibt einige sehr alte (aber immer noch interessante) Benchmarks hier: https://bindmark.dev.java.net/old-index.html – skaffman

+0

Haben Sie überprüft, ob es das Problem mit der mehrfachen Validierung ist? Ich bezweifle!! – srinannapa

Antwort

3

Anpassung der Verwendung von JibX. Wie bei questzen fand ich, dass JibX in meinen Leistungstests 9-mal schneller war als JAXB.

Stellen Sie sicher, dass Sie Woodstox auf dem Klassenpfad haben, wenn Sie JibX verwenden. Ich fand Woodstox's Stax-Implementierung ist etwa 1050% schneller als die Java6-Implementierung von Stax.

+0

+1 für woodstox – skaffman

+1

Nichts gegen JibX, aber von dem, was ich gesehen habe, 9x scheint ziemlich hoch. JAXB war ziemlich performant für mich, solange Sie Woodstox verwenden, keine Validierung verwenden (was Jibx nicht tut und selten zum Marshalling nützlich ist). Und wenn möglich, verwenden Sie auch nicht die Version JAXB impl JDK-Bundles: Verwenden Sie aktuell eins. – StaxMan

+0

Eigentlich denke ich daran, dass Suns Stax-Paket (Sjsxp) beim Schreiben von XML viel langsamer ist als Woodstox - das könnte den 9-fachen Unterschied erklären, vorausgesetzt, JibX verwendet Woodstox (was es standardmäßig tut) – StaxMan

1

Meiner Erfahrung nach war JIBX http://jibx.sourceforge.net/ fast 10X schneller als JAXB. Ja, ich habe es für eine Leistungsspezifikation gemessen. Wir haben es verwendet, um Java-Beans mit großen HL7 XML zu binden. Davon abgesehen besteht der Weg zur Leistungsverbesserung nicht darin, sich auf die Schemadefinition zu verlassen, sondern benutzerdefinierte Bindungen zu schreiben.

11

Stellen Sie sicher, dass Sie die JaxB-Kontextinstanz nur einmal erstellen. Die Erstellung des Kontexts dauert einige Zeit, da Reflektionen verwendet werden, um die Anmerkungen des Objekts zu analysieren.

Beachten Sie, dass der JAXBContext Thread-sicher ist, aber die Marshallers \ unmarshallers nicht sind, so müssen Sie noch den Marshaller für jeden Thread erstellen. Wie auch immer, ich habe festgestellt, dass das Erstellen der Marshaller, wenn Sie bereits einen Jaxb-Kontext haben, ziemlich schnell ist.

+1

Danke dafür Kommentar, half mein junit ziemlich schnell zu beschleunigen. Jaxb Kontext Generation für mich dauert 14+ Sekunden. Danach sind die Marshal/Unmarshals ziemlich schnell unmarshal: 0.116s Marshal: 0.023s – Russ

+0

Dies sollte die akzeptierte Antwort sein. –

5

Byeond andere gute Vorschläge, schlage ich vor, es ist etwas falsch mit der Art und Weise verwenden Sie JAXB - es in der Regel recht gut ist die Durchführung so lange wie:

  • Sie verwenden JAXB Version 2 (nie verwenden veraltete JAXB 1 - das war schrecklich langsam, nutzloses Stück Mist); vorzugsweise eine aktuelle Version 2.1.x von http://jaxb.dev.java.net
  • Stellen Sie sicher, dass Sie SAX oder Stax Quelle/Ziel verwenden; NIEMALS DOM verwenden, wenn Sie unbedingt für die Interoperabilität müssen: Verwendung von DOM wird es 3 - 5x langsamer machen, ohne Nutzen (es verdoppelt nur Objektmodell: POJO -> DOM -> XML; DOM Teil ist völlig unnötig)
  • Ideal am schnellsten zu verwenden SAX/Stax-Parser verfügbar; Woodstox ist schneller als Sun gebündelt Stax Prozessor (und ref BEA. Impl. Fehlerhaft ist, nicht schneller als Suns)

Wenn JAXB noch mehr als 50% langsamer als manuell geschrieben Variante ist, würde ich es Profil, was zu sehen sonst geht es schief. Es sollte nicht langsam arbeiten, wenn es richtig verwendet wird - ich habe es kontinuierlich gemessen und es so schnell gefunden, dass handschriftliche Konverter normalerweise keine Zeit und Mühe wert sind.

Jibx ist auch ein gutes Paket, also habe ich nichts dagegen, es auszuprobieren. Es könnte immer noch etwas schneller sein als JAXB; nur nicht 5x oder 10x, wenn beide richtig verwendet werden.

0

Wir können die Leistung beim Marshalling und beim Unmarshalling erreichen, indem wir die Schnellstart-Eigenschaft auf Systemebene festlegen. Dies wird viel Leistungsverbesserung bringen.

System.setProperty ("com.sun.xml.bind.v2.runtime.JAXBContextImpl.fastBoot", "true");

1

Wir haben gerade ein JAXB-Leistungsproblem im Zusammenhang mit der von Xerces verwendeten Standardparser-Konfiguration festgestellt. JAXB Leistung war sehr langsam (30s +) für eine Datendatei (< 1Mb)

Zitat "Wie ändere ich die Standard-Parser-Konfiguration?"Von http://xerces.apache.org/xerces2-j/faq-xni.html

Der DOM und SAX-Parser entscheiden, welche Parserkonfiguration in der folgenden Reihenfolge für die Klassennamen

  1. Die org.apache.xerces.xni.parser.XMLParserConfiguration Systemeigenschaft abgefragt, um zu verwenden,
  2. Wenn eine Datei mit dem Namen xerces.properties im Unterverzeichnis lib der JRE-Installation existiert und die Eigenschaft org.apache.xerces.xni.parser.XMLParserConfiguration definiert ist, wird ihr Wert aus dem Verzeichnis gelesen Datei
  3. Die Datei org.apache.xerces.xni.parser.XMLParserConfiguration wird im Verzeichnis META-INF/services/angefordert. Diese Datei enthält den Klassennamen der Parserkonfiguration.
  4. Die org.apache.xerces.parsers.XIncludeAwareParserConfiguration wird als Standardparserkonfiguration verwendet.

Unmarshalling mit JAXB Ergebnisse in diesem Algorithmus wiederholt angewendet wird. Es kann also sehr viel Zeit darauf verwendet werden, den Klassenpfad wiederholt zu durchsuchen und nach der Konfigurationsdatei zu suchen, die nicht existiert. Die Lösung besteht darin, Option 1, Option 2 oder Option 3 zu machen (erstellen Sie die Konfigurationsdatei unter META-INF). Alles, um den wiederholten Klassenpfad-Scan zu verhindern.

Hoffe, das hilft jemandem - es hat uns Tage gekostet, dies zu verfolgen.