ThingWorx Flow > Installation und Konfiguration > ThingWorx Flow konfigurieren > ThingWorx Flow Engine optimieren und skalieren
ThingWorx Flow Engine optimieren und skalieren
Der ThingWorx Flow Engine-Dienst enthält eine Reihe von Konfigurationsoptionen, die einen großen Einfluss auf die Leistung von ThingWorx Flow und die Ausführung von Workflows haben können. Diese Optionen finden Sie in der Datei deploymentConfig.json im Engine-Modul. Die Engine-Beispieldatei deploymentConfig.json sieht folgendermaßen aus:
{
"MAX_FLOW_RUN_TIME": 180000, // Only allows a workflow to run for up to 3 minutes.
"EXCHANGE_STATUS_CHECK_INTERVAL": 120000, // Checks if it can communicate with the Exchange service every 2 minutes.
"REFRESH_ON_INTERVAL_MINUTES": 60,
"ENGINE_PORT": 2006, // The port Engine will reserve for health check purposes
"ENGINE_HOST": "localhost", // The hostname Engine will reserve the port against
"SLEEP_BETWEEN_FLOW_EXECUTION": 3000, // Waits 3 seconds before a worker can execute the next workflow
"ENGINE_DATA_PATH": "C:/ThingWorxOrchestration/modules/cache", // Location where files are stored during workflow execution. Files are deleted once the workflow execution is complete.
"EXCHANGE": { // The host and port for the Exchange service that this Engine should communicate with
"HOST": "localhost",
"PORT": "7822"
},
"logLevel":"error", // valid levels are 'trace', 'debug', 'info', 'warn', and 'error'; default is 'error'
"QUEUE": {
"MAX_SOCKET": 100,
"QUEUE_CONSUMPTION_UNIT": {
"256": 1
},
"DEFAULT_FLOW_QUEUE": "256",
"ACTIVE_ADAPTER_DEFAULT": "amqp",
"ACTIVE_ADAPTER_FLOW": "amqp",
"ACTIVE_ADAPTER_STOP": "amqp",
"ACTIVE_ADAPTER_WEBHOOK": "amqp",
"ADAPTERS": {
"AMQP": {
"CONFIG": { // The host and port for the RabbitMQ server
"port": "5672",
"protocol": "amqp",
"host": "localhost",
"vhost": "orchestration",
"CHANNEL_MAX_FETCH": "5" // The maximum number of messages this Engine will fetch from the queue
},
"FLOW_QUEUE": {
"QUEUE_NAMES": {
"256m": "256mb"
},
"QUEUE_NAME": "256mb"
}
}
}
}
}
Wenn Sie eine dieser Konfigurationsoptionen ändern, müssen Sie den ThingWorxFlow Dienst mit den nativen Dienststeuerungstools für Ihr Betriebssystem (Services oder sc für Windows, sysctl für Red Hat Enterprise Linux) neu starten.
In der folgenden Tabelle werden die relevanten Einstellungen beschrieben und Empfehlungen zur Konfiguration dieser Einstellungen auf Grundlage Ihrer Umgebung und Systemressourcen bereitgestellt.
Konfigurationseinstellung
Beschreibung
Empfehlungen
CHANNEL_MAX_FETCH
Ausführungsdurchsatz
Typ – Ganzzahl
Standardwert – 10
Einheiten – Gesamtanzahl Meldungen
Steuert die maximale Anzahl von Workflow-Ausführungsmeldungen, die vom Engine-Dienst verarbeitet werden. Diese Meldungen werden immer dann von ThingWorx Foundation übertragen, wenn ein Workflow-Dienst ausgeführt wird; dies schließt auch unabhängige Workflows ein, die manuell ausgeführt werden oder einen Trigger verwenden. Durch das Verringern dieser Zahl wird die Anzahl der Workflows begrenzt, die die Engine gleichzeitig ausführen kann.
Legen Sie für Entwicklungsumgebungen diesen Wert so fest, dass er mit der Anzahl der Kerne auf Ihrem System übereinstimmt.
Legen Sie diesen Wert für Produktionsumgebungen auf 50 bis 200 % der Anzahl der Kerne fest, abhängig von der Anzahl anderer Dienste, die auf demselben Rechner ausgeführt werden.
ENGINE_SIZE
Worker-Arbeitsspeicherzuordnung
Typ – Ganzzahl
Standardwert – 1802
Einheiten – Megabyte (10242 Byte)
Stellt die maximale Menge an Arbeitsspeicher in MB dar, die ein Worker-Prozess der Engine für Objekte zuordnen kann. Berücksichtigen Sie beim Konfigurieren dieses Werts die folgenden Faktoren:
Anzahl der Aktivitäten in einem Workflow
Komplexität von Inline-Ausdrücken oder Node.js-Aktionen
Menge der pro Aktion abgerufenen oder verarbeiteten Daten
Behalten Sie für Entwicklungsumgebungen den Standardwert bei.
Legen Sie für Produktionsumgebungen den Wert ENGINE_SIZE auf ungefähr den Höchstwert des System-RAMs dividiert durch den für CHANNEL_MAX_FETCH verwendeten Wert fest.
MAX_FLOW_RUN_TIME
Maximale Ausführungszeit
Typ – Ganzzahl
Standardwert – 300000
Einheiten – Millisekunden
Steuert den Gesamtzeitraum in Millisekunden, die ein Workflow pro Rechenlauf ausgeführt werden darf. Diese Einstellung verhindert, dass ein Engine-Worker einen Workflow über einen übermäßig langen Zeitraum ausführt. Dieser Wert variiert basierend auf der Bereitstellung und der vorhandenen Netzwerkumgebung. Es wird jedoch empfohlen, diesen Wert niedrig zu halten. Dadurch soll verhindert werden, dass die Worker über einen längeren Zeitraum nicht verfügbar sind. Dies kann nämlich zu einer Verschlechterung der Gesamtleistung von ThingWorx Flow führen. Es muss ausreichend Zeit für die vollständige Ausführung des Workflows bereitgestellt, aber gleichzeitig der Wert so niedrig gehalten werden, dass die Engine-Worker so schnell wie möglich wieder verfügbar sind.
Behalten Sie für Entwicklungsumgebungen den Standardwert bei, oder ändern Sie ihn bei Bedarf zu Debugging-Zwecken in einen längeren Zeitraum.
Legen Sie für Produktionsumgebungen den Wert auf die Länge des am längsten ausgeführten Workflows plus 15 % fest.
SLEEP_BETWEEN_FLOW_EXECUTION
Worker-Wiederherstellungszeitraum
Typ – Ganzzahl
Standardwert – 3000
Einheiten – Millisekunden
Fügt eine zusätzliche Verzögerung in Millisekunden ein, bevor ein Engine-Worker einen Workflow ausführen kann. Damit soll in erster Linie sichergestellt werden, dass das Betriebssystem Speicher von beendeten Engine-Workern zurückfordern kann. Dadurch wird die Sicherheit in Umgebungen erhöht, in denen der Speicherplatz nicht von mehreren Workflow-Ausführungen geteilt werden darf.
Für die Entwicklungsumgebung und die meisten Produktionsumgebungen sollten Sie diesen Wert auf 0 festlegen.
Behalten Sie für Umgebungen mit mehreren Mandanten, die vertrauliche Informationen enthalten, die nicht vermischt werden dürfen, den Standardwert bei, oder erhöhen Sie ihn nach Bedarf.
Es gibt keinen Wert, der sicherstellt, dass das Betriebssystem den Speicher ordnungsgemäß recycelt hat.
KILL_WORKER_AFTER_RUN
Beendet Engine-Worker nach der Workflow-Ausführung
Typ – boolescher Wert
Standardwert – false
Wenn ein Workflow ausgeführt wird, erstellt der Engine-Dienst einen Worker-Prozess, der die tatsächliche Ausführung des Workflows verarbeitet (bis zu dem von CHANNEL_MAX_FETCH festgelegten Wert). Standardmäßig bleiben die Worker-Prozesse aktiv, um zusätzliche Ausführungsanforderungen zu verarbeiten. Diese Einstellung ändert dieses Verhalten so, dass der Worker-Prozess beendet wird, sobald die Ausführung des Workflows abgeschlossen ist.
Behalten Sie den Standardwert für die Entwicklungsumgebung und die meisten Produktionsumgebungen bei.
Für Umgebungen mit mehreren Mandanten, die vertrauliche Informationen enthalten, die nicht vermischt werden können, wird empfohlen, diesen Wert auf wahr festzulegen.
AVAILABLE_WORKER_CHECK_TRIES
Anzahl der Wiederholungen für Worker-Verfügbarkeit
Typ – Ganzzahl
Standardwert – 10
Einheiten – Wiederholungen
Wenn alle Worker-Prozesse aktuell verwendet werden, aber eine Workflow-Anforderung aussteht, versucht der Engine-Dienst weiterhin, einen Worker-Prozess zu reservieren, und zwar so oft wie in der Konfiguration für AVAILABLE_WORKER_CHECK_TRIES festgelegt. Wenn die maximale Anzahl von Wiederholungen durchgeführt wurde, schlägt die Ausführungsanforderung fehl.
Behalten Sie für Entwicklungszwecke den Standardwert bei.
Legen Sie für Produktionsumgebungen einen angemessenen Wert fest, zusammen mit dem Wert AVAILABLE_WORKER_CHECK_INTERVAL.
Idealerweise sollte die Gesamtverzögerung nicht größer als ungefähr die Hälfte der gesamten Anforderungsdienstzeit sein.
AVAILABLE_WORKER_CHECK_INTERVAL
– Wiederholungsverzögerung für Worker-Verfügbarkeit
Typ – Ganzzahl
Standardwert – 3000
Einheiten – Millisekunden
Bestimmt, wie lange der Engine-Dienst wartet, bevor er versucht, einen Worker-Prozess für die Workflow-Ausführung zu reservieren, unter der Annahme, dass der erste Versuch fehlgeschlagen ist.
Behalten Sie für Entwicklungszwecke den Standardwert bei.
Legen Sie für Produktionsumgebungen einen angemessenen Wert fest, zusammen mit dem Wert AVAILABLE_WORKER_CHECK_TRIES.
Idealerweise sollte die Gesamtverzögerung nicht größer als ungefähr die Hälfte der gesamten Anforderungsdienstzeit sein.
WORKER_DISMISS_INTERVAL
Verzögerung bei Beendung der Worker-Prozesse
Typ – Ganzzahl
Standardwert – 1800
Einheiten – Sekunden
Gibt an, wie lange der Engine-Dienst auf zusätzliche Arbeit wartet, bevor er mit dem Beenden der Worker-Prozesse beginnt. Dieser Wert wird ignoriert, wenn KILL_WORKER_AFTER_RUN auf true festgelegt ist.
Behalten Sie für lokale Umgebungen den Standardwert bei.
In Cloud-Bereitstellungen oder Umgebungen mit eingeschränktem Arbeitsspeicher können Sie diesen Wert reduzieren, insbesondere dann, wenn Workflows nur gelegentlich verwendet werden.
War dies hilfreich?