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.
|