Zum Hauptinhalt springen
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

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

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