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