Lasttests für Mandantenfähigkeit in dWb+

vorhergehende Artikel in: dWb+ Software-Test
27.10.2015

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.

Dataflow Workbench dWb+ 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

Verschiedene Interaktionsmetaphern in dWb+

18.09.2016

Nach Fertigstellung einiger Module, die die Kommunikation zwischen Komponenten auf Dateiebene unterstützen, werde ich versuchen, verschiedene Interaktionsmetaphern bzw. Kommunikationsstrategien aus anderen datenflussgetriebenen Systemen in dWb+ nachzuvollziehen, um die Effizienz der Implementierung und die Vor- und Nachteile ihrer Anwendung diskutieren zu können.

WebSocket Server in dWb+

08.11.2015

Bereits vor einigen Jahren wurde für dWb+ die Einführung von Mandantenfähigkeit diskutiert. Die aus der Schublade geholte Implementierung wurde nach erfolgreichen Lasttests für die Entwicklung von Servern verschiedenster Art eingesetzt.

JMeter Links

19.10.2015

Nachdem ich vor einiger Zeit die Durchführung von Lasttestst zur Verifikation der Mandantenfähigkeit in dWb+ vorgestellt habe, hier noch eine Sammlung von Links zum Thema JMeter...

Alle Artikel rss Wochenübersicht Monatsübersicht Github Repositories Gitlab Repositories Mastodon Über mich home xmpp


Vor 5 Jahren hier im Blog

Neueste Artikel

  • SQL Funktionen in SQLite als BeanShell-Scripts

    Ich habe bereits hin und wieder über Erweiterungen der sQLshell berichtet, die bestimmte spezifische, proprietäre Features des jeweiligen DBMS in der sQLshell verfügbar machen.

    Weiterlesen...
  • Spieleengine IX

    Es gibt seit Ewigkeiten mal wieder Neues von meiner eigenen Spieleengine!

    Weiterlesen...
  • Neue Version plantumlinterfaceproxy napkin look

    Es gibt eine neue Version des Projektes plantumlinterfaceproxy - Codename napkin look.

    Weiterlesen...

Manche nennen es Blog, manche Web-Seite - ich schreibe hier hin und wieder über meine Erlebnisse, Rückschläge und Erleuchtungen bei meinen Hobbies.

Wer daran teilhaben und eventuell sogar davon profitieren möchte, muß damit leben, daß ich hin und wieder kleine Ausflüge in Bereiche mache, die nichts mit IT, Administration oder Softwareentwicklung zu tun haben.

Ich wünsche allen Lesern viel Spaß und hin und wieder einen kleinen AHA!-Effekt...

PS: Meine öffentlichen GitHub-Repositories findet man hier - meine öffentlichen GitLab-Repositories finden sich dagegen hier.