> ## 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.

# Skalierung

Der Orchestrator passt die Größe des Worker-Pools an die Warteschlange an. Sie legen die Ober- und Untergrenzen fest und bestimmen, wie schnell er reagiert.

## So wird die Größe des Pools bestimmt

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

begrenzt auf den Bereich zwischen `scaling.minWorkers` und `scaling.maxWorkers`. Die durchschnittliche Zeit pro Einheit beginnt bei `scaling.defaultUnitSeconds` und richtet sich nach den gemessenen Zeiten, sobald Einheiten abgeschlossen werden. Beispiel: 80 Einheiten in der Warteschlange mit je 30 Sekunden ergeben bei einem Zielwert von 120 Sekunden einen Bedarf von 20 zusätzlichen Workern.

Der Pool wächst, sobald die Warteschlange es erfordert, und schrumpft erst, wenn die Warteschlange über den Zeitraum `scaling.scaleDownCooldownMs` hinweg weniger Worker erfordert hat.

| Wert | Standard | Wirkung |
| - | - | - |
| `scaling.minWorkers` | `0` | Anzahl der Worker, die bei leerer Warteschlange weiterlaufen. |
| `scaling.maxWorkers` | `20` | Maximale Anzahl der Worker im Pool. |
| `scaling.minimumThroughputSeconds` | `120` | Wie schnell Arbeit in der Warteschlange Kapazität erhalten soll. Niedrigere Werte starten früher mehr Worker. |
| `scaling.defaultUnitSeconds` | `30` | Anfängliche Schätzung der Dauer einer Einheit. |
| `scaling.tickMs` | `15000` | Wie oft die Größe des Pools geprüft wird. |
| `scaling.scaleDownCooldownMs` | `300000` | Wie lange die Warteschlange weniger Worker erfordern muss, bevor der Pool schrumpft. |

Skalieren Sie das Worker-Deployment nicht selbst und hängen Sie keinen HorizontalPodAutoscaler daran an. Der Orchestrator setzt die Anzahl der Replikate bei seiner nächsten Prüfung zurück.

## Kapazität

Jeder Worker fordert `worker.resources.requests` an – standardmäßig 1 vCPU und 1 GB – und verarbeitet jeweils eine Einheit. Steigern Sie den Durchsatz, indem Sie `maxWorkers` erhöhen, statt den Workern mehr CPU zuzuweisen.

Der Orchestrator erstellt lediglich pods. Der Cluster benötigt daher einen Knoten-Autoscaler, der die erforderlichen Knoten hinzufügt. Bevor Sie `maxWorkers` auf mehrere Hundert erhöhen, prüfen Sie sowohl das CPU-Kontingent Ihrer Cloud als auch die Limits des Clusters.

Das chart legt Requests fest, jedoch keine Limits. Wenn Worker bei großen oder hochauflösenden Seiten wegen Arbeitsspeicherknappheit verdrängt werden, erhöhen Sie `worker.resources.requests.memory`.

## Kaltstarts

Bei `minWorkers: 0` muss der erste Job nach einer Leerlaufphase warten, bis ein Worker eingeplant wurde, sein Image abgerufen hat und gestartet ist. Legen Sie `minWorkers` fest, um Worker einsatzbereit zu halten. Wie Sie Lastspitzen auf neuen Knoten schneller abarbeiten, erfahren Sie unter [Vorab-Abruf des Worker-Images](https://docs.abbyy.com/de/fine-parser/enterprise/best-practices/scheduling.md#pre-pulling-the-worker-image).

## Einheitengröße und Leases

Ein PDF mit mehr als `ingest.pageSplitThreshold` Seiten (25) wird in Teile mit jeweils dieser Seitenzahl aufgeteilt; jeder Teil bildet eine Arbeitseinheit. Je kleiner die Einheiten, desto mehr Worker teilen sich die Verarbeitung eines großen Dokuments.

Ein Worker muss eine Einheit innerhalb von `orchestrator.workLeaseSeconds` (300) Sekunden abschließen. Andernfalls wird die Einheit einem anderen Worker zugewiesen, und nach `orchestrator.workMaxAttempts` (3) Versuchen schlägt der Job mit `timed-out` fehl. Wählen Sie die Lease-Dauer länger als die Verarbeitungszeit Ihrer langsamsten Einheit, oder senken Sie den Schwellenwert für die Aufteilung.

## Ingest-Komponente und Orchestrator

Die Ingest-Komponente läuft in `ingest.replicas` pods. Erhöhen Sie diesen Wert, wenn das Hochladen oder die Aufteilung von PDFs die Ingest-Komponente dauerhaft auslastet. Der Orchestrator läuft immer als einzelnes Replikat.