ThingWorx Flow > Installation and Configuration > Configuring ThingWorx Flow > Tuning and Scaling the ThingWorx Flow Engine
Tuning and Scaling the ThingWorx Flow Engine
The ThingWorx Flow Engine service contains a number of configuration options that can have an outsized effect on the performance of ThingWorx Flow and its execution of workflows. These options can be found in the deploymentConfig.json file in the engine module. The sample engine deploymentConfig.json file is as follows:
{
"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"
}
}
}
}
}
If you change any of these configuration options, then you must restart the ThingWorxFlow service using the native service control tools for your operating system (Services or sc for Windows, sysctl for Red Hat Enterprise Linux).
The following table describes the relevant settings and provides recommendations on how to configure them based on your environment and system resources:
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.
Was this helpful?