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 sulla relativa esecuzione di workflow. Queste opzioni sono disponibili nel file deploymentConfig.json nel modulo motore. Se una di queste opzioni di configurazione viene modificata, è necessario riavviare il servizio ThingWorxFlow utilizzando gli strumenti nativi di controllo del servizio per il sistema operativo in uso (servizi o sc per Windows, sysctl per Red Hat). Nelle sezioni che seguono vengono descritte tutte le impostazioni pertinenti e vengono forniti suggerimenti su come configurarle in base all'ambiente e alle risorse di sistema.
Throughput di esecuzione (CHANNEL_MAX_FETCH)
• Tipo - Integer
• Default - 10
• Unità - Totale messaggi
Controlla il numero massimo di messaggi di esecuzione del workflow che il servizio del motore gestisce. Questi messaggi vengono trasmessi da ThingWorx Foundation ogni volta che viene eseguito un servizio di Workflow, compresi i workflow indipendenti che vengono eseguiti manualmente o che utilizzano un trigger. Riducendo questo numero, si limiterà il numero di workflow che il motore può eseguire simultaneamente.
Gli ambienti di sviluppo devono configurarlo in modo che corrisponda al numero di core del sistema. I sistemi di produzione devono configurare 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.
Allocazione della memoria del worker (ENGINE_SIZE)
• Tipo - Integer
• Default - 1802
• Unità - Megabyte (10242 byte)
Rappresenta la quantità massima di memoria espressa in megabyte che un processo del worker di motore può allocare per gli oggetti. I fattori che devono essere presi in considerazione per la configurazione di questo valore includono:
• Numero di attività in un workflow
• Complessità delle espressioni in linea o delle azioni Node.js
• Quantità di dati recuperati o elaborati per azione
Consigli di distribuzione - Si consiglia di lasciare l'impostazione di default negli ambienti di sviluppo. Per gli ambienti di produzione, è necessario configurare ENGINE_SIZE in modo che corrisponda approssimativamente alla quantità massima di RAM di sistema divisa per l'impostazione utilizzata per CHANNEL_MAX_FETCH.
Tempo di esecuzione massimo (MAX_FLOW_RUN_TIME)
• Tipo - Integer
• Default - 300000
• Unità - Millisecondi
Controlla la quantità totale di tempo in millisecondi in cui è possibile eseguire un workflow per esecuzione. Questa impostazione impedisce a un worker di 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 questo valore basso per evitare che i worker rimangano non disponibili per lunghi periodi di tempo, poiché ciò può provocare una riduzione delle prestazioni complessive di Flow. È necessario creare l'equilibrio giusto 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.
Consigli di distribuzione - Si consiglia di lasciare l'impostazione di default per gli ambienti di sviluppo o valori superiori, se necessario ai fini del debug. Per gli ambienti di produzione, si consiglia di impostare il valore sulla lunghezza del workflow in esecuzione più lungo, cui si aggiunge il 15%.
Periodo di recupero del worker (SLEEP_BETWEEN_FLOW_EXECUTION)
• Tipo - Integer
• Default - 3000
• Unità - Millisecondi
Inserisce un ritardo aggiuntivo in millisecondi prima che un worker di 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.
Consigli di distribuzione - Per gli ambienti di sviluppo e per la maggior parte degli ambienti di produzione, si consiglia di impostare questo valore su 0. Per gli ambienti con più tenant che conservano informazioni sensibili che non possono coesistere con altri dati, si consiglia di lasciare il valore di default o di aumentare in base alle esigenze. Nessun valore garantisce che il sistema operativo abbia riciclato correttamente la memoria.
Termine dei worker di motore dopo l'esecuzione del flusso (KILL_WORKER_AFTER_RUN)
• Tipo - Booleano
• Default - false
Ogni volta che si esegue un workflow, il servizio del motore crea un processo worker che gestisce l'esecuzione effettiva del workflow (fino al valore impostato da CHANNEL_MAX_FETCH). Per default, i processi del worker 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.
Consigli di distribuzione - Per gli ambienti di sviluppo e per la maggior parte degli ambienti di produzione, si consiglia di lasciare questo valore sull'impostazione 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.
Numero di tentativi di disponibilità del worker (AVAILABLE_WORKER_CHECK_TRIES)
• Tipo - Integer
• Default - 10
• Unità - Nuovi tentativi
Se tutti i processi del worker sono attualmente in uso ma è in sospeso una richiesta di workflow, il servizio del motore continua a provare a riservare un processo del worker tutte le volte indicate nella configurazione. Se viene raggiunto il numero massimo di tentativi, il motore non riuscirà a eseguire la richiesta di esecuzione.
Consigli di distribuzione - Ai fini dello sviluppo, è sufficiente mantenere il valore di default. Per gli ambienti di produzione, si consiglia di impostare un valore ragionevole, compatibilmente con l'impostazione di AVAILABLE_WORKER_CHECK_INTERVAL, per evitare che il ritardo complessivo superi approssimativamente la metà del tempo totale del servizio di richiesta.
Ritardo dei tentativi di disponibilità del worker (AVAILABLE_WORKER_CHECK_INTERVAL)
• Tipo - Integer
• Default - 3000
• Unità - Millisecondi
Determina il tempo di attesa del servizio del motore prima di tentare di riservare un processo worker per l'esecuzione del workflow, supponendo che il primo tentativo non sia riuscito.
Consigli di distribuzione - Ai fini dello sviluppo, è sufficiente mantenere il valore di default. Per gli ambienti di produzione, si consiglia di impostare un valore ragionevole, compatibilmente con l'impostazione di AVAILABLE_WORKER_CHECK_TRIES, per evitare che il ritardo complessivo superi approssimativamente la metà del tempo totale del servizio di richiesta.
Ritardo del processo del worker (WORKER_DISMISS_INTERVAL)
• 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 non ha alcun significato se KILL_WORKER_AFTER_RUN è impostato su true.
Consigli di distribuzione - Negli ambienti locali è in genere sufficiente lasciare l'impostazione di default di questo valore. Per le distribuzioni cloud o vincolati alla memoria, potrebbe essere opportuno ridurre questo valore, in particolare se i workflow vengono utilizzati solo occasionalmente.
Configurazione del motore di esempio
Il file deploymentConfig.json è 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
"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"
}
}
}
}
}