ThingWorx Flow > 安装和配置 > 配置 ThingWorx Flow > 调整和扩展 ThingWorx Flow 引擎
调整和扩展 ThingWorx Flow 引擎
ThingWorx Flow 引擎服务包含多个配置选项,它们可对 ThingWorx Flow 的性能及其工作流的执行产生极大影响。这些选项可在引擎模块中的 deploymentConfig.json 文件内找到。示例引擎 deploymentConfig.json 文件如下所示:
{
"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"
}
}
}
}
}
如果更改这些配置选项中的任何一个,则必须使用您所用操作系统的本机服务控制工具 (面向 Windows:Servicessc,面向 Red Hat Enterprise Linux:sysctl) 重新启动 ThingWorxFlow 服务。
下表介绍了各种相关设置,并就如何根据您的环境和系统资源对其进行配置提供了相应建议。
配置设置
说明
建议
CHANNEL_MAX_FETCH -
执行吞吐量
类型 - 整数
默认值 - 10
单位 - 消息总数
用于控制引擎服务将要处理的最大工作流执行消息数。每次执行“工作流”服务 (包括手动执行或通过触发器执行的独立工作流) 时,都会通过 ThingWorx Foundation 传输这些消息。通过减小此数字可限制引擎可同时执行的工作流数量。
对于开发环境,建议将此值设置为与系统中的内核数相匹配。
对于生产环境,建议将此值设置为介于内核数的 50% 到 200% 之间,具体取决于同一台计算机上运行的其他服务数量。
ENGINE_SIZE -
工作器内存分配
类型 - 整数
默认值 - 1802
单位 - 兆字节 (10242 字节)
表示引擎工作器进程可为对象分配的最大内存量 (以兆字节为单位)。配置此值时,请考虑以下因素:
工作流中的活动数。
内联表达式或 Node.js 操作的复杂性。
每个操作检索或处理的数据量。
对于开发环境,建议将其保留为默认值。
对于生产环境,建议将 ENGINE_SIZE 的值大约设置为最大可用系统 RAM 数量除以 CHANNEL_MAX_FETCH 所使用的值。
MAX_FLOW_RUN_TIME -
最长执行时间
类型 - 整数
默认值 - 300000
单位 - 毫秒
控制每次运行允许工作流执行的总时间 (以毫秒为单位)。此设置可防止引擎工作器执行工作流时持续时间过长。此值会根据部署和网络环境的不同而有所不同。不过,建议始终将其保持在一个低值,以防因工作器长时间不可用而导致 ThingWorx Flow 的整体性能下降。需要在以下两方面之间进行适当的平衡:提供足够的时间,以允许工作流完成执行;以及保持足够低的值,以使引擎工作器尽快达到可用状态。
对于开发环境,建议将其保留为默认值,或根据需要将其更改为更长的时间段,以便进行调试。
对于生产环境,建议将此值设置为工作流的最长运行时长外加 15%。
SLEEP_BETWEEN_FLOW_EXECUTION -
工作器恢复期
类型 - 整数
默认值 - 3000
单位 - 毫秒
在引擎工作器能够执行工作流之前,插入附加延迟 (以毫秒为单位)。这主要是为了让操作系统从已停止的引擎工作器中回收内存,从而提高不同工作流执行之间不需要共享内存空间的环境的安全性。
对于开发环境和大多数生产环境,建议将此值设置为 0
对于其中包含不能混合出现的敏感信息的多租户环境,建议将其保留为默认值,或根据需要适当增加。
不存在可以确保操作系统正确回收内存的值。
KILL_WORKER_AFTER_RUN -
工作流执行完成后终止引擎工作器
类型 - 布尔型
默认值 - false
每次执行工作流时,引擎服务都会创建一个工作器进程,用于处理实际执行的工作流 (其值最高可达由 CHANNEL_MAX_FETCH 设置的值)。默认情况下,工作器进程保持活动状态,以便为其他执行请求提供服务。此设置会修改上述行为,这将使得在工作流执行完成后,工作器进程会终止。
对于开发环境和大多数生产环境,建议将此值保留为默认值。
对于其中包含不能混合出现的敏感信息的多租户环境,建议将此值设置为 true
AVAILABLE_WORKER_CHECK_TRIES -
工作器可用性重试计数
类型 - 整数
默认值 - 10
单位 - 重试次数
如果所有工作器进程目前正在使用中,但有一个工作流请求处于待处理状态,则引擎服务将继续重试工作器进程,直到达到为 AVAILABLE_WORKER_CHECK_TRIES 配置的次数。如果尝试的重试次数已达到最大值,则引擎将无法处理执行请求。
对于开发环境,建议将此值保留为默认值。
对于生产环境,建议结合 AVAILABLE_WORKER_CHECK_INTERVAL 的值,将此值设置为一个合理的值。
理想情况下,您并不希望总延迟时间超过总请求服务时间的一半左右。
AVAILABLE_WORKER_CHECK_INTERVAL
- 工作器可用性重试延迟时间
类型 - 整数
默认值 - 3000
单位 - 毫秒
用于确定在第一次尝试失败后,再次尝试工作流执行的工作器进程之前,引擎服务需等待的时间。
对于开发环境,建议将此值保留为默认值。
对于生产环境,建议结合 AVAILABLE_WORKER_CHECK_TRIES 的值,将此值设置为一个合理的值。
理想情况下,您并不希望总延迟时间超过总请求服务时间的一半左右。
WORKER_DISMISS_INTERVAL -
工作器进程降速延迟时间
类型 - 整数
默认值 - 1800
单位 - 秒
用于指定引擎服务在开始终止工作器进程之前,等待其他工作的时间。如果将 KILL_WORKER_AFTER_RUN 设置为 true,则忽略此值。
对于本地部署环境,建议将此值保留为默认值。
对于云端部署环境或内存约束环境,建议降低此值,特别在只是偶尔使用此工作流的情况下更应如此。
这对您有帮助吗?