Egy szolgáltatás percenként 60 API-kérést enged, ezért elsőre gyorsnak tűnik a tízezer rekordos import. Ha közben percenként legfeljebb 2000 rekord fogadható, a nagyobb csomagok csak egy határig segítenek. A két kvótát egyszerre kell figyelembe venni.
Az összes alábbi korlát hipotetikus. Valódi szolgáltatásnál a számlálás egységét, az időablakot és a megosztott keretet a szolgáltató dokumentációjából kell kiolvasni.
Kérés és rekord: két nevező
Jelölje R a megengedett kérésszámot kérés/perc egységben, B az egy kérésbe csomagolt rekordok számát rekord/kérés egységben, D pedig a rekordkvótát rekord/percben.
A kvótákból adódó hosszabb távú kapacitás legfeljebb a R × B és D érték közül a kisebb.
R = 60, B = 100, D = 2000 mellett a kéréskeret 6000 rekord/percet tenne lehetővé, de a rekordkeret 2000 rekord/perc. A tízezer rekordhoz legalább 100, egyenként százrekordos kérés kell. Az egyszerű átlagos kapacitásból számított munkamennyiség 10 000 / 2000 = 5 percnyi kvótakapacitás.
Ez még nem pontos faliórás futási idő. A kvóta időbeli működése külön kérdés: rögzített ablak, gördülő ablak vagy feltöltődő keret eltérő ütemezést engedhet.
Mit jelent öt időablak?
Tegyük fel, hogy a szolgáltatás egymást követő, rögzített percablakokat használ, minden ablak elején teljes új kerettel. A munka az első ablak elején indul, a kérések és a feldolgozás idejét most elhanyagoljuk. Ablakonként húsz százrekordos kérés fogyasztja el a 2000 rekordos keretet.
Öt ilyen ablak kell. A csomagok ideális esetben a 0., 60., 120., 180. és 240. másodperc körül elküldhetők. A munka így nagyjából a 240. másodpercnél érhet a végére ebben az erősen egyszerűsített modellben. Az öt igénybe vett percablak nem jelent automatikusan öt teljes perc várakozást.
Ha a munka az ablak végén indul, más időközök adódhatnak. Ha a keret gördülő, a gyors, ablakhatár körüli küldést másképp korlátozza. A Google Cloud kvótakezelési dokumentációja is megkülönböztet kvótatípusokat; a saját rendszer konkrét szabálya nélkül a futásidő csak becslés.
Kisebb csomagoknál másik korlát lesz szűkebb
Marad a 60 kérés/perc és a 2000 rekord/perc, de egy kérés csak húsz rekordot tartalmaz. A kéréskvótából következő kapacitás 60 × 20 = 1200 rekord/perc. Ez kisebb a rekordkvótánál, így a kérésszám korlátoz előbb.
Tízezer rekordhoz 10 000 / 20 = 500 kérés szükséges. Hatvan kéréses ablakokból felfelé kerekítve kilenc kell. Nyolc teljes ablak 480 kérést, a kilencedik a maradék húszat fogadja. Az előző, ablak elején induló ideális modellben az utolsó csomagok a 480. másodperc körül indulhatnak.
A százrekordos csomagok tehát csökkentik az ablakigényt. A további csomagnövelés a 2000 rekordos percenkénti korláton már nem javít. Külön kérésméret- vagy bájtkorlát is megjelenhet, ezért a rekordok méretét is érdemes mérni.
A tényleges ütem mérhető
A válaszidő és a megengedett párhuzamos kérések száma további korlátot ad. Ha egy kérés átlagosan két másodperc és egyszerre csak egy fut, legfeljebb körülbelül harminc kérés készül el percenként, még akkor is, ha a kvóta hatvanat enged. A több kérést engedő keret nem gyorsítja automatikusan a szerver feldolgozását.
A százalékkalkulátor a kvótakihasználás, az adatmennyiség-átváltó a csomagok méretének ellenőrzéséhez adhat általános segítséget. A számításban a sikeres rekordot, a küldési próbát és a ténylegesen elszámolt kvótaegységet külön kezeld.
Az RFC 6585 a 429-es státuszt a túl sok kérés jelzésére írja le; a válasz várakozási útmutatást is tartalmazhat. A pontos keretfogyasztást a szolgáltató határozza meg. A futásterv hagyjon helyet más klienseknek, ellenőrzéseknek és újrapróbálkozásoknak, ha közös kvótát használnak.
Tudáspróba
1. Mekkora a kvóták szerinti kapacitás 60 kérés/perc, 100 rekord/kérés és 2000 rekord/perc mellett?
- A: 6000 rekord/perc.
- B: 60 rekord/perc.
- C: 2000 rekord/perc.
2. Hány kérés kell tízezer rekordhoz húszrekordos csomagokkal?
- A: 500.
- B: 200.
- C: 50.
3. Mit jelent öt rögzített percablak igénybevétele?
- A: Mindig pontosan öt perc faliórát.
- B: Az időzítés és a feldolgozás ismerete nélkül nem ad pontos futásidőt.
- C: A rekordkvóta figyelmen kívül hagyható.
Megoldások és következő lépés
1. C. A 6000-es kérésből adódó lehetőség és a 2000-es rekordkorlát közül az alacsonyabb érvényesül.
2. A. 10 000 / 20 = 500 kérés.
3. B. Az indulás, az ablakok szabálya és a feldolgozási idő együtt adja a tényleges időt.
0–1 pont: írd minden bemenet mellé a kérés vagy rekord mértékegységet. 2 pont: számold újra a két csomagméret ablakigényét. 3 pont: a saját szolgáltatásod szabályaihoz készíts idővonalat, majd egy kis próbaimporttal ellenőrizd a becsült ütemet.
