|
Configuration Setting
|
Description
|
Recommendations
|
|---|---|---|
|
CHANNEL_MAX_FETCH—
Execution throughput
• Type—Integer
• Default—10
• Units—Total messages
|
Controls the maximum number of workflow execution messages that the engine service will handle. These messages are transmitted by ThingWorx Foundation whenever a Workflow service is executed, including standalone workflows that are manually executed or that use a trigger. Lowering this number limits the number of workflows that the engine can execute simultaneously.
|
For development environments, set this value to match the number of cores on your system.
For production environments, set this value this between 50% and 200% of the number of cores, depending on the number of other services that run on the same machine.
|
|
ENGINE_SIZE—
Worker memory allocation
• Type—Integer
• Default—1802
• Units—Megabytes (10242 bytes)
|
Represents the maximum amount of memory in megabytes that an engine worker process can allocate for objects. While configuring this value, consider the following factors:
• Number of activities in a workflow.
• Complexity of inline expressions or Node.js actions.
• Amount of data retrieved or processed per action.
|
For development environments, leave it at its default value.
For production environments, set the value of ENGINE_SIZE to be approximately the maximum amount of system RAM divided by the value used for CHANNEL_MAX_FETCH.
|
|
MAX_FLOW_RUN_TIME—
Maximum execution time
• Type—Integer
• Default—300000
• Units—Milliseconds
|
Controls the total amount of time in milliseconds that a workflow is allowed to execute per run. This setting prevents an engine worker from executing a workflow for an overly long period of time. This value varies based on deployment and the network environment present; however, it is recommended to keep this value low to keep workers from remaining unavailable for long periods of time, as this can impact the overall performance of ThingWorx Flow. An appropriate balance must be made between providing enough time to allow the workflow to complete execution, and keeping the value low enough so that engine workers are made available as soon as possible.
|
For development environments, leave it at its default value, or change it to a longer time period if needed, for debugging purposes.
For production environments, set the value to the length of your longest running workflow plus 15%.
|
|
SLEEP_BETWEEN_FLOW_EXECUTION—
Worker recovery period
• Type—Integer
• Default—3000
• Units—Milliseconds
|
Inserts an additional delay in milliseconds before an engine worker is able to execute a workflow. This is primarily meant to allow for the operating system to reclaim memory from killed engine workers, allowing for increased security in environments that require not sharing memory space between workflow executions.
|
For development and most production environments, set this value to 0.
For multi-tenant environments that have sensitive information that cannot be intermingled, leave this at the default or increase; as needed.
There is no value that guarantees the operating system has properly recycled the memory.
|
|
KILL_WORKER_AFTER_RUN—
Kill engine workers After workflow execution
• Type—Boolean
• Default—false
|
Whenever a workflow is executed, the engine service creates a worker process that handles the actual execution of the workflow, up to the value set by CHANNEL_MAX_FETCH. By default, the worker processes remain active to service additional execution requests. This setting modifies that behavior such that once the execution of the workflow completes, the worker process terminates.
|
For development and most production environments, leave this value at its default.
For multi-tenant environments that have sensitive information that cannot be intermingled, it is recommended to set this to true.
|
|
AVAILABLE_WORKER_CHECK_TRIES—
Worker availability retry count
• Type—Integer
• Default—10
• Units—Retries
|
If all worker processes are currently in use but a workflow request is pending, the engine service continues to attempt to reserve a worker process as many times as the value configured for AVAILABLE_WORKER_CHECK_TRIES. If the maximum number of retries has been attempted, then the engine fails the execution request.
|
For development purpose, leave this value at its default.
For production environments, set this value at a reasonable value, in conjunction with the value of AVAILABLE_WORKER_CHECK_INTERVAL.
Ideally, you do not want the total delay to exceed approximately half the total request service time.
|
|
AVAILABLE_WORKER_CHECK_INTERVAL
—Worker availability retry delay
• Type—Integer
• Default—3000
• Units—Milliseconds
|
Determines how long the engine service waits before attempting to reserve a worker process for workflow execution, under the assumption that the first attempt failed.
|
For development purpose, keep this value at its default.
For production environments, set this value at a reasonable value, in conjunction with the value of AVAILABLE_WORKER_CHECK_TRIES.
Ideally, you do not want the total delay to exceed approximately half the total request service time.
|
|
WORKER_DISMISS_INTERVAL—
Worker process spin down delay
• Type—Integer
• Default—1800
• Units—Seconds
|
Specifies how long the engine service waits for additional work before it begins terminating the worker processes. This value is ignored if KILL_WORKER_AFTER_RUN is set to true.
|
For on-premise environments, leave this value at its default.
For cloud deployments or memory-constrained environments, you can reduce this value, particularly if workflows are only occasionally used.
|