Staged Event Driven Architecture

based on CORSO

Christoph Nagl

MatrNr. 9826039

Version 1.0

Inhaltsverzeichnis

1 Technischer Entwurf 11.1 Staged Event-Driven Architecture (SEDA) . . . . . . . . . . . . . . . . . . . 11.2 Framework STEAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Abarbeitung in STEAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.4 CORSO Event Queues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.4.1 Konfiguration der Event Queues . . . . . . . . . . . . . . . . . . . . 31.4.2 Aufbau der CORSO Event Queues . . . . . . . . . . . . . . . . . . . 4

1.5 Klassendiagramm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.6 Links im WWW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2 Testkonzept 72.1 Allgemein . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2 Testtools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.3 Testplan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.4 Mengengerust Testzyklus . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.5 Test Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.6 Referenztest STEAM mit JMS . . . . . . . . . . . . . . . . . . . . . . . . . 82.7 Test STEAM mit CORSO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.8 Testauswertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.9 Erwartetes Ergebnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3 Testauswertung 103.1 Vorbedingungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.2 Testdurchfuhrung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.3 Testergebnisse Testzyklus 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.3.1 10 Requests SEDA & CO . . . . . . . . . . . . . . . . . . . . . . . . 113.3.2 100 Requests SEDA & CO . . . . . . . . . . . . . . . . . . . . . . . 113.3.3 1000 Requests SEDA & CO . . . . . . . . . . . . . . . . . . . . . . . 123.3.4 10 Requests mit 2 CORSO Runtimes . . . . . . . . . . . . . . . . . . 123.3.5 100 Requests mit 2 CORSO Runtimes . . . . . . . . . . . . . . . . . 133.3.6 10 Requests CORSO vs JMS . . . . . . . . . . . . . . . . . . . . . . 133.3.7 100 Requests CORSO vs JMS . . . . . . . . . . . . . . . . . . . . . . 143.3.8 1000 Requests CORSO vs JMS . . . . . . . . . . . . . . . . . . . . . 14

3.4 Auswertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.5 Testergebnisse Testzyklus 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

i

3.5.1 10 Requests SEDA & CO . . . . . . . . . . . . . . . . . . . . . . . . 163.5.2 100 Requests SEDA & CO . . . . . . . . . . . . . . . . . . . . . . . 163.5.3 1000 Requests SEDA & CO . . . . . . . . . . . . . . . . . . . . . . . 173.5.4 10 Requests CORSO vs JMS . . . . . . . . . . . . . . . . . . . . . . 173.5.5 100 Requests CORSO vs JMS . . . . . . . . . . . . . . . . . . . . . . 183.5.6 1000 Requests CORSO vs JMS . . . . . . . . . . . . . . . . . . . . . 18

3.6 Gesamtauswertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

ii

Kapitel 1

Technischer Entwurf

1.1 Staged Event-Driven Architecture (SEDA)

Bei der herkommlichen SEDA Architektur werden Aufgaben (Berechnungen) in Teilauf-gaben (Stages) zerlegt. Diese Stages werden uber Event Queues miteinander verbunden.Jede Stage reprasentiert einen Zustand eines endlichen Automaten. Die Stages verfugenuber einen eigenen Thread Pool, wodurch das System in Hinblick auf Performancetuningmassiv konfigurierbar ist. Stages konnen parallel oder sequentiell ausgefuhrt werden undintern blockieren um Lastspitzen ausgleichen zu konnen. Blockierende Stages werden ei-ne geringe Anzahl von Threads zugeordnet, um Belastungsspitzen durch die Queues zuabsorbieren.

Abbildung 1.1: A SEDA-Based Web Server

Jeder Stage werden Event Handler Routinen zugeordnet. Event Handler erhalten meh-rere Events, verarbeiten diese und stellen die resultierenden neuen Events in die nachfol-genden Queues.

Abbildung 1.2: Interner Aufbau einer Stage

1

1.2 Framework STEAM

STEAM (STaged Enterprise Architecture and More) ist ein SEDA basierendes Frame-work, das in der SPARDAT, im Rahmen des Projekts TINA (Telebanking IMC New Age),entwickelt worden ist. Wichtige Aspekte von STEAM sind asynchrone Verarbeitung, Ro-bustheit gegenuber Belastungsspitzen und naturlich hohe Performance. Die Event Queues,welche die Stages verbinden, sind mit JMS Queues realisiert worden, um den vorgegebenenArchitekturstandards zu entsprechen. Die STEAM Implementierung der SEDA Architek-tur verwendet anstelle des Begriffes Stage den Begriff Channel. Jeder Channel hat einenThread Pool fur die Parallelisierung von Subaufgaben zugewiesen. Die Channels verfugenuber einen eindeutigen Identifier. Somit ist es moglich, mehrere Channels mit unterschied-lichen Event Handler Routinen zu konfigurieren und die Last gleichmaßig auf mehrereChannels zu verteilen. Durch die konfigurierbare Anzahl der Threads kann man Zugrif-fe auf Backendsysteme begrenzen (Abarbeitung blockieren), da diese unter der massivenLast zusammenbrechen konnen. (Bsp.: Begrenzte Anzahl an DB Connections) In der JMSVariante werden Message Driven Beans fur das Dequeuing verwendet - daher kein aktivesPolling auf die Queues.

1.3 Abarbeitung in STEAM

Die Abarbeitung in STEAM ist Workflow basierend. Ein Workflow wird ahnlich einemPetri Netz beschrieben und abgearbeitet. Dabei besteht ein Workflow aus mehreren Akti-vitaten, die Transitions zugeordnet werden. Eine Transition aktiviert die fur den aktuel-len Workflowschritt definierte Aktivitat und initiiert den Ubergang zum nachsten Work-flow Schritt. Innerhalb des Workflows kann aufgrund des aktuellen Status des Modelsauf unterschiedliche Workflowpfade (Outlets) verzweigt werden. Die Junction ist dafurzustandig, die nachfolgende Transition zu ermitteln. Dazu werden Conditions am aktuel-len Model ausgewertet. Zu jeder Transition konnen N Junctions definiert werden. Junc-tions konnen mehrere Eingange (Inlets) besitzen und dienen dann zur Synchronisierung(Zusammenfuhrung) paralleler Aktivitaten.

Abbildung 1.3: Aufbau eines Workflows

Beim Starten der Applikation werden die einzelnen Channels instanziert und die Event

2

Handler bei den jeweiligen Channels registriert Die Entwicklung eines konkreten Work-flows ist einfach, da das darunter liegende Framework den Entwickler von technischenDetails abschirmt. Die Entwicklung beschrankt sich auf Spezifikation des Workflows undImplementierung der einzelnen Aktivitaten.

Jede Aktivitat bekommt bei der Ausfuhrung einen Context ubergeben. Im Contextenthalten ist das Model, das den Workflow durchlauft und dessen Daten manipuliert wer-den. Der Typ des Models bestimmt den konkreten Workflow, welcher durchlaufen wird.Intern wird ein Workflow mit Hilfe des Composite Patterns realisiert. Die Aktivitaten sindstateless und operieren lediglich auf dem aktuellen Model (Flyweight Pattern).

Eine Aktivitat wird durch den registrierten Event Handler angestossen. Nach Abar-beitung der Aktivitat wird die Schaltbedingung (LatchCondition) ausgewertet. Ist dieseerfullt, so wird fur die nachfolgenden Transitionen (Outlets) der Context in die jeweili-gen Event Queues gestellt. Durch die Schaltbedingung werden die einzelnen parallelenAktivitaten synchronisiert.

1.4 CORSO Event Queues

Die Event Queues werden in Java & Co realisiert. Dabei soll das bestehende API eingehal-ten werden. Die Enqueueing und Dequeueing Operationen mussen performant realisiertwerden, da diese fur die Gesamtperformance von entscheidender Bedeutung sind. UmBusy-Waits zu vermeiden, werden der Notification Mechanismus und das blockierendeLesen von Objekt IDs verwendet.

Da die unterschiedlichen Rechner als GRID miteinander agieren, reicht es nicht aus,nur den zuvor beschriebenen Context in den CORSO Space zu serialisieren. ZusatzlicheInformationen, die fur die Synchronisation notwendig sind, mussen ebenfalls berucksichtigtwerden. In STEAM wird uber den SessionContext fur zusammengehorige Workflows undParallele Aktivitaten ein gemeinsamer Kontext geschaffen. Dieser SessionContext muss inder CORSO Implementierung ebenfalls in den Space serialisiert werden. Da Aktivitatenparallel in unterschiedlichen VMs verarbeitet werden, bietet sich der Corso NotificationMechanismus an, um den gemeinsamen SessionContext immer aktuell zu halten. So schafftman die Moglichkeit uber VM Grenzen hinweg zu synchronisieren und notwendige Datenauszutauschen.

Da in den bestehende Workflow Engine moglichst wenig eingegriffen werden soll undauch die Workflow Entwicklung handhabbar bleiben soll, werden alle notwendigen Kom-ponenten uber den Java Reflection Mechanismus in den Space serialisiert.

1.4.1 Konfiguration der Event Queues

Der Server wird uber mehrere Propertiefiles konfiguriert. Im File seda.properties werdendie projektweiten Properties definiert. Den Properties werden Umgebungen zugeordnet(Bsp. SIM fur Simulation) und sind nur in dieser Umgebung aktiv. Die verwendetenChannels werden in diesem Property File definiert und beim Hochfahren des Systemsinstanziert. Die in Corso definierten Event-Queues werden dort unter einer eigenen Umge-bung definiert. So kann der Server uber ein VM Argument mit CORSO order JMS Queuesgestartet werden. Die Komponenten von STEAM werden uber Reflection instanziert. Die

3

Queues selbst werden durch eine eigene Factory erzeugt.

1.4.2 Aufbau der CORSO Event Queues

Der Aufbau der Event Queues ist dem Publish-Subscriber Pattern sehr ahnlich. Internwerden die Corso Event Queues als eine FIFO Datenstruktur realisiert, um Starvation zuvermeiden. In einer Erweiterung konnte man die Messages noch mit Prioritaten versehen.(Gefahr: unfairness, starvation).

Die Event Queues werden als verkettete Listen mit einem Zeiger auf den Anfang (Cor-soNamedVarOID) und einem Zeiger auf das Ende der Liste (CorsoNamedVarOID), umdie Enqueuing und Dequeuing Operationen zu optimieren, implementiert.

Abbildung 1.4: Event Queue Datenstruktur

Funktion add (CorsoBuffer) Die Funktion add() ubergibt den Context an den Con-textTransformer (encodeFor()). Dieser ist fur die Transformation und die Serialisierungdes Context zustandig. Da der Context sehr viele Daten, welche fur die Abarbeitung notigsind, beinhaltet, wird dieser aus Performancegrunden nur einmal in den Space serialisiert.Der ContextTransformer uberpruft, ob der ubergebene Context bereits im Space vorhan-den ist. Ist der Context noch nicht im Space vorhanden, so wird dieser in den Spaceserialisiert. Als Output liefert der ContextTransformer eine CorsoMessage, welche eineReferenz auf den Context im Space beinhaltet.

Die zuruckgelieferte CorsoMessage wird mit Hilfe der Funktion appendShareable() andas Ende der spezifizierten Liste eingehangt und der Zeiger, der auf das Ende der Queuezeigt (TailOid), wird auf den Nachfolger der CorsoMessage gesetzt. Die Funktion add()wird fur jede nachfolgende Transition aufgerufen - daher wird ein und derselbe Context,bei Parallelausfuhrung, von mehreren CorsoMessages referenziert.

4

/**

* Method which appends a Message to the stream

* @param message

*/

public void appendShareable(CorsoMessage message) {

while (true) {

if (!getTailOid().test(tx)) { // is tailOid empty?

tx.cancelRequest(getTailOid().lastRequestNr()); // cancel last transaction

getTailOid().readShareable(tmpMessage, null, INFINITE_TIMEOUT); // read successor

setTailOid(tmpMessage.getNextOid()); // update tailOid

} else {

message.setNextOid(Primitives.getNewCorsoConstOid()); // create new tailOid

getTailOid().writeShareable(message, tx); // write message to space

setTailOid(message.getNextOid());

getQueueOid().writeShareable(this, tx); // update tailOid in space

tx.commit(1); // commit transaction

break;

}

}

}

Listing 1.11 Funktion appendShareable

Funktion remove (CorsoBuffer) Die Funktion remove() versucht die nachste Messa-ge aus dem Space transaktionell zu lesen. Wird ein CorsoMessage Objekt zuruckgeliefert,so wird diese mit Hilfe des ContextTranformers wieder in ein Context Objekt transfor-miert. Dabei wird der referenzierte Context aus dem Space gelesen und die nachste zuverarbeitende Transition aus dem Context Objekt im Space geloscht, um eine Mehrfach-ausfuhrung von Aktivitaten zu verhindern. Ist keine Message in der Liste, so blockiertdie Funktion consumeShareable() mit Hilfe des Event Mechanismus von CORSO bis eineneue Transition, die ausgefuhrt werden darf (LatchCondition) in der Queue verfugbar ist.Danach wird der Zeiger, der auf den Anfang der Queue (HeadOid) zeigt, auf das nachsteElement gesetzt. Der Context wird an den registrierten Event Handler ubergeben.

/**

* Method which consumes a WorkItem from the stream

* @param item

*/

public CorsoMessage consumeShareable(){

getQueueOid().setTimeStamp(0);

getQueueOid().readShareable(this, tx, INFINITE_TIMEOUT); // get latest headOid

getHeadOid().readShareable(message, null, INFINITE_TIMEOUT); // read Message or block

setHeadOid(message.getNextOid());

getQueueOid().writeShareable(this, tx); // update headOid in Space

tx.commit(INFINITE_TIMEOUT); // commit transaction

return message;

}

Listing 1.2 Funktion consumeShareable

5

1.5 Klassendiagramm

Das Klassendiagram in Abbildung 1.5 zeigt den Zusammenhang der wichtigsten Klassen.

Abbildung 1.5: Klassendiagramm

1.6 Links im WWW

A Design Framework for Highly Concurrent Systemshttp://www.eecs.harvard.edu/ mdw/papers/events.pdf

Enabling Robust Performance for Busy Internet Serverhttp://www.eecs.harvard.edu/ mdw/talks/seda-lecture-uw.pdf

SEDA Framework (Sourceforge Projekt)http://sourceforge.net/projects/seda

6

Kapitel 2

Testkonzept

2.1 Allgemein

Der Test des Frameworks STEAM basierend auf CORSO wird in 3 Abschnitten durch-gefuhrt. Der erste wichtige Teil ist der Referenztest der bestehenden Architektur, umReferenzwerte fur die nachfolgenden CORSO Tests zu erlangen. Der Test des Frameworksbasierend auf CORSO, ist in zwei Zyklen unterteilt. Im ersten Zyklus wird das Systemunter Last getestet und mit den zuvor gewonnenen Referenzwerten verglichen. Die ausdiesem Test gewonnenen Erkenntnisse sollen fur Verbesserungen und Performancetuningherangezogen werden. Nach dem Performancetuning wird der Test wiederholt und diegewonnen Ergebnisse werden anschaulich dargestellt.

2.2 Testtools

Um bereits bestehende Testtolls verwenden zu konnen, wurde ein Webinterface entwickeltuber das die Verarbeitung am Server angestoßen werden kann. Um den Server unter Last zusetzen, wird Rational TestStudio verwendet. Rational TestStudio ermoglicht es, virtuelleUser zu simulieren. Dabei werden C++ ahnliche Skripts geschrieben, die das vorgegebeneWebinterface aufrufen, das Ergebnis validieren und die Response Time vermerken.

2.3 Testplan

Um moglichst viele Erkenntnisse uber das Performance Verhalten des zugrundeliegendenSystems zu erhalten, wird die Last schrittweise erhoht. Dabei werden die Anzahl derparallelen Benutzer (virtuellen User) und die Anzahl der Iterationen erhoht.

2.4 Mengengerust Testzyklus

• 10 parallele Benutzer mit 1000 jeweils Iterationen

• 100 parallele Benutzer mit 1000 jeweils Iterationen

• 1000 parallele Benutzer mit 1000 jeweils Iterationen

7

Der Testdurchlauf wird zuerst auf einem Rechner, dann auf einem GRID (CORSOVariante), bestehend aus 5 Rechnern und abschließend auf einem GRID, bestehend aus10 Rechnern wiederholt.

2.5 Test Konfiguration

Fur die Benchmark Tests stehen 9 Desktoprechner zur Verfugung. Die Rechner befindensich im selben Netzwerk, daher ist nicht mit Netzwerk Latenzen zu rechnen.

Kenndaten der Rechner

• Intel Pentium IV 2,4 GHz

• Arbeitsspeicher 1024 MB

• OS Windows 2000

2.6 Referenztest STEAM mit JMS

Das bestehende Framework, basierend auf JMS, ist nicht GRID Computing fahig. DieRechner laufen nicht im Cluster. Die einzelnen Requests werden uber einen Loadbalancerauf die unabhangigen Serverinstanzen verteilt. Der Loadbalancer nimmt die Requests ent-gegen und verteilt diese an die einzelnen Server nach dem Round Robin Verfahren. DieRequests werden uber das http Protokoll an die einzelnen Serverinstanzen weitergeleitet.Die Applikation lauft unter BEA Weblogic Server 6.1 SP6 und Java Runtime 1.3.1.

2.7 Test STEAM mit CORSO

ahnlich wie beim Referenztest fungiert ein Rechner als Entry Point. Dieser nimmt dieRequests entgegen und publiziert diese in den Space. Da BEA WL 6.1 nur die Java Runtime1.3.1 unterstutzt, wird bei den CORSO Tests ebenfalls die Java Runtime 1.3.1 verwendet.

Bei den Tests des Frameworks basierend auf CORSO werden folgende Konfigurationender CORSO Runtime getestet:

• Eine Corso Runtime - alle 10 Rechner verbinden sich auf die Runtime

• Start von 2 Corso Runtimes welche miteinander verbunden sind

Der zuvor beschriebene Testdurchlauf wird mit beiden Konfigurationen durchlaufen.

2.8 Testauswertung

Wichtigstes Kriterium fur den Erfolg der Tests ist die Stabilitat und Robustheit des Sys-tems unter Beweis zu stellen, und naturlich die Korrektheit der Ergebnisse. Ohne dieseVoraussetzungen hatten die Aussagen uber die Performance wenig Gewichtung.

Response time der einzelnen Requests, CPU Auslastung, Speicherverbrauch der ein-zelnen Serverinstanzen und die Zeit fur die durchschnittliche Zeit der einzelnen QueingOperationen werden zur Auswertung herangezogen.

8

2.9 Erwartetes Ergebnis

Bei einzelnen Requests ist zu erwarten, dass sich beide Systeme annahrend gleich verhalten.Durch die Steigerung der Last bis zur Maximalauslastung (CPU Verbrauch annahrend100%) ist zu erwarten, dass sich das System mit Corso besser im Bezug auf ResponseTime und Robustheit verhalt, da die einzelnen Aktivitaten auf mehrere Rechner verteiltlaufen, und die Ressourcen besser ausgenutzt werden.

Bei Lastspitzen ist eine bessere Verteilung der Last zu erwarten, da die einzelnenRechner bei der CORSO Variante als GRID agieren. Performanceeinbußen durch denOverhead der Synchronisation der einzelnen Aktivitaten, welche in unterschiedlichen VMslaufen, sollten durch die verbesserte Auslastung des Systems kompensiert werden.

9

Kapitel 3

Testauswertung

3.1 Vorbedingungen

Fur die Benchmarktests standen 9 Rechner zur Verfugung. Auf 2 Rechnern war Weblogic6.1 SP 6 installiert und konfiguriert. Die CORSO Runtime konnte auf 2 Rechnern installiertwerden.

3.2 Testdurchfuhrung

Die einzelnen Tests wurden uber ein Testprogramm gestartet. Dabei wurde die Zeitmes-sung durch Mitprotokollieren der Anfangs- und Endzeiten vorgenommen. Das Testpro-gramm startete jeweils 10, 100 oder 1000 parallele Threads, welche die Testrequests amServer absetzten.Bei den ersten CORSO Tests war die CORSO Runtime auf einem Rechner gestartet unddie einzelnen Rechner haben sich auf die Runtime verbunden.Abschließend wurde noch eine zweite Runtime gestartet, welche sich mit der ersten syn-chronisierte.

3.3 Testergebnisse Testzyklus 1

Nachfolgend sind die Ergebnisse des ersten Testdurchlaufs graphisch dargestellt.

10

3.3.1 10 Requests SEDA & CO

3.3.2 100 Requests SEDA & CO

11

3.3.3 1000 Requests SEDA & CO

3.3.4 10 Requests mit 2 CORSO Runtimes

12

3.3.5 100 Requests mit 2 CORSO Runtimes

3.3.6 10 Requests CORSO vs JMS

13

3.3.7 100 Requests CORSO vs JMS

3.3.8 1000 Requests CORSO vs JMS

14

3.4 Auswertung

Die Tests haben ergeben, dass die Granularitat der einzelnen Aktivitaten von entscheiden-der Bedeutung sind. Die ersten Tests (Telebanking Business Case) wurden abgebrochen,da die Aktivitaten zu wenig Ressourcen verbraucht haben und das System daher nicht,wie erwartet, skaliert hat. Sind die Aktivitaten zu klein oder nicht CPU intensiv, so isteine Verteilung auf mehrere Rechner, selbst bei großer Last, nicht sinnvoll.

Beide Systeme haben sich selbst unter hoher Last stabil verhalten. Jeder Request wurdeordnungsgemaß bearbeitet.

Bei wenigen parallelen Requests (< 20 Threads) verhalten sich die beiden Systemeannahernd gleich. Bei hoherer Belastung des Systems macht sich bei der CORSO Varianteder Synchronisations Overhead bemerkbar. Die JMS Variante hat keinen SynchronisationsOverhead, da ein Request an den Server gebunden ist und nicht verteilt ablauft.

Die Skalierbarkeit des Systems hat seine Grenzen. Mit 9 Rechnern wurde nicht mehrPerformance erreicht als mit 5 Rechnern.

Auffallend ist die Performancekennlinie der beiden Systeme. Bei beiden Varianten istdie Kennlinie annahrend linear ansteigend. Dieses Verhalten ist durch die asynchrone Ver-arbeitung der einzelnen Requests bedingt. Da die einzelnen Requests annahernd gleichzei-tig gestartet wurden, befinden sich am Anfang alle Requests in der ersten Queue. Diesewerden je nach Anzahl der Queuelistener parallel verarbeitet. Daher hat der Request,welcher als letzter in die Queue gestellt wird, auch die langste Ausfuhrungszeit.

3.5 Testergebnisse Testzyklus 2

Beim Analysieren der Testergebnisse ist aufgefallen, dass die Implementierung der EventQueues zu viele Nachrichten uber das Netzwerk schickt. Dies hatte zur Folge, dass beisteigender Knotenanzahl das System nicht mehr skalierte. Daher wurde die kompletteImplementierung der Event Queues erneuert. Als Basis fur die neuen Event Queues dientder Corso Notification Mechanismus. Die Ergebnisse des zweiten Testdurchlaufs sind aufden folgenden Seiten graphisch dargestellt.

15

3.5.1 10 Requests SEDA & CO

3.5.2 100 Requests SEDA & CO

16

3.5.3 1000 Requests SEDA & CO

3.5.4 10 Requests CORSO vs JMS

17

3.5.5 100 Requests CORSO vs JMS

3.5.6 1000 Requests CORSO vs JMS

18

3.6 Gesamtauswertung

Der zweite Testdurchlauf konnte ebenfalls positiv durchgefuhrt werden. Beide Systemehaben sich selbst unter hoher Last stabil verhalten. Jeder Request wurde ordnungsgemaßbearbeitet. Die Anderung an den Event Queues hatte ihr gewunschtes Ziel erreicht. DasSystem konnte noch einiges an Performance gegenuber der Weblogic JMS Implementie-rung gewinnen. Besonders positiv aufgefallen ist die Skalierbarkeit der Corso NotificationImplementierung. Das System hat die Last auf alle beteiligten Knoten verteilt und dieAntwortzeit verhielt sich annahrend proportional zur Anzahl der beteiligten Knoten. DiePerformancekennlinie hat sich trotz neuer Implementierung nicht wesentlich geandert. DieCorsoNotification verhalt sich unter hoher Last wie eine FIFO Datenstruktur.

Der großte Vorteil der SEDA & CO Variante gegenuber der JMS Variante ist dieVerteilung einzelner Aktivitaten auf unterschiedlichen Knoten. Dieses Feature ist von be-sonderer Bedeutung, wenn die Aktivitaten massiv parallel abgearbeitet werden konnen.Bei der JMS Variante ist ein Request an eine Server Instanz gebunden und kann dahernicht verteilt ablaufen. CPU intensive Requests (z.B.: Compilieren von Sourcen) konnendaher bei der JMS Implementierung einen Stau in den einzelnen Event Queues verursa-chen.

Wiederaufsatz und Failover ist bei der SEDA & CO Variante moglich. Ein automati-sches Failover bei mehreren Knoten ist durch die Corso Runtime gegeben. Ein Wiederauf-satz wird vom STEAM Framework zum Teil unterstutzt, jedoch muss der Anwender desFrameworks eine geeignete Wiederaufsatz Strategie fur seinen Businesscase selbst entwi-ckeln.

Die JMS Variante hat bei fein granularen Aktivitaten, die wenig Ressourcen verbrau-chen, einen Performance Vorteil – da die einzelnen Queuing Operationen nicht so aufwen-dig sind und im Gegensatz zur Corso Implementierung kein Synchronisations Overheadanfallt.

19