# Настройка отдельных пулов worker для обработки скриптов

> [HTML Version](worker-pools.html)

В ELMA365 за валидацию, компиляцию и исполнение серверных скриптов отвечает сервис **worker**. Чтобы повысить его производительность, вы можете выделить отдельные пулы исполнения:

- для объектов системы, где инициируются скрипты. Например, для скриптов виджетов или определённого бизнес-процесса;

- для отдельных типов запросов на обработку скриптов. Например, для их публикации или исполнения.

````
начало внимание

````
Настройка отдельных пулов **worker** доступна для поставки ELMA365 On‑Premises Enterprise начиная с версии 2025.6.

````
конец внимание

````
В статье рассмотрим, как в системе:

- [обрабатываются скрипты](#script-processing);

- [настроить отдельные пулы worker для определённых скриптов](#configure-pools);

- [ускорить исполнение скриптов заданного объекта](#hot-forks).

## Алгоритм обработки скриптов в сервисе worker 

Для распределения нагрузки на сервис **worker** используются инструменты:

- Kubernetes — обеспечивает масштабирование экземпляров сервиса, в которых выполняются скрипты;

- RabbitMQ — выступает в качестве маршрутизатора, распределяя запросы на выполнение скриптов между доступными экземплярами **worker**.

При стандартной конфигурации **worker** запросы на обработку скриптов поступают в RabbitMQ и распределяются в рамках общей очереди. Это повышает нагрузку на сервис и замедляет выполнение скриптов.

Настройка отдельных пулов для скриптов определённого типа помогает оптимизировать распределение этой нагрузки. После такой настройки :

- в Kubernetes — передаются данные, по которым будут разворачиваться пулы;

- в RabbitMQ — автоматически добавляется отдельная очередь для каждого настроенного пула.

Рассмотрим подробнее, как происходит маршрутизация запросов на скрипты:

1. **Определение ключа маршрутизации**.

При запуске скрипта автоматически формируется запрос, содержащий его параметры: имя компании, публикация или исполнение скрипта, объекта системы, из которого направлен скрипт, и т. д. На основе этих данных вычисляется ключ маршрутизации:

	- если вы [настроили для определённых скриптов отдельные пулы](#configure-pools), запросу присваивается ключ, равный идентификатору пула **worker**;

	- если подходящего пула нет — присваивается ключ \[OBJECT\].

2. **Распределение запросов**.

Запросы с присвоенным ключом поступают в RabbitMQ, где происходит их маршрутизация:

	- если вы задали для отдельных скриптов свои пулы **worker**, в RabbitMQ** **автоматически создаются очереди для таких пулов. Запросы распределятся в эту очередь по присвоенному ключу;

	- запросы с ключом \[OBJECT\]  попадают в общую очередь \[OBJECT\].

3. **Обработка запросов**.

Из очередей запросы распределяются между экземплярами **worker**:

	- из выделенных очередей запросы на обработку скриптов передаются на настроенные пулы **worker**;

	- из очереди \[OBJECT\]** **— распределяются между общими экземплярами **worker**.

## Настроить пулы worker

Настройка пулов **worker** состоит из двух этапов:

1. [Задать конфигурацию пулов worker](#pool-parameters).

2. [Применить настроенную конфигурацию](#apply-pool-parameters).

### Шаг 1. Задать конфигурацию пулов worker

Чтобы создать отдельный пул **worker** для определённых скриптов, в файле \[OBJECT\] задайте его конфигурацию. В ней определите критерии отбора скриптов, параметры автомасштабирования экземпляров в пуле, а также время ожидания выполнения скриптов.

Для этого:

1. Создайте резервную копию файла \[OBJECT\], заполненного при установке ELMA365. Это требуется перед редактированием, так как некорректная настройка параметров может привести к сбоям в работе приложения ELMA365.

2. В конфигурационном файле \[OBJECT\] перейдите к блоку \[OBJECT\] и заполните параметры в секции \[OBJECT\].

````
начало примечание

````
**Пример настройки параметров в секции workerPoolCfg**

````
global:  
   workerPoolCfg:  
     pools:  
       namespacepool: # Наименование пула задаётся в свободной форме строчными латинскими буквами и цифрами длиной до 20 символов   
         sources: # Фильтры для отбора скриптов, которые будут распределяться на пул  
         - company: head  
           operation: execute  
           type: process  
           namespace: crm  
           code: createlead  
         autoscaling: # Параметры автомасштабирования для пула  
           enabled: true  
           type: "hpa"  
           minReplicas: 1  
           maxReplicas: 9  
         options: # Дополнительные опции для пула — таймауты  
           defaultScriptTimeoutSeconds: 180  
           maxScriptTimeoutSeconds: 1200

конец примечание

````
Для этого укажите:

1. **Идентификатор пула** (\[OBJECT\]) — наименование пула **worker**. Задайте пользовательское название для пула, используя строчные латинские буквы и цифры длиной до 20 символов.

2. **Источники запросов на обработку скриптов** (\[OBJECT\]).   
  
Когда в системе запускается скрипт, автоматически генерируется запрос на его обработку. В этом запросе передаются параметры скрипта. Укажите, по каким параметрам отбирать скрипты для настраиваемого пула:

	- \[OBJECT\] — имя компании в кластере;

	- \[OBJECT\] — тип запроса: публикация или исполнение скрипта. Добавьте одно из доступных значений: \[OBJECT\] или \[OBJECT\]. Например, обрабатывать только публикацию скриптов, указав конфигурацию: 

````
workerPoolCfg:  
   pools:  
     publishpool:  
       sources:  
       - operation: compile

	- ````
\[OBJECT\] — объект системы, из которого направлен запрос на обработку скрипта. Укажите одно из доступных значений:

		- \[OBJECT\] — бизнес-процесс;

		- \[OBJECT\] — действие БП в модуле;

		- \[OBJECT\] — виджет;

		- \[OBJECT\] — обработчик события;

		- \[OBJECT\] — обработчик методов API;

	- \[OBJECT\] — название пространства имён для объекта системы, из которого направлен запрос на обработку скрипта. Например, для раздела — это его код;

	- \[OBJECT\] — код объекта системы, из которого направлен запрос на обработку скрипта. Например, код бизнес-процесса, действия БП в модуле и т. д.



Чем больше условий задано, тем точнее отбор скриптов для пула. Если параметр не заполнен, он не учитывается.



Примеры конфигураций для отбора скриптов

  
Рассмотрим варианты настройки пулов, демонстрирующие разные уровни отбора скриптов:

1. Самый широкий охват — на выделенном пуле **worker** публикуются и исполняются все скрипты раздела **CRM**:

````
workerPoolCfg:  
   pools:  
     namespacepool: # Идентификатор пула задаётся в свободной форме строчными латинскими буквами и цифрами длиной до 20 символов  
       sources:  
       - company: head # Имя компании  
         namespace: crm # Код раздела

2. ````
Умеренный отбор — на выделенном пуле **worker **исполняются скрипты только из бизнес-процессов раздела **CRM**:

````
workerPoolCfg:  
   pools:  
     namespacepool: # Идентификатор пула задаётся в свободной форме строчными латинскими буквами и цифрами длиной до 20 символов  
       sources:  
       - company: head # Имя компании  
         namespace: crm # Код раздела  
         operation: execute # Тип операции — исполнение скриптов  
         type: process # Отбираются только скрипты из бизнес-процессов

3. ````
Более точный отбор — на выделенном пуле **worker **исполняются скрипты бизнес-процессов, созданных на уровне приложения с кодом \[OBJECT\] из раздела **CRM**:

````
workerPoolCfg:  
   pools:  
     applicationpool: # Идентификатор пула задаётся в свободной форме строчными латинскими буквами и цифрами длиной до 20 символов  
       sources:  
       - company: head # Имя компании  
         namespace: crm.clientapp # \`\{код раздела\}.\{код приложения\}\`  
         operation: execute # Тип операции — исполнение скриптов  
         type: process # Отбираются только скрипты из бизнес-процессов

4. ````
Максимально точный отбор — на выделенном пуле **worker **исполняются скрипты только из бизнес-процесса **Создание лида**:

````
workerPoolCfg:  
   pools:  
     processpool: # Идентификатор пула задаётся в свободной форме строчными латинскими буквами и цифрами длиной до 20 символов  
       sources:  
       - company: head # Имя компании  
         namespace: crm.clientapp # \`\{код раздела\}.\{код приложения\}\`  
         operation: execute # Тип операции — исполнение скриптов  
         type: process # Отбираются только скрипты из бизнес-процесса  
         code: createlead # Код бизнес-процесса, из которого отбираются скрипты
````

3. ````
**Параметры для автомасштабирования пула **(\[OBJECT\]).  
  
В зависимости от нагрузки на пул **worker**, задайте настройки для его автоматического масштабирования. На их основе в оркестраторе Kubernetes будет создаваться указанное количество экземпляров **worker**. Для этого заполните параметры в блоке \[OBJECT\]:

	- \[OBJECT\] — значение \[OBJECT\] включает автомасштабирование;

	- \[OBJECT\] — выбор метода автомасштабирования. Определите, какой инструмент использовать. Доступные значения: 

		- \[OBJECT\] — Horizontal Pod Autoscaler. Используется по умолчанию. Не требуется дополнительных настроек;

		- \[OBJECT\] — Kubernetes Event-driven Autoscaling. Используется, если настроен дополнительный компонент [KEDA](install-keda.md);

	- \[OBJECT\] — минимальное количество экземпляров в пуле;

	- \[OBJECT\] — максимальное количество экземпляров в пуле.

4. **Дополнительные опции для пула  **(\[OBJECT\]).  
  
Для серверных скриптов существует время ожидания их исполнения — таймаут. Если скрипт не выполнился в течение этого времени, он прерывается. Таким образом работа пула не блокируется из‑за долгого выполнения скриптов. Для установки таймаутов в секции \[OBJECT\] заполните параметры:

	- \[OBJECT\] — стандартное время ожидания исполнения скрипта в секундах. После истечения этого времени исполнение скрипта прерывается;

	- \[OBJECT\] — максимальное время ожидания исполнения скрипта в секундах. После истечения этого времени исполнение скрипта прерывается. 

### Шаг 2. Применить настроенную конфигурацию пулов worker

Когда в файле \[OBJECT\] вы задали конфигурацию для отбора скриптов и для автомасштабировния пулов **worker**, [примените обновлённые параметры](change-settings-enterprise.md#apply-new-parameters). 

### Пример настройки отдельного пула для обработки скриптов бизнес-процесса

Допустим, в файле \[OBJECT\] мы настроили отдельный пул **worker** для бизнес-процесса по созданию лида в разделе **CRM**:

````
workerPoolCfg:  
   pools:  
     processpool: # Идентификатор пула задаётся в свободной форме строчными латинскими буквами и цифрами длиной до 20 символов  
       sources:  
       - company: head # Имя компании  
         namespace: crm # Код раздела, на уровне которого создан бизнес-процесс  
         operation: execute # Тип операции — исполнение скриптов  
         type: process # Отбираются только скрипты из бизнес-процесса  
         code: createlead # Отбираются только скрипты с кодом бизнес-процесса для создания лида  
       autoscaling:   
         enabled: true  
         type: "hpa"  
         minReplicas: 1  
         maxReplicas: 9

````


После применения этих настроек автоматически создались:

- в Kubernetes пул **worker**;

- в RabbitMQ отдельная очередь для этого пула, чтобы распределять запросы на обработку скриптов по бизнес-процессу для создания лида.

Когда в системе запустился процесс для создания лида, автоматически сгенерировался запрос на обработку скрипта. В этом запросе передались данные:

- компания: \[OBJECT\]; 

- операция: \[OBJECT\];

- тип объекта системы: \[OBJECT\]; 

- пространство имён объекта системы: \[OBJECT\];

- код объекта системы: \[OBJECT\].

Поскольку мы указали эти данные в настройках выделенного пула **worker**, запрос автоматически ставится в отдельную очередь этого пула и выполняется в нём.

## Ускорить исполнение скриптов заданного объекта



Начиная с версии 2026.2, в пуле **worker**, настроенном на работу с одним объектом, можно ускорить исполнение серверных скриптов. Это достигается за счёт повторного использования среды выполнения. Она подготавливается один раз, а затем применяется для следующих скриптов.

Чтобы активировать работу выделенного пула таким образом:



1. В файле `values‑elma365.yaml` в блоке `global` в секции `workerPoolCfg` настройте конфигурацию пула на исполнение серверных скриптов только одного объекта — виджета, бизнес-процесса и т. д.

2. Укажите полное описание объекта, заполнив все значения в [параметре sources](#source): `company`, `type`, `operation`, `namespace`, `code`.  
  
Параметр `code` может отсутствовать или содержать пустое значение только для методов API.



Тогда среда выполнения будет использоваться повторно, пока не изменятся параметры, влияющие на неё — версия объекта, текст или настройки скрипта, идентификатор файла серверных зависимостей, метаданные компании и т. д. При изменении хотя бы одного из них среда создаётся заново.



Примеры настроек пула worker для переиспользования среды выполнения

1. Виджет страницы:

````
workerPoolCfg:  
   pools:  
     widgetpool:  
       sources:  
       - company: company1  
         type: widget  
         operation: execute  
         namespace: orders.summary  
         code: \_page

````


2. Обработчик события:

````
workerPoolCfg:  
   pools:  
     eventhandlerpool:  
       sources:  
       - company: company1  
         type: eventhandler  
         operation: execute  
         namespace: ext\_531577a5-b874-4685-9dfc-942ac8805939  
         code: 6e3e4fbd-6339-496b-9715-f74c7484fc95

````


3. Метод API. Т. к. все методы API являются одним объектом, не требуется указывать код:

````
workerPoolCfg:  
   pools:  
     apimethodpool:  
       sources:  
       - company: company1  
         type: apihandler  
         operation: execute  
         namespace: ext\_531577a5-b874-4685-9dfc-942ac8805939
````

### ````


## Удалить созданный пул worker

Чтобы удалить настроенный пул **worker**, в файле \[OBJECT\] уберите ранее заданные параметры и [примените](change-settings-enterprise.md#apply-new-parameters) их. После этого в RabbitMQ все необработанные запросы на обработку скриптов из его очереди перенаправятся в очередь \[OBJECT\]. Из неё распределятся на общие экземпляры **worker**.