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