Confrontare lo stesso percorso
Esempio fittizio con kilobyte decimali: 100 chiamate da 100 kB contro 20 da 50 kB. Il traffico scende da 10000 a 1000 kB, del 90 %. Non dimostra un’uguale riduzione della latenza. Il calcolo include solo i corpi delle risposte, senza richieste e header.
| Misura fittizia | Iniziale | Candidato |
|---|---|---|
| Chiamate | 100 | 20 |
| Dati per risposta | 100 kB | 50 kB |
| Traffico totale | 10000 kB | 1000 kB |
| Durata del percorso | Da misurare | Da misurare |
Ridurre prima di parallelizzare
- Richiedere solo i campi necessari e seguire la paginazione documentata. I lotti richiedono limiti e gestione degli esiti parziali; pagine maggiori non sono sempre più rapide.
- Riutilizzare connessioni e risposte quando contesto e freschezza lo consentono. Limitare la concorrenza e misurare code e lavoro del server.
- Definire scadenza complessiva e massimo di tentativi. Distanziare i tentativi transitori con una componente casuale e controllare le ripetizioni già presenti nei vari livelli.
Non duplicare azioni completate
Un timeout del client non prova l’annullamento sul server. Prima di ripetere una creazione o un pagamento, verificarne stato e meccanismo di idempotenza previsto. Confrontare durata, errori e correttezza sotto carico rappresentativo.
Fonti primarie
- IETF RFC 9110 — HTTP Semantics [EN]
- AWS Builders’ Library — Timeouts, retries and backoff with jitter [EN]
Ispezionare il lavoro dietro una risposta API.
Una singola query GraphQL può attivare molte chiamate a valle. La latenza visibile al client può nascondere il costo di resolver, liste e relazioni attraversate.
- Tracciare un'operazione dal client ai servizi a valle.
- Confrontare il costo del campo e il volume effettivamente utile.
- Associare liste e query ripetute prima della memorizzazione nella cache.
Fonte primaria: OWASP — GraphQL Cheat Sheet. Metodo correlato: consultare la guida pratica.
Retry-After: attesa, budget e nuovi tentativi
Le note dettagliate di questa edizione sono disponibili in inglese.
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