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의 경우 Services 또는 sc, Red Hat Enterprise Linux의 경우 sysctl)를 사용하여 ThingWorxFlow 서비스를 다시 시작해야 합니다.
다음 표에서는 관련 설정에 대해 설명하고 사용자의 환경 및 시스템 리소스에 따라 이러한 설정을 구성하는 방법에 대한 권장 사항을 제공합니다.
구성 설정
설명
권장 사항
CHANNEL_MAX_FETCH -
실행 처리량
유형 - 정수
기본값 - 10
단위 - 총 메시지
엔진 서비스가 처리할 최대 워크플로 실행 메시지 수를 제어합니다. 이러한 메시지는 수동으로 실행되거나 트리거를 사용하는 독립형 워크플로를 포함하여 워크플로 서비스가 실행될 때마다 ThingWorx Foundation에 의해 전송됩니다. 이 숫자를 낮추면 엔진이 동시에 실행할 수 있는 워크플로 수가 제한됩니다.
개발 환경에서는 이 값을 시스템의 코어 수와 일치하도록 설정합니다.
생산 환경에서는 동일한 시스템에서 실행되는 다른 서비스의 수에 따라 이 값을 코어 수의 50%와 200% 사이로 구성해야 합니다.
ENGINE_SIZE -
작업자 메모리 할당
유형 - 정수
기본값 - 1802
단위 - 메가바이트(10242바이트)
엔진 작업자 프로세스가 객체에 대해 할당할 수 있는 최대 메모리 양(메가바이트)을 나타냅니다. 이 값을 구성하는 동안 다음 요인을 고려하십시오.
워크플로의 활동 수
인라인 식 또는 Node.js 작업의 복잡성
작업당 검색 또는 처리된 데이터의 양
개발 환경에서는 기본값으로 그대로 둡니다.
생산 환경에서는 ENGINE_SIZE의 값을 CHANNEL_MAX_FETCH에 사용된 값으로 나눈 시스템 RAM의 대략적인 최대 크기로 설정합니다.
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 값과 함께 이 값을 적절한 값으로 설정합니다.
총 지연이 총 요청 서비스 시간의 약 1/2을 초과하지 않도록 하는 것이 가장 좋습니다.
AVAILABLE_WORKER_CHECK_INTERVAL
- 작업자 사용 가능성 재시도 지연
유형 - 정수
기본값 - 3000
단위 - 밀리초
엔진 서비스가 워크플로 실행을 위해 작업자 프로세스를 예약하기 전에 대기하는 시간을 결정합니다. 이 경우 첫 번째 시도가 실패했다고 가정합니다.
개발에서는 이 값을 기본값으로 둡니다.
생산 환경에서는 AVAILABLE_WORKER_CHECK_TRIES 값과 함께 이 값을 적절한 값으로 설정합니다.
총 지연이 총 요청 서비스 시간의 약 1/2을 초과하지 않도록 하는 것이 가장 좋습니다.
WORKER_DISMISS_INTERVAL -
작업자 프로세스 스핀 다운 지연
유형 - 정수
기본값 - 1800
단위 - 초
엔진 서비스에서 작업자 프로세스 종료를 시작하기 전에 추가 작업을 대기하는 시간을 지정합니다. KILL_WORKER_AFTER_RUNtrue로 설정된 경우 이 값은 무시됩니다.
온프레미스 환경에서는 이 값을 기본값으로 둡니다.
클라우드 배포 또는 메모리 제약이 있는 환경에서는 특히 워크플로를 가끔씩만 사용하는 경우에는 이 값을 줄일 수 있습니다.
도움이 되셨나요?