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. Si l'une de ces options de configuration est modifiée, le service ThingWorxFlow doit être redémarré à 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). Les sections suivantes décrivent chacun des paramètres appropriés et fournissent des recommandations sur la façon de les configurer en fonction de votre environnement et de vos ressources système.
Débit d'exécution (CHANNEL_MAX_FETCH)
• 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 de 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.
Lors de la configuration, les environnements de développement doivent prendre en compte le nombre de coeurs de votre système. Les systèmes de production doivent configurer 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.
Allocation de mémoire du worker (ENGINE_SIZE)
• 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. Les facteurs suivants sont notamment à prendre en compte pour la configuration de cette valeur :
• 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
Recommandations de déploiement : il est recommandé de conserver la valeur par défaut dans les environnements de développement. Pour les environnements de production, vous devez définir pour ENGINE_SIZE une valeur qui correspond environ à la quantité maximale de mémoire RAM système divisée par le paramètre utilisé pour CHANNEL_MAX_FETCH.
Temps d'exécution maximum (MAX_FLOW_RUN_TIME)
• 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 entraîner une dégradation des 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é.
Recommandations de déploiement : il est recommandé de conserver la valeur par défaut dans les environnements de développement ou des valeurs supérieures si cela est nécessaire à des fins de débogage. Pour les environnements de production, il est recommandé de définir une valeur 15 % supérieure à la durée de votre processus d'exécution le plus long.
Période de récupération du worker (SLEEP_BETWEEN_FLOW_EXECUTION)
• 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.
Recommandations de déploiement : pour les environnements de développement et la plupart des environnements de production, il est recommandé de définir cette valeur sur 0. Pour les environnements mutualisés disposant d'informations sensibles qui ne peuvent pas être mélangées, il est recommandé de conserver la valeur par défaut ou de l'augmenter si nécessaire. Aucune valeur ne permet de garantir que le système d'exploitation a correctement recyclé la mémoire.
Arrêt des workers de moteur après l'exécution de flux (KILL_WORKER_AFTER_RUN)
• 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.
Recommandations de déploiement : pour les environnements de développement et la plupart des environnements de production, il est recommandé de conserver 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".
Nombre de tentatives de contrôle de disponibilité du worker (AVAILABLE_WORKER_CHECK_TRIES)
• 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 selon le paramètre défini. Si le nombre maximal de tentatives est atteint, la requête d'exécution échouera.
Recommandations de déploiement : pour les environnements de développement, conserver la valeur par défaut est suffisant. Pour les environnements de production, il est recommandé de définir une valeur raisonnable qui tient compte du paramètre AVAILABLE_WORKER_CHECK_INTERVAL. Le délai total ne doit ainsi pas dépasser environ la moitié de la durée totale du service de requête.
Délai de nouvelle tentative de contrôle de disponibilité du worker (AVAILABLE_WORKER_CHECK_INTERVAL)
• 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é.
Recommandations de déploiement : pour les environnements de développement, conserver la valeur par défaut est suffisant. Pour les environnements de production, il est recommandé de définir une valeur raisonnable qui tient compte du paramètre AVAILABLE_WORKER_CHECK_TRIES. Le délai total ne doit ainsi pas dépasser environ la moitié de la durée totale du service de requête.
Délai d'interruption des processus de worker (WORKER_DISMISS_INTERVAL)
• 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 n'a aucun impact si KILL_WORKER_AFTER_RUN est défini sur "vrai".
Recommandations de déploiement : dans les environnements sur site, conserver la valeur par défaut est généralement suffisant. Pour les déploiements sur le Cloud ou dans des environnements à mémoire réduite, il peut être souhaitable de réduire cette valeur, notamment si les processus ne sont utilisés que de manière occasionnelle.
Exemple de configuration du 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
"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"
}
}
}
}
}