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"
}
}
}
}
}
Если изменить какую-либо из этих опций конфигурации, необходимо перезапустить сервис ThingWorxFlow, используя собственные инструменты управления сервисами для операционной системы (Services или sc для Windows, sysctl для Red Hat Enterprise Linux).
В следующей таблице приведено описание каждой из соответствующих настроек и приведены рекомендации по их конфигурированию на основе ресурсов среды и системы.
Настройка конфигурации
Описание
Рекомендации
CHANNEL_MAX_FETCH-
Производительность выполнения
Тип: целочисленный
По умолчанию: 10
Единицы измерения: общее количество сообщений
Управляет максимальным числом сообщений о выполнении рабочего процесса, которые будет обрабатывать сервис обработчика. ThingWorx Foundation передает эти сообщения при каждом выполнении сервиса Рабочий процесс, включая автономные рабочие процессы, выполняемые вручную или использующие триггер. Уменьшение этого числа ограничивает число рабочих процессов, которые обработчик может выполнять одновременно.
Для среды разработки задайте это значение в соответствии с количеством ядер в вашей системе.
Для производственных сред конфигурируйте это значение в диапазоне от 50 до 200 % от числа ядер в зависимости от числа других сервисов, которые выполняются на том же компьютере.
ENGINE_SIZE-
Назначение памяти обработчика
Тип: целочисленный
По умолчанию: 1802
Единицы измерения: мегабайты (1024 КБ)
Представляет максимальный объем памяти в мегабайтах, которую процесс обработчика может выделить для объектов. При конфигурировании этого значения учитывайте следующие факторы.
Количество задач в рабочем процессе.
Сложность встроенных выражений или действий Node.js.
Объем данных, загружаемых или обрабатываемых в действии.
В средах разработки оставьте значение по умолчанию.
В производственных средах задайте для параметра значение ENGINE_SIZE, приблизительно равное максимальному объему системной памяти, деленному на значение, используемое для CHANNEL_MAX_FETCH.
MAX_FLOW_RUN_TIME-
Максимальное время выполнения
Тип: целочисленный
По умолчанию: 300000
Единицы измерения: миллисекунды
Определяет общее количество времени в миллисекундах, в течение которого рабочий процесс может выполняться при каждом запуске. Эта настройка не позволяет обработчику выполнять рабочий процесс в течение более длительного периода времени. Это значение должно изменяться в зависимости от текущего развертывания и сетевой среды. Однако рекомендуется оставлять это значение низким, чтобы нельзя было использовать обработчики длительное время, поскольку это может привести к снижению общей производительности ThingWorx Flow. Необходимо поддерживать разумный баланс между предоставлением достаточного времени для выполнения рабочего процесса и достаточно низким значением, чтобы обработчики становились доступными как можно раньше.
Для сред разработки оставьте значение по умолчанию или измените его на более длительный период времени, если это необходимо в целях отладки.
Для производственных сред задавайте значение продолжительности самого длинного рабочего процесса плюс 15 %.
SLEEP_BETWEEN_FLOW_EXECUTION-
Период восстановления обработчика
Тип: целочисленный
По умолчанию: 3000
Единицы измерения: миллисекунды
Вставка дополнительной задержки в миллисекундах, перед тем как обработчик сможет выполнить рабочий процесс. Эта опция в основном предназначена для того, чтобы операционная система освободила память от закрытых обработчиков, что позволяет повысить безопасность в средах, требующих не разрешать общий доступ к объему памяти между выполнениями рабочего процесса.
Для разработки и большинства производственных сред задавайте для этого параметра значение 0.
Для многопользовательских сред с конфиденциальной информацией, которая не должна перемешиваться, оставляйте значение по умолчанию или увеличивайте его по мере необходимости.
Нет значения, гарантирующего, что операционная система правильно будет повторно использовать память.
KILL_WORKER_AFTER_RUN-
Закрыть обработчики модуля после выполнения рабочего процесса
Тип: логический
По умолчанию: ложь
При каждом выполнении рабочего процесса сервис обработчика создает процесс обработчика, который обрабатывает фактическое выполнение рабочего процесса (до значения, заданного опцией 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.
Для локальных сред оставляйте значение по умолчанию.
Для облачных развертываний или ограниченных по памяти сред можно уменьшить это значение, особенно если рабочие процессы используются только время от времени.
Было ли это полезно?