Subscribe
Follow me on TwitterDa für EJOE vor kurzem das am meisten nachgefrage Feature, ein InProcess-Modus, implementiert wurde, habe ich gleich mal ein paar Geschwindigkeitsmessungen vorgenommen, welche die beiden Modi miteinander vergeleichen.
Was ist ein InProcess-Modus überhaupt?
Das ist relativ einfach: Im Falle von EJOE liegt dann ein InProcess-Modus vor, wenn:
- sowohl Client als auch Server auf der selben Maschine und innerhalb der gleichen Instanz der Java Virtual Machine laufen
- die Clientprozesse direkt mit den Serverprozessen kommunizieren und somit keine Kommunikation über ein lokales Socket vorliegt.
In der Theorie sind lokale Sockets (manchmal auch als Loopback bezeichnet) langsamer als eine InProcess-Kommunikation. Naja gut, Theorie ist eine Sache 
Als Testfall wurde wieder eine EJOE-Standardkonfiguration herangezogen, welche mit dem Server über das EJOE-Testbean
kommuniziert, wobei der Server wiederum ebenfalls mit einer neuen Instanz des Beans antwortet (TestHandler)
Gemessen wird die Zeit zwischen Abschicken einer Abfrage und Erhalten der Serverantwort. Es finden also pro Anfrage zwei Serialisierungs- und zwei Deserialisierungsvorgänge statt. (Client: Anfrage serialisieren, Serverantwort deserialisieren; Server: Clientanfrage deserialisieren, Antwort serialisieren)
Testfall 1
Ein Client kommuniziert mit dem Server über lokales Socket mit einer persistenten Verbindung. Ein weiterer Client kommuniziert mit dem Server InProcess:
Im Gesamten bedeutet dies einen Geschwindigkeitsvorteil für den InProcess-Modus von lediglich 20,76%.
Testfall 2
Im ersten Lauf kommunizieren zwei Clients mit dem Server über lokales Socket mit jeweils einer persistenten Verbindung. Im zweiten Lauf kommunizieren zwei Clients mit dem Server InProcess. Im Gegensatz zu Testfall 1 wird hierbei EJOEs Multithreading-Architektur stärker angesprochen.
Im Gesamten bedeutet dies einen Geschwindigkeitsvorteil für den InProcess-Modus von lediglich 21,98%.
Fazit
Der InProcess-Modus ist wie erwartet performanter als die Kommunikation über lokale Sockets. Der Geschwindigkeitsvorteil beträgt jedoch nur rund ein Fünftel, wodurch wiederum drei Fakten deutlich werden:
- EJOE implementiert einen hochperformanten Umgang für die Datenkommunikation über Sockets
- Lokale Sockets (Loopback Device) sind bei modernen Betriebssysteme sehr performant umgesetzt
- Im Unterschied zu einer richtigen Netzwerkübertragung sind bei einer lokalen Kommunikation die Kosten für Serialisierung und Deserialisierung der Anfragen und Antworten wichtigster Faktor. Hier hat auch eine InProcess-Implementierung keinen entscheidenten Vorteil.
Weiterhin wird deutlich, dass EJOEs skalierbare Serverarchitektur – welche bei der Benutzung von Sockets eine wesentlich höhere Rolle als beim InProcess-Modus spielt – auch bei parallelen Anfragen einen fast gleichbleibend hohen Durchsatz garantiert. Der Unterschied zwischen mehreren gleichzeitigen Anfragen und der Verarbeitung einelner, sequentieller Anfragen ist gering. In den obigen Testfällen beträgt der Abfall gegenüber dem Abfall des InProcess-Modus gerade mal ~1,2%.
Wie dicht lokale Sockets und InProcess-Mode beieinanderliegen – und wie performant EJOE selbst mit Standardeinstellungen bereits zur Sache geht – zeigt eine andere Darstellung für den Testfall 2 – jetzt allerdings auf einem Mehrprozessorsystem:
Der Unterschied in der Verarbeitungszeit berägt durchschnittlich gerademal ~1,8 Millisekunden pro Anfrage. Selbst mit zwei Serialisierungs- sowie zwei Deserialisierungsoperationen pro Anfrage mit dem durchaus komlexen EJOE-Testbean bewegt sich die Verarbeitungszeit bei paralleler Verarbeitung durchschnittlich lediglich im Bereich von 4,42 bis 6,22 Millisekunden.
Die Serialisierung ist extrem CPU-lastig. Sowohl die Kosten für die parallele (De)Serialisierung als auch das Multithreading-Verhalten von EJOEs Serverkern sind stark von der CPU abhängig: Je mehr CPUs bzw. CPU-Cores, destso besser ist die Skalierung.
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.