> ## Documentation Index
> Fetch the complete documentation index at: https://docs.abbyy.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Escalado

El orquestador ajusta el tamaño del pool de trabajadores según la cola. Usted define los límites y la rapidez con la que reacciona.

## Cómo se determina el tamaño del pool

```text theme={null}
workers = busy + ceil(queued units × average unit time / minimumThroughputSeconds)
```

acotado entre `scaling.minWorkers` y `scaling.maxWorkers`. El tiempo medio por unidad parte de `scaling.defaultUnitSeconds` y se va ajustando a los tiempos medidos a medida que se completan las unidades. Por ejemplo, 80 unidades en cola de 30 segundos cada una, con un objetivo de 120 segundos, requieren 20 trabajadores más.

El pool crece en cuanto la cola lo requiere y solo se reduce después de que la cola haya requerido menos trabajadores durante `scaling.scaleDownCooldownMs`.

| Valor | Predeterminado | Efecto |
| - | - | - |
| `scaling.minWorkers` | `0` | Trabajadores que se mantienen en ejecución cuando la cola está vacía. |
| `scaling.maxWorkers` | `20` | Número máximo de trabajadores que ejecuta el pool. |
| `scaling.minimumThroughputSeconds` | `120` | Rapidez con la que el trabajo en cola debe obtener capacidad. Un valor más bajo inicia más trabajadores antes. |
| `scaling.defaultUnitSeconds` | `30` | Estimación inicial del tiempo que tarda una unidad. |
| `scaling.tickMs` | `15000` | Frecuencia con la que se comprueba el tamaño del pool. |
| `scaling.scaleDownCooldownMs` | `300000` | Tiempo durante el que la cola debe requerir menos trabajadores antes de que el pool se reduzca. |

No escale manualmente el Deployment del trabajador ni le adjunte un HorizontalPodAutoscaler. El orquestador restablece el número de réplicas en su siguiente comprobación.

## Capacidad

Cada trabajador solicita `worker.resources.requests` (1 vCPU y 1 GB de forma predeterminada) y procesa una unidad a la vez. Para aumentar el rendimiento, incremente `maxWorkers` en lugar de asignar más CPU a los trabajadores.

El orquestador solo crea pods, por lo que el clúster necesita un escalador automático de nodos que agregue los nodos necesarios para alojarlos. Antes de aumentar `maxWorkers` a varios cientos, compruebe tanto la cuota de CPU de su proveedor de nube como los límites del clúster.

El chart define solicitudes de recursos, pero no límites. Si los trabajadores se desalojan por presión de memoria al procesar páginas grandes o de alta resolución, aumente `worker.resources.requests.memory`.

## Arranques en frío

Con `minWorkers: 0`, el primer trabajo tras un periodo de inactividad debe esperar a que se programe un trabajador, se descargue su imagen y se inicie. Configure `minWorkers` para mantener trabajadores disponibles. Para acelerar los picos de carga en nodos nuevos, consulte [Descarga previa de la imagen del trabajador](https://docs.abbyy.com/es/fine-parser/enterprise/best-practices/scheduling.md#pre-pulling-the-worker-image).

## Tamaño de las unidades y concesiones

Un PDF con más de `ingest.pageSplitThreshold` páginas (25) se divide en partes con ese número de páginas, y cada parte constituye una unidad de trabajo. Cuanto más pequeñas son las unidades, más trabajadores se reparten un documento grande.

Un trabajador debe terminar una unidad en el plazo definido por `orchestrator.workLeaseSeconds` (300). De lo contrario, la unidad se asigna a otro trabajador y, tras `orchestrator.workMaxAttempts` (3) intentos, el trabajo falla con `timed-out`. Configure una concesión superior al tiempo que tarda su unidad más lenta, o reduzca el umbral de división.

## Ingest y el orquestador

Ingest ejecuta `ingest.replicas` pods. Aumente este valor si las cargas o la división de archivos PDF mantienen ocupado a Ingest. El orquestador siempre se ejecuta con una sola réplica.