ThingWorx Flow > Installazione e configurazione > Configurazione di ThingWorx Flow > Ottimizzazione e scalabilità del motore di ThingWorx Flow
Ottimizzazione e scalabilità del motore di ThingWorx Flow
Il servizio del motore di ThingWorx Flow include una serie di opzioni di configurazione che possono avere un effetto significativo sulle prestazioni di ThingWorx Flow e sull'esecuzione dei workflow. Queste opzioni sono disponibili nel file deploymentConfig.json nel modulo motore. Il file deploymentConfig.json del motore di esempio è il seguente:
{
"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"
}
}
}
}
}
Se si modifica una di queste opzioni di configurazione, è necessario riavviare il servizio ThingWorxFlow utilizzando gli strumenti nativi di controllo del servizio per il sistema operativo (Services o sc per Windows, sysctl per Red Hat Linux aziendali).
Nella tabella seguente vengono descritte tutte le impostazioni pertinenti e vengono forniti suggerimenti su come configurarle in base all'ambiente e alle risorse di sistema.
Impostazione della configurazione
Descrizione
Suggerimenti
CHANNEL_MAX_FETCH
Throughput di esecuzione
Tipo - Integer
Default - 10
Unità - Totale messaggi
Controlla il numero massimo di messaggi di esecuzione del workflow che il servizio del motore può gestire. Questi messaggi vengono trasmessi da ThingWorx Foundation ogni volta che viene eseguito un servizio Workflow, compresi i workflow indipendenti che vengono eseguiti manualmente o che utilizzano un trigger. Riducendo questo numero, si limita il numero di workflow che il motore può eseguire simultaneamente.
Per gli ambienti di sviluppo, impostare questo valore in modo che corrisponda al numero di core del sistema.
Per gli ambienti di produzione, impostare questo valore in modo che rientri tra il 50% e il 200% del numero di core, a seconda del numero di altri servizi che vengono eseguiti sullo stesso computer.
ENGINE_SIZE
Allocazione della memoria del worker
Tipo - Integer
Default - 1802
Unità - Megabyte (10242 byte)
Rappresenta la quantità massima di memoria espressa in megabyte che un processo di lavoro del motore può allocare per gli oggetti. Durante la configurazione di questo valore, considerare i fattori riportati di seguito.
Numero di attività in un workflow.
Complessità delle espressioni in linea o delle azioni Node.js.
Quantità di dati recuperati o elaborati per azione.
Per gli ambienti di sviluppo, lasciare il valore di default.
Per gli ambienti di produzione, impostare il valore di ENGINE_SIZE in modo che corrisponda approssimativamente alla quantità massima di RAM di sistema divisa per il valore utilizzato per CHANNEL_MAX_FETCH.
MAX_FLOW_RUN_TIME
Tempo di esecuzione massimo
Tipo - Integer
Default - 300000
Unità - Millisecondi
Controlla la quantità totale di tempo in millisecondi in cui è possibile eseguire un workflow per ogni esecuzione. Questa impostazione impedisce a un worker del motore di eseguire un workflow per un periodo di tempo troppo lungo. Questo valore varia in base alla distribuzione e all'ambiente di rete presente. Tuttavia, si consiglia di mantenere basso questo valore per evitare che i worker rimangano non disponibili per lunghi periodi di tempo, poiché ciò può provocare una riduzione delle prestazioni complessive di ThingWorx Flow. È necessario ottenere il giusto equilibrio tra il tempo necessario al workflow per completare l'esecuzione e l'impostazione di questo valore, sufficientemente bassa da rendere i worker di motore disponibili il più presto possibile.
Per gli ambienti di sviluppo, lasciare il valore di default o, se necessario, modificarlo in un periodo di tempo più lungo ai fini del debug.
Per gli ambienti di produzione, impostare il valore sulla lunghezza del workflow in esecuzione più lungo, cui si aggiunge il 15%.
SLEEP_BETWEEN_FLOW_EXECUTION
Periodo di recupero del worker
Tipo - Integer
Default - 3000
Unità - Millisecondi
Inserisce un ritardo aggiuntivo in millisecondi prima che un worker del motore riesca a eseguire un workflow. L'intento è principalmente quello di permettere al sistema operativo di recuperare memoria dai worker di motore terminati, garantendo maggiore sicurezza negli ambienti che non richiedono la condivisione dello spazio di memoria tra le esecuzioni dei workflow.
Per gli ambienti di sviluppo e la maggior parte degli ambienti di produzione, impostare questo valore su 0.
Per gli ambienti con più tenant che conservano informazioni sensibili che non possono coesistere con altri dati, lasciare il valore di default o aumentarlo in base alle esigenze.
Nessun valore garantisce che il sistema operativo abbia riciclato correttamente la memoria.
KILL_WORKER_AFTER_RUN
Terminare i worker di motore dopo l'esecuzione del workflow
Tipo - Booleano
Default - false
Ogni volta che si esegue un workflow, il servizio del motore crea un processo di lavoro che gestisce l'esecuzione effettiva del workflow, fino al valore impostato da CHANNEL_MAX_FETCH. Per default, i processi di lavoro rimangono attivi per gestire le richieste di esecuzione aggiuntive. Questa impostazione consente di modificare tale comportamento in modo che, una volta completata l'esecuzione del workflow, il processo di lavoro venga terminato.
Per gli ambienti di sviluppo e la maggior parte degli ambienti di produzione, lasciare il valore di default.
Per gli ambienti con più tenant che conservano informazioni sensibili che non possono coesistere con altri dati, si consiglia di impostare questo valore su true.
AVAILABLE_WORKER_CHECK_TRIES
Numero di tentativi di disponibilità del worker
Tipo - Integer
Default - 10
Unità - Nuovi tentativi
Se tutti i processi di lavoro sono attualmente in uso ma è in sospeso una richiesta di workflow, il servizio del motore continua a provare a riservare un processo di lavoro tutte le volte indicate nel valore configurato per AVAILABLE_WORKER_CHECK_TRIES. Se viene raggiunto il numero massimo di tentativi, il motore non riesce a eseguire la richiesta di esecuzione.
A scopo di sviluppo, lasciare il valore di default.
Per gli ambienti di produzione, specificare un valore ragionevole, insieme al valore di AVAILABLE_WORKER_CHECK_INTERVAL.
Il ritardo complessivo non dovrebbe superare la metà del tempo totale del servizio di richiesta.
AVAILABLE_WORKER_CHECK_INTERVAL
- Ritardo dei tentativi di disponibilità del worker
Tipo - Integer
Default - 3000
Unità - Millisecondi
Determina il tempo di attesa del servizio del motore prima di tentare di riservare un processo di lavoro per l'esecuzione del workflow, supponendo che il primo tentativo non sia riuscito.
A scopo di sviluppo, lasciare il valore di default.
Per gli ambienti di produzione, specificare un valore ragionevole, insieme al valore di AVAILABLE_WORKER_CHECK_TRIES.
Il ritardo complessivo non dovrebbe superare la metà del tempo totale del servizio di richiesta.
WORKER_DISMISS_INTERVAL
Ritardo di rotazione del processo di lavoro
Tipo - Integer
Default - 1800
Unità - Secondi
Specifica per quanto tempo il servizio motore attende lavoro aggiuntivo prima di iniziare la chiusura dei processi di lavoro. Questo valore viene ignorato se KILL_WORKER_AFTER_RUN è impostato su true.
Per gli ambienti locali, lasciare il valore di default.
Per le distribuzioni cloud o gli ambienti vincolati alla memoria, è possibile ridurre questo valore, in particolare se i workflow vengono utilizzati solo occasionalmente.
È stato utile?