Denselben Ablauf vergleichen
Fiktives Beispiel mit dezimalen Kilobytes: zunächst 100 Aufrufe mit je 100 kB, danach 20 mit je 50 kB. Die Datenmenge sinkt von 10000 auf 1000 kB, also um 90 %. Das belegt keine entsprechende Latenzverbesserung. Gezählt werden nur Antwortinhalte, ohne Anfragen und Header.
| Fiktive Messgröße | Ausgang | Kandidat |
|---|---|---|
| Aufrufe | 100 | 20 |
| Daten je Antwort | 100 kB | 50 kB |
| Gesamtvolumen | 10000 kB | 1000 kB |
| Ablaufdauer | Messen | Messen |
Vor mehr Parallelität Arbeit vermeiden
- Nur benötigte Felder anfordern und die dokumentierte Seitennavigation beachten. Stapel brauchen Grenzen und Behandlung von Teilergebnissen; größere Seiten sind nicht immer schneller.
- Verbindungen und Antworten bei passendem Kontext und zulässiger Aktualität wiederverwenden. Parallelität begrenzen und Serverarbeit sowie Warteschlangen messen.
- Gesamtfrist und Höchstzahl der Versuche festlegen. Vorübergehende Fehler mit zufällig gestreuten Wartezeiten erneut versuchen; Wiederholungen aller Schichten prüfen.
Abgeschlossene Aktionen nicht doppelt ausführen
Ein Client-Timeout belegt keinen Abbruch auf dem Server. Vor erneuter Erstellung oder Zahlung Zustand und zugesicherten Idempotenzmechanismus prüfen. Unter repräsentativer Last Ablaufdauer, Fehler und Datenrichtigkeit vergleichen.
Primärquellen
- IETF RFC 9110 — HTTP Semantics [EN]
- AWS Builders’ Library — Timeouts, retries and backoff with jitter [EN]
Die Verarbeitung einer API-Antwort analysieren.
Eine einzelne GraphQL-Abfrage kann viele nachgelagerte Aufrufe auslösen. Die für den Client sichtbare Latenz kann die Kosten von Resolvern, Listen und durchlaufenen Beziehungen verschleiern.
- Eine Operation vom Client zu nachgelagerten Diensten nachverfolgen.
- Feldkosten und tatsächlich nutzbares Volumen vergleichen.
- Listen und wiederholte Abfragen vor dem Caching begrenzen.
Primärquelle: OWASP — GraphQL Cheat Sheet. Verwandte Methode: den praktischen Leitfaden lesen.
Retry-After: Wartezeit, Budget und Wiederholung
Ausführliche Hinweise stehen in dieser Ausgabe auf Englisch zur Verfügung.
Reducing API calls includes controlling repetition
An API optimisation should count attempts reaching the dependency rather than only requests initiated by the screen.
- Trace SDK and proxy retries under one logical identifier.
- Avoid shortening server instructions merely to fit a budget.
- Verify an uncertain write’s state before creating a new intention.
Explore Retry-After and the retry model →
References reviewed · RFC 9110 · §9.2.2, §10.2.3 · RFC 6585 · §4 · AWS