ThingWorx Flow > Installation et configuration > Configuration de ThingWorx Flow > Réglage et mise à l'échelle du moteur ThingWorx Flow
Réglage et mise à l'échelle du moteur ThingWorx Flow
Le service du moteur ThingWorx Flow contient plusieurs options de configuration qui peuvent avoir un impact considérable sur les performances de ThingWorx Flow et son exécution des processus. Ces options se trouvent dans le fichier deploymentConfig.json du module de moteur. L'exemple de fichier deploymentConfig.json du moteur se présente comme suit :
{
"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"
}
}
}
}
}
Si vous modifiez l'une de ces options de configuration, vous devez redémarrer le service ThingWorxFlow à l'aide des outils de contrôle de services natifs de votre système d'exploitation (Services ou sc pour Windows, sysctl pour Red Hat Enterprise Linux).
La table suivante décrit des paramètres appropriés et fournit des recommandations sur la façon de les configurer en fonction de votre environnement et de vos ressources système :
Paramètre de configuration
Description
Recommandations
CHANNEL_MAX_FETCH :
débit d'exécution
Type : entier
Par défaut : 10
Unités : nombre total de messages
Contrôle le nombre maximal de messages d'exécution de processus que le service de moteur peut traiter. Ces messages sont transmis par ThingWorx Foundation chaque fois qu'un service Processus est exécuté, y compris les processus autonomes qui sont exécutés manuellement ou qui utilisent un déclencheur. En diminuant ce nombre, vous limitez le nombre de processus pouvant être exécutés simultanément par le moteur.
Pour les environnements de développement, définissez cette valeur pour qu'elle corresponde au nombre de coeurs de votre système.
Pour les environnements de production, définissez cette valeur entre 50 % et 200 % du nombre de coeurs, en fonction du nombre d'autres services exécutés sur la même machine.
ENGINE_SIZE :
allocation de mémoire du worker
Type : entier
Par défaut : 1 802
Unités : mégaoctets (10 242 octets)
Il s'agit de la quantité maximale de mémoire (en mégaoctets) qu'un processus de worker du moteur peut allouer à des objets. Lors de la configuration de cette valeur, vous devez tenir considération des facteurs suivants :
Nombre d'activités dans un processus
Complexité des expressions en ligne ou des actions Node.js
Quantité de données récupérées ou traitées par action
Pour les environnements de développement, conservez la valeur par défaut.
Pour les environnements de production, définissez la valeur de ENGINE_SIZE afin qu'elle soit approximativement égale à la quantité maximale de RAM système divisée par la valeur utilisée pour CHANNEL_MAX_FETCH.
MAX_FLOW_RUN_TIME :
temps d'exécution maximum
Type : entier
Par défaut : 300 000
Unités : millisecondes
Contrôle la durée totale (en millisecondes) d'exécution d'un processus. Ce paramètre empêche un worker de moteur d'exécuter un processus pendant une période trop longue. Cette valeur varie selon le déploiement et l'environnement réseau existant. Toutefois, il est recommandé de conserver une valeur basse pour empêcher les workers de rester indisponibles pendant de longues périodes, car cela peut avoir une influence sur les performances globales de ThingWorx Flow. Il convient donc de trouver un juste milieu en accordant suffisamment de temps pour que le processus termine l'exécution et en définissant une valeur la plus basse possible pour garantir une haute disponibilité.
Pour les environnements de développement, conservez la valeur par défaut ou modifiez-la sur une période plus longue si nécessaire, à des fins de débogage.
Pour les environnements de production, définissez une valeur 15 % supérieure à la durée de votre processus d'exécution le plus long.
SLEEP_BETWEEN_FLOW_EXECUTION :
période de récupération du worker
Type : entier
Par défaut : 3 000
Unités : millisecondes
Insère un délai supplémentaire en millisecondes avant qu'un worker de moteur ne puisse exécuter un nouveau processus. Il s'agit principalement de permettre au système d'exploitation de récupérer la mémoire des workers de moteur arrêtés, ce qui permet d'augmenter la sécurité dans les environnements qui n'ont pas besoin de partager l'espace mémoire entre les exécutions de processus.
Pour le développement et la plupart des environnements de production, définissez cette valeur sur 0.
Pour les environnements mutualisés disposant d'informations sensibles qui ne peuvent pas être mélangées, conservez la valeur par défaut ou augmentez-la si nécessaire.
Aucune valeur ne permet de garantir que le système d'exploitation a correctement recyclé la mémoire.
KILL_WORKER_AFTER_RUN :
arrêt des workers de moteur après l'exécution du processus
Type : booléen
Par défaut : false
Chaque fois qu'un processus est exécuté, le service de moteur crée un processus de worker qui gère l'exécution réelle du processus, jusqu'à la valeur définie par CHANNEL_MAX_FETCH. Par défaut, les processus de worker restent actifs pour traiter d'autres requêtes d'exécution. Ce paramètre modifie ce comportement de sorte que le processus du worker s'arrête une fois l'exécution du processus terminée.
Pour le développement et la plupart des environnements de production, conservez la valeur par défaut.
Pour les environnements mutualisés disposant d'informations sensibles qui ne peuvent pas être mélangées, il est recommandé de définir cette valeur sur vrai.
AVAILABLE_WORKER_CHECK_TRIES :
Nombre de tentatives de contrôle de disponibilité du worker
Type : entier
Par défaut : 10
Unités : nouvelles tentatives
Si tous les processus de worker sont actuellement en cours d'utilisation mais qu'une requête de processus est en attente, le service de moteur continue de tenter de réserver un processus de worker aussi souvent que la valeur configurée pour AVAILABLE_WORKER_CHECK_TRIES. Si le nombre maximal de tentatives est atteint, la requête d'exécution échouera.
A des fins de développement, conservez la valeur par défaut.
Pour les environnements de production, définissez une valeur raisonnable qui tient compte de la valeur de AVAILABLE_WORKER_CHECK_INTERVAL.
Idéalement, le délai total ne doit pas dépasser environ la moitié de la durée totale du service de requête.
AVAILABLE_WORKER_CHECK_INTERVAL
 : délai de nouvelle tentative de contrôle de disponibilité du worker
Type : entier
Par défaut : 3 000
Unités : millisecondes
Détermine le délai d'attente du service du moteur avant une nouvelle tentative de réservation d'un processus de worker pour l'exécution du processus, en supposant que la première tentative a échoué.
A des fins de développement, conservez la valeur par défaut.
Pour les environnements de production, définissez une valeur raisonnable qui tient compte de la valeur de AVAILABLE_WORKER_CHECK_TRIES.
Idéalement, le délai total ne doit pas dépasser environ la moitié de la durée totale du service de requête.
WORKER_DISMISS_INTERVAL :
délai d'interruption des processus de worker
Type : entier
Par défaut : 1 800
Unités : secondes
Spécifie combien de temps le service de moteur attend une tâche supplémentaire avant de lancer l'arrêt des processus de worker. Cette valeur est ignorée si KILL_WORKER_AFTER_RUN est défini sur vrai.
Pour les environnements sur site, conservez la valeur par défaut.
Pour les déploiements sur le Cloud ou dans des environnements à mémoire réduite, vous pouvez réduire cette valeur, notamment si les processus ne sont utilisés que de manière occasionnelle.
Est-ce que cela a été utile ?