Vertaa samaa käyttötapausta
Kuvitteellinen esimerkki desimaalisilla kilotavuilla: ensin 100 kutsua ja 100 kB vastausta kohti, sitten 20 kutsua ja 50 kB. Siirto laskee 10000:sta 1000 kB:uun eli 90 %. Viiveen vastaavaa laskua tämä ei osoita. Mukana ovat vain vastaussisällöt, eivät pyynnöt tai otsakkeet.
| Kuvitteellinen mittari | Alkuperäinen | Ehdokas |
|---|---|---|
| Kutsut | 100 | 20 |
| Tietoa vastausta kohti | 100 kB | 50 kB |
| Kokonaismäärä | 10000 kB | 1000 kB |
| Käyttötapauksen kesto | Mitattava | Mitattava |
Vähennä ennen rinnakkaistamista
- Pyydä vain tarvittavat kentät ja noudata sivutussopimusta. Eräkutsut tarvitsevat rajat ja osittaisten tulosten käsittelyn; suurempi sivu ei aina ole nopeampi.
- Käytä yhteyksiä ja vastauksia uudelleen asiayhteyden ja tuoreusvaatimusten salliessa. Rajaa rinnakkaisuus ja mittaa palvelintyö sekä jonot.
- Määritä kokonaisaikaraja ja yritysten enimmäismäärä. Hajauta tilapäisten virheiden uusinnat satunnaisella odotuksella ja tarkista eri kerrosten uusinnat.
Älä suorita valmista toimintoa uudelleen
Asiakkaan aikakatkaisu ei osoita palvelimen peruutusta. Tarkista tila ja toimittajan idempotenssikäytäntö ennen luonnin tai maksun uusintaa. Vertaa kestoa, virheitä ja oikeellisuutta edustavalla kuormalla.
Alkuperäiset lähteet
- IETF RFC 9110 — HTTP Semantics [EN]
- AWS Builders’ Library — Timeouts, retries and backoff with jitter [EN]
Tarkastele yhden API-vastauksen taustalla olevaa työtä.
Yksi GraphQL-kysely voi laukaista useita alavirran kutsuja. Asiakkaan näkyvä latenssi voi piilottaa resolvereiden, listojen ja läpikäytyjen suhteiden kustannukset.
- Jäljitä toiminto asiakkaalta alavirran palveluihin.
- Vertaa kentän kustannuksia ja todellista hyödyllistä volyymia.
- Sidotut listat ja toistuvat kyselyt ennen välimuistiin tallentamista.
Ensisijainen lähde: OWASP — GraphQL Cheat Sheet. Aiheeseen liittyvä menetelmä: lue käytännön opas.
Retry-After: odotus, budjetti ja uusintapäätös
Tämän kieliversion tarkemmat lähdekuvaukset ovat englanniksi.
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