# Dedicated worker pools for script processing > [HTML Version](worker-pools.html) In BRIX, the **worker **service is responsible for the validation, compilation, and execution of server scripts. To improve its performance, you can allocate dedicated execution pools: - For system objects where scripts are initiated. For example, for widget scripts or a specific business process. - For specific types of script processing requests. For example, for their compilation or execution. ```` начало внимание ```` The configuration of dedicated **worker** pools is available for BRIX On‑Premises starting from version 2025.6. ```` конец внимание ```` This article describes how the system: - [Processes scripts](#script-processing). - [Configures dedicated worker pools for specific scripts](#configure-pools). - [Execute scripts of a specific object faster](#hot-forks). ## Script processing algorithm in the worker service The following tools are used to distribute the load on the **worker** service: - Kubernetes. Ensures the scaling of service replicas where scripts are executed. - RabbitMQ. Acts as a router, distributing script execution requests among available **worker** replicas. With the default **worker** configuration, script processing requests are sent to RabbitMQ and distributed within a shared queue. This increases the load on the service and slows down script execution. Configuring dedicated pools for specific types of scripts helps optimize this load distribution. After such configuration: - In Kubernetes, data is transmitted to deploy the pools. - In RabbitMQ, a separate queue is automatically added for each configured pool. Let’s take a closer look at how script request routing works: 1. **Routing key determination**. When a script is launched, a request containing its parameters is automatically generated: company name, script compilation or execution, the system structure from which the script was initiated, etc. Based on this data, a routing key is determined: - If you [have configured dedicated pools for specific scripts](#configure-pools), the request gets a key equal to the **worker** pool identifier. - If no suitable pool exists, the \[OBJECT\] key is assigned. 2. **Request distribution**. Requests with assigned keys are sent to RabbitMQ, where they are routed: - If you have specified dedicated **worker** pools for certain scripts, RabbitMQ automatically creates queues for these pools. Requests are distributed to these queues based on the assigned key. - Requests with the \[OBJECT\] key are placed in the shared \[OBJECT\] queue. 3. **Request processing**. Requests are distributed from the queues to **worker** replicas: - From dedicated queues, script processing requests are sent to the configured **worker** pools. - From the \[OBJECT\] queue, requests are distributed among shared **worker** replicas. ## Configure worker pools The configuration of **worker** pools consists of two steps: 1. [Define the worker pool configuration](#pool-parameters). 2. [Apply the configured settings](#apply-pool-parameters). ### Step 1: Define the worker pool configuration To create a dedicated **worker** pool for specific scripts, specify its configuration in the \[OBJECT\] file. Define the script selection criteria, autoscaling parameters for pool replicas, and script execution timeout settings. To do this: 1. Create a backup of the \[OBJECT\] file filled during BRIX installation. This is necessary before editing, as incorrect parameter settings may cause BRIX application failures. 2. In the \[OBJECT\] configuration file, go to the \[OBJECT\] block and fill in the parameters in the \[OBJECT\] section. ```` начало примечание ```` **Example of parameter configuration in the workerPoolCfg section ** ```` global: workerPoolCfg: pools: namespacepool: # The pool name is specified in free form using lowercase Latin letters and numbers, up to 20 characters long sources: # Filters for selecting scripts to be distributed to the pool - company: head operation: execute type: process namespace: crm code: createlead autoscaling: # Autoscaling parameters for the pool enabled: true type: "hpa" minReplicas: 1 maxReplicas: 9 options: # Additional pool options — timeouts defaultScriptTimeoutSeconds: 180 maxScriptTimeoutSeconds: 1200 конец примечание ```` For this, specify: 1. **Pool identifier** (\[OBJECT\]). The name of the **worker** pool. Assign a custom name to the pool using lowercase Latin letters and numbers, up to 20 characters long. 2. **Sources of script processing requests** (\[OBJECT\]). When a script is launched in the system, a request for its processing is automatically generated. This request includes the script parameters. Specify which parameters to use for selecting scripts for the configured pool: - \[OBJECT\]. The company name in the cluster. - \[OBJECT\]. The request type: script compilation or execution. Add one of the available values: \[OBJECT\] or \[OBJECT\]. For example, to process only script compilation, specify the configuration: ```` workerPoolCfg: pools: publishpool: sources: - operation: compile - ```` \[OBJECT\]. The system object from which the script processing request was initiated. Specify one of the available values: - \[OBJECT\]. Business process. - \[OBJECT\]. Business process action in the module. - \[OBJECT\]. Widget. - \[OBJECT\]. Event handler. - \[OBJECT\]. API method handler. - \[OBJECT\]. The namespace of the system object from which the script processing request was initiated. For example, for a workspace, this is its code. - \[OBJECT\]. The code of the system object from which the script processing request was initiated. For example, the business process code, the code of the business process action in the module, etc. The more conditions specified, the more precise the script selection for the pool. If a parameter is not filled in, it is not considered. Examples of script selection configurations Let’s see pool configuration options demonstrating different levels of script selection: 1. Broadest coverage. All scripts in the **CRM** workspace are published and executed on a dedicated **worker** pool: ```` workerPoolCfg: pools: namespacepool: # The pool identifier is specified in free form using lowercase Latin letters and numbers, up to 20 characters long sources: - company: head # Company name namespace: crm # Workspace code 2. ```` Moderate selection. Only scripts from business processes in the **CRM** workspace are executed on a dedicated **worker** pool: ```` workerPoolCfg: pools: namespacepool: # The pool identifier is specified in free form using lowercase Latin letters and numbers, up to 20 characters long sources: - company: head # Company name namespace: crm # Workspace code operation: execute # Operation type — script execution type: process # Only scripts from business processes are selected 3. ```` More precise selection. Scripts from business processes associated with the app with the \[OBJECT\] code in the **CRM** workspace are executed on a dedicated **worker** pool: ```` workerPoolCfg: pools: applicationpool: # The pool identifier is specified in free form using lowercase Latin letters and numbers, up to 20 characters long sources: - company: head # Company name namespace: crm.clientapp # \`\{workspace code\}.\{app code\}\` operation: execute # Operation type — script execution type: process # Only scripts from business processes are selected 4. ```` Most precise selection. Only scripts from the **Create lead** business process are executed on a dedicated **worker** pool: ```` workerPoolCfg: pools: processpool: # The pool identifier is specified in free form using lowercase Latin letters and numbers, up to 20 characters long sources: - company: head # Company name namespace: crm.clientapp # \`\{workspace code\}.\{app code\}\` operation: execute # Operation type — script execution type: process # Only scripts from the business process are selected code: createlead # The business process code from which scripts are selected ```` 3. ```` **Autoscaling pool parameters** (\[OBJECT\] ). Depending on the load on the **worker** pool, configure settings for its automatic scaling. Based on these settings, the specified number of **worker** replicas will be created in the Kubernetes orchestrator. To do this, fill in the parameters in the \[OBJECT\] block: - \[OBJECT\]. The \[OBJECT\] value enables autoscaling. - \[OBJECT\]. The autoscaling method selection. Specify which tool to use. Available values: - \[OBJECT\]. Horizontal Pod Autoscaler. Used by default. No additional configuration is required. - \[OBJECT\]**. **Kubernetes event-driven autoscaling. Used if the additional [KEDA](install-keda.md) component is configured. - \[OBJECT\]. The minimum number of replicas in the pool. - \[OBJECT\]. The maximum number of replicas in the pool. 4. **Additional pool options** (\[OBJECT\]). For server scripts, there is an execution timeout. If a script does not complete within this time, it is terminated. This prevents the pool from being blocked due to long script execution. To set timeouts, fill in the parameters in the \[OBJECT\] section: - \[OBJECT\]. The standard script execution timeout in seconds. After this time is up, script execution is terminated. - \[OBJECT\]. The maximum script execution timeout in seconds. After this time is up, script execution is terminated. ### Step 2: Apply the configured worker pool settings Once you have configured the script selection and autoscaling parameters for **worker** pools in the \[OBJECT\] file, [apply the updated settings](change-settings-enterprise.md#apply-new-parameters). ### Use case: Configuring a dedicated pool for business process script processing Suppose we have configured a dedicated **worker** pool in the \[OBJECT\] file for the **Create lead** business process in the **CRM** workspace: ```` workerPoolCfg: pools: processpool: # The pool identifier is specified in free form using lowercase Latin letters and numbers, up to 20 characters long sources: - company: head # Company name namespace: crm # Workspace code where the business process is created operation: execute # Operation type — script execution type: process # Only scripts from the business process are selected code: createlead # Only scripts with the Create lead business process code are selected autoscaling: enabled: true type: "hpa" minReplicas: 1 maxReplicas: 9 ```` After applying these settings, the following are automatically created: - A **worker** pool in Kubernetes. - A separate queue in RabbitMQ for this pool to distribute script processing requests for the **Create lead** business process. When the **Create lead** process is launched in the system, a script processing request is automatically generated. This request includes the following data: - Company: \[OBJECT\]. - Operation: \[OBJECT\]. - System structure type: \[OBJECT\]. - System structure namespace: \[OBJECT\]. - System structure code: \[OBJECT\]. Since we specified this data in the dedicated **worker** pool settings, the request is automatically placed in this pool’s queue and executed within it. ## Execute scripts of a specific object faster Starting with version 2026.2, you can speed up the execution of server-side scripts in a **worker** pool configured to work with a single object. This is achieved by reusing the execution environment. It is prepared once and then used for subsequent scripts. To enable a dedicated pool to work in such a mode: 1. In the `values-brix365.yaml` file, in the `global` block, in the `workerPoolCfg` section, configure the pool to execute server-side scripts for only one object — a widget, business process, etc. 2. Specify a full description of the object by filling in all values in the [sources parameter](#sources): `company`, `type`, `operation`, `namespace`, and `code`. The `code` parameter may be skipped or empty only for API methods. The execution environment will then be reused until any parameters that affect it change — object version, script text or settings, server dependency file ID, company metadata, etc. If even one of these changes, the execution environment is recreated. Examples of worker pool settings for reusing the execution environment 1. **Page widget**: ```` workerPoolCfg: pools: widgetpool: sources: - company: company1 type: widget operation: execute namespace: orders.summary code: \_page ```` 2. **Event handler**: ```` 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 method**. Since all API methods are a single object, there is no need to specify the code: ```` workerPoolCfg: pools: apimethodpool: sources: - company: company1 type: apihandler operation: execute namespace: ext\_531577a5-b874-4685-9dfc-942ac8805939 ```` ## Delete a configured worker pool To delete a configured **worker** pool, remove the previously specified parameters from the \[OBJECT\] file and [apply](change-settings-enterprise.md#apply-new-parameters) them. After this, in RabbitMQ, all unprocessed script processing requests from its queue will be redirected to the \[OBJECT\] queue. From there, they will be distributed among shared **worker** replicas.