API-Limits und Leistung

Planen Sie die Workflow-Leistung mit zwei Fragen: Wie viel Arbeit nehmen die beteiligten APIs an, und bis wann muss ein Vorgang sein fachliches Ergebnis erreichen? Mehr gleichzeitige Aufrufe helfen nur, solange die Systeme sie verarbeiten können.

Vier Grenzen auseinanderhalten

Die Grenzen können sich überlagern. GitHub nennt für seine REST-API primäre Limits und für GraphQL ein separates primäres Limit. Bei Microsoft Graph variieren die Drosselungsgrenzen je nach Szenario und Art der Anfragen.

Kapazitätsplanung: Wichtige Grenzwerte im Überblick

Batchgrenzen in die Kapazitätsplanung aufnehmen

Ein Batch ändert, wie viele Arbeitsschritte ein Aufruf transportiert, aber nicht zwingend die Limits oder die zulässige Menge pro Operation. Bei Amazon SQS nimmt SendMessageBatch höchstens 10 Nachrichten je Aufruf an; maximale Größe einer Nachricht und maximale Gesamtgröße der Nutzdaten im Batch betragen je 1 MiB. Diese Obergrenzen bestimmen, wie viele Aufrufe das erwartete Arbeitsvolumen benötigt.

Planen Sie nicht nur die Zahl äußerer HTTP-Aufrufe, sondern auch die enthaltenen Operationen und ihren Typ. Das zählt besonders, wenn ein Ablauf viele Schreibvorgänge bündelt oder ein gemeinsames Budget mit anderen Anwendungen nutzt.

Das Budget für den ganzen Vorgang bestimmen

Zählen Sie die Aufrufe eines vollständigen Falls: Abruf mit weiteren Ergebnisseiten, Schreibaufruf und spätere Statusprüfung. Rechnen Sie Wiederholungen ein. Halten Sie je Operation fest, welches Budget sie belastet. Ein Grenzwert für den gesamten Workflow ist irreführend, wenn die API Ressourcen oder Anfragearten getrennt begrenzt.

Beispiel: Eine interne App überträgt freigegebene Materialanforderungen. Klären Sie, ob Positionen einzeln oder gemeinsam gesendet werden und welcher Nachweis die Übernahme bestätigt.

Nutzen mehrere Worker dasselbe API-Budget, muss die Begrenzung über alle diese Worker gelten. Prüfen Sie auch andere Abläufe mit demselben Zugang. Die Kapazitätsaufteilung richtet sich nach ihrer fachlichen Priorität.

Leiten Sie die zulässige Parallelität nicht allein aus dem Anfragebudget ab. Für eine belastbare Schätzung zählen zusätzlich Bearbeitungsdauer, zeitliche Verteilung der API-Aufrufe je Fall und Verarbeitungskapazität. Starten Sie konservativ und passen Sie an, wenn Drosselung oder wachsender Rückstand sichtbar werden.

Schritte zur Planung der Workflow-Leistung

Limits konkret einordnen

Ein API-Limit lässt sich erst bewerten, wenn Authentifizierung und Operation feststehen. Bei GitHub sind nicht authentifizierte REST-Aufrufe für öffentliche Daten auf 60 Anfragen pro Stunde begrenzt; authentifizierte Anfragen mit persönlichem Zugriffstoken zählen grundsätzlich zu 5.000 pro Stunde. Für bestimmte Apps von GitHub-Enterprise-Cloud-Organisationen nennt GitHub 15.000 Anfragen pro Stunde.

Diese Budgets sind nicht immer unabhängig: Anfragen einer App mit höherem Limit können das verbleibende Budget niedriger eingestufter Authentifizierungsarten verringern. GitHub führt GraphQL mit separatem primärem Limit und Git-LFS-Aufrufe in eigenem Limit-Bucket. Für einzelne REST-Endpunkte, etwa Suchendpunkte, können restriktivere Grenzen gelten. Eine Kapazitätsplanung nur nach dem allgemeinen REST-Limit fällt daher zu hoch aus.

Microsoft Graph nennt keine einheitliche Grenze für alle Fälle: Die Drosselung hängt unter anderem vom Szenario und der Art der Anfragen ab. Umfangreiche Schreibvorgänge werden eher gedrosselt als reine Lesevorgänge; bei bestimmten Lasten können Schreibaufrufe bereits begrenzt sein, während Leseaufrufe noch möglich sind. Relevant sind auch die Last anderer Anwendungen im Mandanten und die Nutzung derselben Anwendung über mehrere Mandanten.

Bei Überschreitung kann Microsoft Graph weitere Anfragen der betroffenen Client-App zeitweise begrenzen und mit HTTP 429 antworten. Die Antwort enthält eine empfohlene Wartezeit im Header Retry-After; rechnen Sie diese Verzögerung in die erwartete Ergebnisdauer ein, statt eine schnelle erfolgreiche Antwort anzunehmen.

Vergleich der API-Limits verschiedener Plattformen

Lastspitzen und Teilfehler berücksichtigen

Treffen Auslöser schneller ein, als das Ziel verarbeitet, kann eine Warteschlange Arbeit puffern. Sie erhöht die Kapazität der Ziel-API nicht. Planen Sie zulässige Wartezeit, Aufbewahrung und Abbau des Rückstands zusammen.

Zeitliche Abfolge bei API-Aufrufen mit Drosselung

Leistung am Ergebnis beurteilen

Messen Sie die Ergebnisdauer vom fachlichen Auslöser bis zur bestätigten Erledigung. Eine schnelle HTTP-Antwort belegt nicht von selbst einen abgeschlossenen Geschäftsvorgang.

Beobachten Sie zusätzlich Rückstand und Alter offener Fälle. Amazon SQS liefert Metriken für verfügbare und gerade verarbeitete Nachrichten sowie für das Alter der ältesten unverarbeiteten Nachricht. Die Werte sind teils ungefähr und ersetzen keine Messung je Geschäftsvorgang.

Für die erste Planung halten Sie fest: Welches Ergebnis wird bis wann gebraucht? Welche Limits gelten für die verwendeten Operationen? Wie werden zusätzliche Auslöser aufgenommen? Wer übernimmt Fälle mit unklarem oder verspätetem Ergebnis?