Bereits vor einigen Jahren wurde für dWb+ die Einführung von Mandantenfähigkeit diskutiert. Die aus der Schublade geholten Implementierungen wurden nach leichten Änderungen in verschiedenen Szenarien Lasttests unterzogen.

Die Lasttests wurden für das im vorhergehenden Artikel zu diesem Thema beschriebene Szenario A durchgeführt: In diesem ersten Szenario geht es um die Umsetzung eines einfachen HTTP-Servers, der basierend auf der abgeforderten URL eine Datenverarbeitung anstößt und das Ergebnis der Datenverarbeitung an den Anfragenden zurückliefern soll. Der Workflow wurde gegenüber dem beschriebenen ein wenig geändert: Statt eines BeanContext-Service zur HTTP-Protokollunterstützung wurde ein Modul geschaffen, das einen Serversocket für einen konfigurierten Port öffnet. Dieses Modul startet einen eigenen Thread für jede eingehende Client-Verbindung. Dieser Thread öffnet den InputStream des Client-Socket und liest den Request ein. Er extrahiert die (absolute) URL aus dem Request. Dies ist das Datum, das das Modul an seinem Ausgangsslot bereitstellt. Gleichzeitig wird im Context für dieses Datum der Client-Socket gespeichert, der durch das Server-Modul nicht geschlossen wird.

Daran wurde ein Modul geschaffen, das eine Auswertung auf der eingehenden URI vornahm (sie wurde einfach in einen String umgewandelt) und diese dann weiterreichte: aus einem Eingangssignal wurden zwei Ausgangssignale. Damit konnte geprüft werden, ob der Context wirklich korrekt weiterpropagiert wurde, auch wenn das propagierende Modul gar nicht mit den Daten in ihm arbeiten wollte. Weiterhin konnte man damit prüfen, ob die Vervielfältigung eines Contexts funktioniert: Am Ausgang des Moduls wurden aus einem Eingangsdatum zwei Ausgangsden erzeugt - jedes davon hatte die korrekte Context-Information übernommen. Das Modul wurde als nebenläufiges implementiert, da Nebenläufigkeit eine besondere Herausforderung bei einer zentralen Verwaltung von Contexten darstellt.

Danach wurde die URI wie bereits gesagt weitergereicht an Module, die den Inhalt des Contexts auslesen und damit arbeiten.

Dazu wurden zwei Module geschaffen, die für die Antwort an den Client verantwortlich sind: Dabei wurde eine nicht nebenläufige Variante geschaffen und eine nebenläufige, da Nebenläufigkeit eine besondere Herausforderung bei einer zentralen Verwaltung von Contexten darstellt.

Die Funktionalität beider Module ist gleich: Das Modul setzt eine HTTP-Response zusammen, indem es den ReturnCode für HTTP einsetzt und einige Header-Felder definiert - unter anderem den Mime-Type (text/html). Weiterhin wird eine Payload für die Response erzeugt, die eine minimale HTML-Seite darstellt, in der der aktuelle Zeitstempel und die empfangene URI enthalten sind. Anschließend wird der Client-Socket aus dem Context geholt, dessen OutputStream geöffnet und die Response darüber versendet. Danach wird der Socket geschlossen und damit ist die Bearbeitung des Requests beendet.

Der Lasttest wurde mit JMeter durchgeführt - hier wurden 150 Clients simuliert, die die betreffende URL des Servers eine Minute lang mit Requests bombardierten - dabei wurde jeder Request individualisiert: es wurde jeweils eine zufällig generierte Zahl als Query-Parameter an die URL angehängt. Inhalt des JMeter-Tests war nun, dass der im Request mitgelieferte Wert dieses Parameters im Body der Response enthalten sein musste - damit konnte man nachweisen, dass der Context und das zugehörige Datum innerhalb dWb+ nicht durcheinandergekommen waren.

Die Tests liefen sowohl mit der nebenläufigen wie auch der nicht nebenläufigen Variante erfolgreich durch.

Artikel, die hierher verlinken

Kommentar hinzufügen (via ) Kommentare ansehen (via )

Kommentar hinzufügen (via ) Kommentare ansehen (via )