Letzte Woche haben wir im EJAPP Top 10 Countdown über die falsche Verwendung von Java EE gesprochen. Nach diesem sehr breiten Thema ist es Zeit für ein sehr spezifisches Thema auf Platz 7. Die unnötige Verwendung von XML ist ein Segen für die Leistung Ihrer Java EE-Anwendung. XML hat eine Reihe interessanter Eigenschaften, die dazu führen, dass es für eine ganze Reihe von Funktionen in der durchschnittlichen Enterprise Java-Anwendung verwendet wird:
- als Konfigurationsdateiformat, z.B. Java EE Bereitstellungsdeskriptoren und Spring Konfigurationsdateien,
- als Remoting-Protokoll, z.B. SOAP oder Burlap, und sogar
- als Datenspeicherformat, z.B. Apache Xindice und eXist.
Jemand hat einmal gesagt: "XML ist das Substantiv und Java ist das Verb", und das hat sich durchgesetzt. Leider beansprucht die XML-Verarbeitung viel CPU-Zyklen und Speicherplatz.
Diese Leistungseinbußen lassen sich auf eine Reihe von Bereichen zurückführen:
- Parsing. Es gibt eine Reihe von Möglichkeiten, ein XML-Dokument zu parsen, wobei jede davon einen Kompromiss zwischen Programmierkomfort und Laufzeitleistung darstellt:
- SAX - sein ereignisbasiertes Modell ist effizient, kann aber schwer zu programmieren sein.
- DOM - sein Baummodell ist einfacher zu verwenden, führt aber dazu, dass das gesamte XML-Dokument auf einmal in den Speicher geladen wird. Alternative APIs, die ein Baummodell verwenden, wie JDOM, dom4j und XOM, leiden unter demselben Problem.
- StAX - sein Pull-Modell ist eine Kreuzung aus SAX und DOM. Es ermöglicht dem Programm, geparste Fragmente des XML-Dokuments in den Speicher zu ziehen und so das komplizierte Ereignismodell von SAX und das speicherineffiziente Baummodell von DOM zu vermeiden. Verfügbar als Teil von Java SE 6.
- Transformation. Bei der Umwandlung eines XML-Dokuments in ein anderes XML-Dokument wird meistens XSLT verwendet. Leider ist die XSLT-Verarbeitung ein teurer Vorgang, sowohl was die CPU als auch was den Speicher betrifft. Xalan-J ist der am weitesten verbreitete Java XSLT-Transformer und seine Leistung kann durch die Verwendung kompilierter Stylesheets und durch Tuning seiner Verwendung verbessert werden. Andere XSLT-Transformatoren bieten möglicherweise eine bessere Leistung.
- Generierung. Die Generierung eines XML-Dokuments (auch bekannt als XML-Serialisierung) ist im Allgemeinen viel schneller als das Parsen von XML. Es ist keine komplexe Logik erforderlich und es müssen keine Objekte erstellt werden. Stellen Sie nur sicher, dass Sie bei großen Dokumenten in einen gepufferten Stream und nicht in einen String schreiben.
- Datenbindung. Einige Anwendungen verarbeiten das XML nicht direkt, sondern verwenden die XML-Datenbindung, um das geparste XML-Dokument in POJOs umzuwandeln(unmarshalling) und zurück(marshalling). Verschiedene Datenbindungs-Frameworks haben unterschiedliche Leistungsmerkmale.
Auch wenn es möglich ist, die Leistung Ihres XML-Parser-, Transformator- und Datenbindungs-Frameworks zu optimieren, wird die XML-Verarbeitung in puncto Leistung niemals Property-Dateien (für Konfigurationsdateien), Java-Serialisierung (für Remoting) oder einfache CSV-Dateien und SQL-Datenbanken (für die Datenspeicherung) schlagen können. Entscheiden Sie sich also nicht für XML, nur weil es gerade angesagt ist!
Mehr aus dieser Serie
- EJApp Top 10 BOF-Sitzung auf der JavaPolis 2006
- #1: Falsche Verwendung der Datenbank
- #Nr. 2: Unnötiges Remoting
- #Nr. 3: Falsch implementierte Gleichzeitigkeit
- #Nr. 4: Schlecht funktionierende Bibliotheken
- #Nr. 5: Übermäßiger Speicherverbrauch
- #Nr. 6: Unsachgemäßes Caching
- #Nr. 7: Unnötige Verwendung von XML
- #Nr. 8: Falsche Verwendung von Java EE
- #9: Falsche Konfiguration des Anwendungsservers
- #Nr. 10: Exzessive Protokollierung
- EJApp Top 10 Countdown Nachbereitung
Verfasst von
Vincent Partington
Unsere Ideen
Weitere Blogs
Contact



