FACHWISSEN · AUTOMATISIERUNG & TRANSFORMATIONINSIGHTS · AUTOMATION & TRANSFORMATION
Automatisierung unter Last: Warum mehr parallele Läufe nicht automatisch schneller sindAutomation under load: Why more parallel runs are not automatically faster
Ein Ablauf verarbeitet zehn Vorgänge gleichzeitig und wird langsamer statt schneller. Das ist kein Widerspruch. Parallelität nutzt freie Kapazität, erzeugt aber auch zusätzliche Anfragen, Konkurrenz um Ressourcen und gegebenenfalls Wiederholungen nach einer Drosselung.
Der Engpass bleibt auch bei mehr Startsignalen bestehen
Automatisierungsplattform und angebundene Systeme können unterschiedliche Grenzen besitzen. Ein Workflow darf möglicherweise mehrere Instanzen starten, während eine Schnittstelle nur eine begrenzte Zahl von Anfragen in einem Zeitraum akzeptiert. Eine HTTP-Antwort mit dem Status 429 weist auf zu viele Anfragen hin; die konkrete Behandlung richtet sich nach dem Dienst und seinen Vorgaben.
Die Zahl gleichzeitig aktiver Läufe ist deshalb keine Leistungskennzahl für sich. Entscheidend ist, wie viele fachlich korrekte Vorgänge pro Zeiteinheit abgeschlossen werden und wie lange ein Vorgang insgesamt wartet.
Ein Rechenbeispiel mit klaren Annahmen
Angenommen, eine Zielanwendung kann dauerhaft fünf Schreibvorgänge pro Sekunde verarbeiten. Ein vorgelagerter Ablauf erzeugt acht Vorgänge pro Sekunde. Solange diese Annahmen gelten, wächst der Rückstand um drei Vorgänge pro Sekunde. Zusätzliche parallele Aufrufer beseitigen die Differenz nicht.
Das vereinfachte Beispiel beschreibt einen Kapazitätsengpass. In der Praxis schwanken Eingang und Bearbeitungszeit. Deshalb müssen auch Lastspitzen, Warteschlangen und die zulässige Verzögerung betrachtet werden. Ein kurzer Mittelwert allein zeigt noch nicht, ob dringende Fälle rechtzeitig bearbeitet werden.
Parallelität nach Unabhängigkeit wählen
Unabhängige Lesezugriffe lassen sich oft anders parallelisieren als Änderungen am selben Datensatz. Zwei Läufe können beide einen alten Wert lesen und anschließend widersprüchliche neue Werte schreiben. Für solche Vorgänge werden beispielsweise Versionsprüfungen, atomare Änderungen oder eine geordnete Verarbeitung pro fachlichem Schlüssel benötigt.
Ein begrenzter Test erhöht die Parallelität schrittweise. Erfasst werden Durchsatz, Fehler, Wiederholungen und Wartezeit. Sobald zusätzliche Läufe keine zusätzlichen Abschlüsse mehr bringen, sollte zuerst der Engpass untersucht werden.
Wiederholungen zählen zur Last
Ein gedrosselter Aufruf, der sofort mehrfach wiederholt wird, erhöht den Druck auf das bereits ausgelastete System. Wartezeiten und gegebenenfalls vom Dienst mitgeteilte Wiederholungsfristen müssen berücksichtigt werden. Fachlich kritische Änderungen brauchen außerdem einen Schutz gegen Doppelwirkungen.
Eine gute Betriebsübersicht unterscheidet neue Arbeit, laufende Arbeit, wartende Arbeit und endgültig gescheiterte Arbeit. Erst diese Trennung zeigt, ob eine Automatisierung ihre Last bewältigt oder nur immer mehr Vorgänge gleichzeitig offen hält.
A workflow processes ten cases at once and becomes slower rather than faster. That is not a contradiction. Parallel execution uses spare capacity, but it also creates more requests, competition for resources and potentially retries after throttling.
Starting more work does not remove the bottleneck
The automation platform and connected systems may have different limits. A workflow may be allowed to start multiple instances while an API accepts only a limited number of requests in a period. An HTTP 429 response indicates too many requests; the appropriate response depends on the service and its instructions.
The number of active runs is therefore not a performance measure on its own. What matters is how many correct business cases finish per unit of time and how long each case waits overall.
A calculation with explicit assumptions
Assume a target application can continuously process five writes per second. An upstream workflow produces eight cases per second. While these assumptions hold, the backlog grows by three cases per second. Adding more parallel callers does not eliminate that difference.
This simplified example describes a capacity bottleneck. Real arrivals and processing times fluctuate. Load peaks, queues and acceptable delays must therefore also be considered. A short average alone does not show whether urgent cases are handled in time.
Choose parallelism according to independence
Independent reads can often be parallelised differently from changes to the same record. Two runs may both read an old value and then write conflicting new values. Such operations may need version checks, atomic updates or ordered processing by business key.
A controlled test increases parallelism step by step while recording throughput, errors, retries and waiting time. When additional runs no longer produce additional completions, investigate the bottleneck first.
Retries contribute to the load
Immediately repeating a throttled request several times adds pressure to a system that is already busy. Waiting periods and any retry timing supplied by the service need to be respected. Business-critical changes also need protection against duplicate effects.
A useful operational view distinguishes new work, active work, queued work and work that has finally failed. Only that distinction shows whether automation is coping with its load or merely keeping more cases open at the same time.