Subscribe
Follow me on TwitterAktuell ist für EJOE gerade der überfällige Milestone 0.3.9.2 in Vorbereitung. Im Zuge dessen haben wir uns die vorhandenen Adapter genauer hinsichtlich Performance und Größen der serialisierten Formen angeschaut und einen Adapter-Benchmark entwickelt.
Der Benchmark umfasste Läufe von 10, 100, 1000 und 10000 Iterationen in denen jeweils ein neues Testbean serialisiert, an den Server gesendet und die Serverantwort (neue Instanz desselben Bean-Typs) wieder deserialisiert wurde. Der Benchmark wurde sowohl für non-blocking I/O als auch für blocking I/O durchgeführt.
Vor jedem Lauf wurde der EJOE-Server in fünf Iterationen mit dem jeweiligem Adapter “aufgewärmt” um allen Adaptern die gleichen Vorraussetzungen zu verschaffen.
Es wurden dabei nur die Adapter berücksichtig, die das EJOE-Testbean auf direktem Weg sowohl komplett serialisieren als auch deserialisieren können.
- de.netseeker.ejoe.adapter.JavaBeansXmlAdapter
- de.netseeker.ejoe.adapter.ObjectStreamAdapter (EJOEs Standardadapter, wenn XStream nicht verfügbar ist)
- de.netseeker.ejoe.adapter.XStreamAdapter (EJOEs Standardadapter, wenn XStream verfügbar ist)
- de.netseeker.ejoe.adapter.HessianAdapter
- de.netseeker.ejoe.adapter.JavolutionAdapter
- de.netseeker.ejoe.adapter.json.JsonToolsAdapter
- de.netseeker.ejoe.adapter.CastorAdapter
- de.netseeker.ejoe.adapter.SojoAdapter
Besonders interessant ist das Verhalten der beiden Adapter basierend auf Java-Standardtechniken:
de.netseeker.ejoe.adapter.JavaBeansXmlAdapter sowie de.netseeker.ejoe.adapter. ObjectStreamAdapter mit blocking I/O. Man sieht insbesondere beim ObjectStreamAdapter, welchem die gleiche Technik wie bei RMI zugrundeliegt, dass ObjectOutputStream und ObjectInputStream unter blocking I/O hervorragende Werte liefern. Unter non-blocking I/O sieht die Sache dann jedoch etwas anders aus…
Der JavolutionAdapter, welcher vor dem Benchmark als Geschwindigkeits-Favoriten gehandelt wurde, schlägt sich zwar gut, jedoch mit wachsender Anzahl Iterationen nicht wirklich herausragend.
Der EJOE-Standardadapter “de.netseeker.ejoe.adapter.XStreamAdapter” schlägt sich gut im Mittelfeld und rechtfertigt unter Einbeziehung des Vorteils, dass er als einziger so ziemlich alle Objekttypen auf dem Java-Planeten verarbeiten kann, seinen Status als empfohlene Standardeinstellung in EJOE.
Bei den Größen der serialisierten Formen (also der Form in der ein Objekt nach dem Serialisierungsvorgang vorliegt) gibt es kaum Überraschungen:
Hessian schafft die kleinsten Bytemengen wie auch zu erwarten war. Die long term persistence for Java (JavaBeansAdapter) erzeugt mit Abstand die größten Datenmengen.
Castor könnte prinzipiell besser abschneiden, jedoch zwingt EJOE den Castor-Marshaller auch XSI-Deklarationen zu erzeugen, wodurch der Output größer wird.
Als Ergebnis konnte der Benchmark zwei Fakten klar darstellen:
- Bei Non-Blocking I/O kann man beruhigt zu jedem der getesteten Adapter greifen. Die Geschwindigkeitsunterschiede sind nach spätestens 5000 Serveranfragen nicht mehr relevant.
- Bei Blocking I/O kommt man, wenn es um Geschwindkeit geht, nicht um den ObjectStreamAdapter herum. Hier zeigt die alterwürdige Objektserialisierung, welche auch bei RMI eine große Rolle spielt, allen anderen Techniken ganz klar wo der Hammer hängt.
EJOE ist ein in Java programmiertes Remoting Framework. Es besteht aus Client- und Serverkomponente und unterstützt den Datenaustausch zwischen Client und Server via austauschbaren (De-)Serialisierungsmechanismen, z.B. XStream, Castor oder Standard Java Beans Serialisierung. Es handelt sich dabei um eine hochperformante und skalierbare Implementierung des Request-Process-Response Patterns. EJOE kann je nach Verwendung den Kategorien Middleware, Remoting Framework, I/O Framework und Object Request Broker zugeordnet werden.
Mehr Informationen zu EJOE inklusive einem umfangreichem, deutschen Handbuch stehen auf der Projektseite http://ejoe.sourceforge.net bereit.
Unsteter Gedankenfluss aus dem Leben eines Projektleiters, Entwicklers, Freizeitautors, eBook-Enthusiasten und last but not least sächsischen Asylschwaben.