Performance verbessern

Dieser Abschnitt erläutert Möglichkeiten zur Verbesserung der Leistungsfähigkeit der INUBIT-Software.

Allgemeine Hinweise

  • Workflows werden aus Zeitgründen mit kleineren Dateien entwickelt und getestet, als sie tatsächlich in der Produktion verwendet werden. Versuchen Sie, bereits beim Workflow-Design die tatsächliche bzw. maximale Dateigröße zu berücksichtigen!

  • Messen Sie die Leistung vor und nach jeder Optimierung Ihres Systems, um ausreichend genau feststellen zu können, ob die Optimierung zu einer Leistungsverbesserung geführt hat.

Bei Hochlast wird empfohlen, einen Virenscanner-Ausschluss für das Verzeichnis <inubit-installdir>/inubit/server/ibis_root zu einer normalen Process Engine-Installation einzurichten.

INUBIT-Software optimieren

Parallelisierung

Die INUBIT-Software kann standardmäßig Technical Workflows parallel in mehreren, voneinander unabhängigen Threads ausführen. Wie viele Threads maximal parallel ausgeführt werden können, ist abhängig von Ihrer Lizenz und der Konfiguration des Workflow-Threadpools. Zusätzlich können Sie auch mehrere Prozesse eines Technical Workflows parallel ausführen lassen.

Bei Einsatz der INUBIT-Software auf einer Ein-Prozessor-Maschine erhöht der Einsatz von maximal zehn parallelen Threads den Nachrichtendurchsatz und optimiert die Auslastung der Maschine. Denn in einer durchschnittlichen Maschine kann oft ein Teil der Rechenzeit nicht genutzt werden, weil häufig auf relativ langsame, externe Ereignisse gewartet werden muss, wie z.B eine Benutzereingabe oder Netzverbindung. Die so entstehende Wartezeit kann von anderen Threads genutzt werden. Wenn die Maschine dagegen z.B. durch einzelne rechenintensive Threads ausgelastet ist, dann führt der Einsatz paralleler Threads dazu, dass dennoch mehrere Threads anteilige Rechenzeit erhalten, statt auf das Ende eines anderen, rechenintensiven Threads warten zu müssen.

Siehe

Application Server

Hinweise zu leistungssteigernden Änderungen des von Ihnen eingesetzten Application Servers erhalten Sie in der technischen Dokumentation der jeweiligen Hersteller.

Performance-Analyse

Objekt Anzeige

Auslastung des Systems (Festplatte, Prozessor, Speicher)

Register Reporting > als Standard-Reports

Ausführungszeiten von Workflows und Modulen

Sie können die Report-Einstellungen individuell anpassen, siehe Reporting und fachliches Monitoring.

Verfügbarer Arbeitsspeicher

Register Administration > Allgemein > Verwaltung > Server

Speicherverbrauch der INUBIT Workbench

INUBIT Workbench > Statusinformation

Siehe Speicherverbrauch/Garbage Collector.

Speicherverbrauch der JVM

Auslesen mithilfe eines Workflows mit dem Utility IS Configuration.

Siehe INUBIT IS Configuration.

JVM der Process Engine optimieren

Dieser Abschnitt erläutert Möglichkeiten, die Speicherallokation und Garbage Collection der JVM zu optimieren. Diese beiden Faktoren sind wichtig für die Performance Ihres Tomcat-Applikationsservers in Hochlast-Szenarien.

Die Optimierung der JVM-Performance sollte immer vor der Hardware-Aufrüstung des Servers durchgeführt werden. Die zu erzielenden Performance-Verbesserungen werden oft unterschätzt! Gerade im High-End-Bereich werden erfolgreich Linux-Systeme eingesetzt, bei denen im Vergleich zu Windows-Systemen ein größerer maximalen JVM-Heap zu erzielen ist.

Hintergrund

Die JVM verfügt über einen speziellen Bereich im Arbeitsspeicher, den Heap. Dort werden Java-Objekte erzeugt und verwaltet. Ein Teil dieses Heaps wird fest zugewiesen, der andere virtuell reserviert und erst genutzt, wenn der fest zugewiesene Speicher nicht mehr ausreicht.

Der Heap wird regelmäßig durch die Garbage Collectoren (GC) aufgeräumt, um unbenutzten Speicher wieder freigeben zu können. Die Arbeit der GC beeinträchtigt die Performance. Je seltener ein GC startet und je weniger Zeit dies in Anspruch nimmt, desto besser wird die Performance des Application Servers.

Die Zuweisung von Speicher (sog. Speicherallokation) und die Garbage Collection können mithilfe von Parametern in der Datei setenv.[bat/sh] beim Start der JVM optimiert werden:

  • -Xms legt die Größe des fest zugewiesenen, initial zur Verfügung stehenden Speicherplatzes der JVM fest.

  • -Xmx definiert die maximale Größe des Heaps. Diese Größe errechnet sich aus dem fest zugewiesenen plus dem virtuellen Speicher. Die maximale Größe ist u.a. abhängig vom Betriebssystem.

    Wenn der Heap-Speicher zu klein dimensioniert ist, dann finden zu häufig Garbage Collections statt. Während dieser Zeit reagiert die Applikation abhängig vom gewählten GC-Mechanismus langsam. Dies führt zu schlechter Performance und langsamen Antwortzeiten.

    Der Heap teilt sich in zwei große Bereiche:

    • Young Generation (YG): Für neu erzeugte Objekte, die oft kurzlebiger sind und entsprechend häufiger im Rahmen einer einfachen GC eingesammelt werden.

    • Tenured Generation (TG): Enthält ältere Objekte, die vorher bereits mehrere GC-Läufe in der Young Generation überlebt haben. Eine GC in diesem Bereich ist oft zeitaufwändig. Die Frequenz der GC in der Tenured Generation wird im Wesentlichen durch die Größe der TG beeinflusst: je größer, desto seltener muss die GC nach nicht mehr verwendeten Objekten suchen, um Speicherplatz freizugeben.

    • Permanent Generation (PG): Bereich, in dem Objekte angelegt werden, von denen a priori eine lange Lebensdauer zu erwarten ist, wie z.B. Klassenobjekte. Alles zusammen ergibt den JVM-Speicher.

Faustregel für die Dimensionierung des Arbeitsspeichers

Xmx + (40 % von Xmx) + Speicher fürs Betriebssystem. Beispiel: 1 GB + 400 MB + 500 MB = 1,9 GB Arbeitsspeicher

Den Xmx erhöhen Sie am besten in 32 MB Schritten. Stellen Sie genug realen physischen Speicher bereit. Swapping führt zu drastischen Performance-Einbußen.

Die folgende Tabelle enthält einige Beispiele für Xmx-Einstellungen für bestimmte Arbeitsspeichergrößen und verschiedene INUBIT-Konfigurationen.

Xmx-Wert RAM-Größe

1024M/1G
2048M/2G
3072M/3G
5120M/5G

2048M/2G
4096M/4G
5120 M/5G
8192M/8G

Weitere Informationen siehe https://www.oracle.com/technetwork/tutorials/tutorials-1876574.html

Beachten Sie, dass alle Optimierungshinweise direkt von der eingesetzten JVM-Version abhängig sind. Bei Bedarf wenden Sie sich an den Support der Virtimo AG.

JVM der Workbench optimieren

Verwendung

Um den JVM-Speicher für die Workbench zu optimieren, zum Beispiel beim Auftraten von Speicherproblemen

So gehen Sie vor

  1. Beenden Sie die Workbench.

  2. Öffnen Sie im Verzeichnis <inubit-installdir>/inubit/client/bin die Datei start_workbench.sh oder start_workbench.bat.

  3. Gehen Sie zu der Zeile, die Xmx512M enthält.

  4. Erhöhen Sie den bisherigen Wert Xmx512M (512 MByte), zum Beispiel auf: Xmx1G (1 GByte)

  5. Speichern Sie die Datei start_workbench.

  6. Starten Sie die Workbench.

  7. Treten in der Workbench weiterhin Speicherprobleme auf, wiederholen Sie Schritt 1 bis Schritt 7, indem Sie den Xmx-Wert um ein weiteres GByte erhöhen.

Netzwerk und Hardware optimieren

Ein weiterer Faktor, der die Performance Ihres Systems beeinflusst, ist die Leistungsfähigkeit der Verbindungen zwischen der INUBIT Workbench und der INUBIT Process Engine sowie der INUBIT Process Engine und Drittsystemen wie z.B. Datenbanken oder Partnersysteme.

Hardware

Auch die Hardwareausstattung hat einen erheblichen Einfluss auf die Leistungsfähigkeit Ihres Systems. Grundsätzlich erhöhen ein schnellerer Prozessor, mehr Arbeitsspeicher sowie eine schnelle Festplatte die Performance des Systems.

Bei der Dimensionierung des Arbeitsspeichers kann folgende Faustregel verwendet werden: Nachrichten und Variablen werden während ihrer Bearbeitung in einem Workflow mit nicht-streaming-fähigen Modulen zum großen Teil im Arbeitsspeicher gehalten. Dabei hat eine Nachricht mit einer Größe von rund 100 MB den ca. drei-fünffachen Bedarf an Arbeitsspeicher. Wenn mehrere Prozesse eines oder mehrerer Technical Workflows parallel ausgeführt werden, dann muss der Arbeitsspeicher für die maximale Anzahl parallel laufender Prozesse ausreichend dimensioniert sein!

Streaming-fähig sind folgende Modultypen. Siehe:

Speichereinstellungen von Remote Connector und INUBIT optimieren

Dieser Abschnitt beschreibt die empfohlenen Einstellungen für die Optimierung der Speicherzuweisung von Remote Connector und INUBIT auf der Grundlage der Dateigröße.

Derzeit werden Dateien, die größer als 1 GB sind, nicht unterstützt.

In der folgenden Tabelle sind die empfohlenen Einstellungen für den Xmx-Wert (MB) in den folgenden Dateien aufgeführt:

  • Remote Connector: start_rc.[bat/sh]

  • INUBIT: setenv.[bat/sh]

Dateigröße (MB) Remote Connector INUBIT Bemerkungen

< 250 MB

2048 MB

4096 MB

Standardwerte

> 250 MB < 500 MB

4096 MB

4096 MB

Remote Connector-Speicher auf 4096 MB erhöhen.

> 500 MB < 1 GB

8182 MB

8182 MB

Remote Connector und INUBIT Speicher auf 8182 MB erhöhen.

Benchmark-Workflows

Verwendung

Mit Benchmarks-Workflows können Sie Hardware, die zusammen mit der INUBIT-Software eingesetzt werden soll, mit einer Referenz-Hardware vergleichen und folgende Werte ermitteln:

  • Absolute Anzahl ausgeführter Workflows

  • Durchschnittliche Ausführungszeit der Workflows

  • CPU-Auslastung

Funktionsweise

Die mitgelieferten Benchmark-Workflows werden in einer vordefinierten Zeitspanne (Standard 3 Minuten) jeweils einmal, fünfmal und zehnmal parallel ausgeführt. Die Anzahl der erreichten Workflow-Durchläufe wird mit den für die Referenz-Hardware gespeicherten Werten verglichen.

Ein Faktor, der INUBIT-Benchmark-Index, gibt an, wie stark die getestete Hardware von der Referenz-Hardware abweicht. Der Referenzwert ist 10 und entspricht 100 %. Abweichungen nach unten oder oben zeigen an, dass auf der getesteten Hardware weniger oder mehr Workflows bearbeitet wurden als auf der Referenz-Hardware.

Referenz-Hardware

Die Ausstattung der verwendeten Referenz-Hardware finden Sie in der Reportdatei unter dem Eintrag ServerTest mit dem Attribut host='benchmarkReferenceServer'.

Eigene Benchmarks

Alternativ können Sie eigene Benchmark-Workflows erstellen und in eigenen Benchmark-Suiten verwenden. Anhand eigener Referenz-Hardware können Sie eigene Referenzwerte ermitteln und zum Ermitteln eines eigenen Benchmark-Index nutzen.

Die aus Ihren eigenen Referenzwerten ermittelten Indizes sind nicht mit dem zum Lieferumfang gehörenden INUBIT-Benchmark-Index vergleichbar.

Benchmark-Workflows vorbereiten und ausführen

So gehen Sie vor

  1. Importieren Sie das Diagramm mit den Benchmark-Workflows:
    <inubit-installdir>/inubit/benchmark/benchmark.diagramgroup.zip

  2. Aktiveren Sie alle Benchmark-Workflows.

    Das Benchmark Scenario 1 sowie das Benchmark Scenario 2 enthalten lizensierte Module. Mit der Basis-Lizenz lassen sich diese Module und somit die betreffenden Szenarien nicht ausführen.

  3. Wechseln Sie in das Verzeichnis <inubit-installdir>/inubit/benchmark.

  4. Öffnen Sie ein Kommandozeilenfenster und stellen Sie die Breite des Fensters auf mindestens 140 Zeichen ein, damit nur die Übersichtzeile aktualisiert wird.

  5. Starten Sie das für Ihr System geeignete Benchmark-Skript:

    • Unix/Linux: benchmark.sh

    • Windows: benchmark.bat
      Siehe Aufrufsyntax des Benchmark-Skripts.
      Beim ersten Starten eines Workflows wird der Server für den Workflow optimiert. In einer Aufwärmphase werden die Benchmark-Workflows daher fünfzigmal ausgeführt, bevor die eigentlichen Benchmark-Workflows starten.

  6. Zeigen Sie den Benchmark-Report an. Siehe Anzeige des Benchmark-Reports.

Aufrufsyntax des Benchmark-Skripts

Mit den Werten, die Sie beim Aufruf des Skripts setzen, überschreiben Sie die Werte in der Konfigurationsdatei <inubit-installdir>/inubit/benchmark/benchmark.properties.

Aufruf

Starten Sie das Benchmark-Skript von der Kommandozeile mit folgendem Aufruf:

benchmark [OPTIONS] [-server <server_name>] [‑r <report_file>]

  • -b|-benchmark <Benchmark-Suite>
    Auszuführende Benchmark-Suite, z.B.: -b fast
    Siehe Benchmark-Suite und Benchmark-Ablauf konfigurieren.

  • -c <Konfigurationsdatei>
    Pfad und Dateiname der Konfigurationsdatei
    Siehe Benchmark-Suite und Benchmark-Ablauf konfigurieren.

  • -h|--help
    Hilfe anzeigen

  • -port <Portnummer>
    Port, über den die INUBIT Process Engine erreicht werden kann, z.B. -port 9000

  • -pr <Reportdatei>
    Auszugebende Reportdatei

  • -r <Reportdatei> Pfad und Dateiname einer Reportdatei, die aktualisiert werden soll

    Die Reportdatei muss bereits vorhanden sein. Wenn Sie die Option -r weglassen, wird die Reportdatei <inubit-installdir>/inubit/benchmark/benchmarkReport.xml erstellt.

  • -rt|-runtime <Dauer>
    Maximale Dauer der Benchmark-Suite in Minuten, z.B.: -rt 10

  • -server <IP-Adresse oder Hostname>
    IP-Adresse oder DNS-Name der Maschine, auf der die INUBIT Process Engine läuft, Standard: localhost, z.B.: ‑server 192.168.0.223

  • -t|-thread [<Thread1> <Thread2> <Thread3> …​]
    Anzahl der parallelen Threads oder eine Gruppe von Threads, z.B.: -t [1 5 10]

Benchmark-Suite und Benchmark-Ablauf konfigurieren

Voraussetzungen

Sie haben die Benchmark-Workflows vorbereitet und ausgeführt.

So gehen Sie vor

  1. Öffnen Sie die Datei benchmark.properties im Verzeichnis <inubit-installdir>/inubit/benchmark.

    Diese Datei wird beim ersten Starten des Benchmark-Skripts angelegt.

  2. Passen Sie die folgenden Parameter an:

    • benchmark.config.thread=[1 5 10]
      Anzahl der parallel ausgeführten Workflows für jeden der konfigurierten Durchläufe

    • benchmark.config.runtime=3
      Zeit für Benchmark eines Workflows in einer bestimmten Konfiguration

    • benchmark.config.server=localhost
      Hostname oder IP-Adresse des Systems mit der INUBIT Process Engine

    • benchmark.config.port=8000
      Port für die Kommunikation mit der INUBIT Process Engine

    • benchmark.config.callTimeout=10
      Aufruf-Timeout in Sekunden: Das Skript wird nach Ablauf der angegebenen Zeitspanne mit einer Fehlermeldung abgebrochen, wenn die Benchmark-Suite nicht gestartet werden konnte.

    • benchmark.suite.full
      Suite mit den Namen der HTTP Connectoren der auszuführenden Benchmark-Workflows (Option -b full)

    • benchmark.suite.normal
      Standard-Suite mit den Namen der HTTP Connectoren der auszuführenden Benchmark-Workflows

    • benchmark.suite.fast
      Suite mit den Namen der HTTP Connectoren der auszuführenden Benchmark-Workflows (Option -b fast)

  3. Passen Sie unterhalb der Sektion List of Benchmark sets eine vorhandene Benchmark-Suite an oder erstellen Sie neue Benchmark-Suite nach folgendem Muster:

    • Name der Benchmark-Suite
      benchmark.suite.<Name der Suite>

    • Namen der HTTP Connectoren der auszuführenden Workflows, getrennt mit Komma und Leerzeichen <HTTP Connector1>[, <HTTP Connector2> …​]
      benchmark.suite.suite1=http_conn_twf1

  4. Speichern Sie Ihre Änderungen.

  5. Starten Sie den Benchmarktest mit der geänderten Konfigurationsdatei.

Eigene Benchmark-Workflows erstellen

So gehen Sie vor

  1. Erstellen Sie einen neuen Workflow oder verwenden Sie einen vorhandenen Workflow.

  2. Fügen Sie einen HTTP Connector ein und verbinden Sie ihn mit dem ersten Modul des Workflows.

  3. Erstellen Sie eine neue Benchmark-Suite.
    Siehe Benchmark-Suite und Benchmark-Ablauf konfigurieren.

  4. Tragen Sie den Namen des Workflows als Parameterwert ein.

  5. Speichern Sie die angepasste Konfigurationsdatei unter einem anderen Namen.

  6. Starten Sie das Benchmark-Skript mit der angepassten Konfigurationsdatei und mit einer angepassten Reportdatei.

Eigene Referenzwerte setzen

So gehen Sie vor

  1. Führen Sie eine Benchmark-Suite mit den von Ihnen erstellten Workflows und einer daraus erstellten Benchmark-Suite auf der Referenz-Hardware aus. Siehe

  2. Öffnen Sie die Reportdatei.

  3. Entfernen Sie das Element ServerInfo sowie die TestCase-Elemente unter dem Eintrag ServerTest mit dem Attribut host='benchmarkReferenceServer'.

  4. Kopieren Sie das Element ServerInfo sowie die TestCase-Elemente unter dem Eintrag ServerTest mit dem Attribut host='<Name des Referenz-Servers>'.

  5. Fügen Sie die kopierten Einträge unter dem Eintrag ServerTest mit dem Attribut host='benchmarkReferenceServer' ein.

  6. Speichern Sie die Reportdatei unter einem neuen Namen.

  7. Transferieren Sie die neue Reportdatei und die passende Konfigurationsdatei zu den Systemen, deren INUBIT-Benchmark-Index Sie ermitteln möchten.

  8. Starten Sie das Benchmark-Skript mit der angepassten Konfigurationsdatei und der angepassten Reportdatei.
    Siehe Benchmark-Workflows vorbereiten und ausführen.

  9. Öffnen Sie den Benchmark-Report.
    Siehe Anzeige des Benchmark-Reports.

Der ermittelte Index gibt an, wie Ihre aktuelle Hardware von Ihrer Referenz-Hardware abweicht.

Anzeige des Benchmark-Reports

So gehen Sie vor

  1. Wechseln Sie in das Verzeichnis <inubit-installdir>/inubit/benchmark.

  2. Starten Sie das Benchmark-Skript mit der Option -pr (ausgewählten Report anzeigen).

    • Unix/Linux: benchmark.sh -pr [Reportdatei]

    • Windows: benchmark.bat -pr [Reportdatei]
      Die Reportdatei (Standard: benchmarkReport.xml) müssen Sie nur angeben, wenn Sie beim Starten der Benchmark-Suite einen anderen Pfad und/oder Dateinamen angegeben haben.

  3. Öffnen Sie die Reportdatei im Workbench-Editor.

Press Esc to exit full screen
Modal image placeholder
Press Esc to exit full screen