Przykład 1
- limit 60
- jednostka na minutę
- okno 15 min
900
Ile zapytań w oknie przy 60 na minutę i 15 min? 900. Średnie RPM razy okno, nie token bucket.
Kalkulator limitów API (rate limit)
Wpisz limit, jednostkę i okno. 60 na minutę i 15 min dają 900. 10 na sekundę i 1 min dają 600. 3600 na godzinę i 60 min dają 3600. Średnie tempo, nie kubełek tokenów.
To średnie RPM razy okno, nie token bucket. Backoff po 429 jest na backoffie wykładniczym.
Wynik
Wprowadź dane i kliknij Oblicz.
Jak to działa?
Kalkulator limitów API (rate limit) na tej karcie liczy zapytania w oknie ze średniego RPM. 60 na minutę i 15 min dają 900. 10 na sekundę i 1 min dają 600. 3600 na godzinę i 60 min dają 3600. To średnia, nie kubełek tokenów i nie Retry-After.
Pole limitu jest liczbą. Jednostka rate-limit-unit to min, sec albo hour. Okno jest w minutach. Z min RPM zostaje wpis. Z sec karta mnoży przez 60. Z hour dzieli przez 60. Potem RPM razy okno.
900 to 60 razy 15. 600 to 10 razy 60 razy 1. 3600 to 3600 przez 60, potem razy 60. Inna jednostka przy tym samym 60 zmienia wynik. Karta nie czyta nagłówka 429.
Backoff wykładniczy obok liczy przerwę po błędzie. Koszt na request mnoży cenę przez wolumen. Tu zostaje średnie tempo: 60 i 15 min zostają 900 zapytań w oknie.
Wpisz 60, wybierz na minutę, okno 15, potem Oblicz. Przecinek w 60,5 działa. Zero w limicie albo oknie to błąd pól, nie kubełek. To szkic średniej, nie live API.
60 na minutę i 15 min dają 900. 10 na sekundę i 1 min dają 600. 3600 na godzinę i 60 min dają 3600. Inne okno przy 60 zmienia 900.
Wzór
zapytania w oknie = RPM × okno (min). RPM = limit (min), limit × 60 (sec) albo limit / 60 (hour).
Jak korzystać
- Wpisz limit, na przykład 60.
- Wybierz jednostkę na minutę. Wpisz okno 15.
- Kliknij Oblicz. Wynik to 900 zapytań w oknie.
- 10 na sekundę i 1 min dają 600. 3600 na godzinę i 60 min dają 3600.
- To średnie RPM razy okno, nie token bucket.
60 na minutę i 15 min = 900
Średnie RPM razy okno. 60 na minutę i 15 min dają 900. To nie token bucket.
- rate limit
- Wpisany limit. 60 na minutę przy oknie 15 zostawia 900.
- okno
- Minuty w polu okna. 15 przy 60 na minutę daje 900 zapytań.
- zapytań
- Wynik w oknie. 10 na sekundę i 1 min dają 600 zapytań.
Przykłady
Przykład 2
- limit 10
- jednostka na sekundę
- okno 1 min
600
Ile przy 10 na sekundę i 1 min? 600. 10 × 60 RPM × 1.
Przykład 3
- limit 3600
- jednostka na godzinę
- okno 60 min
3600
Ile przy 3600 na godzinę i 60 min? 3600. Godzina sprowadzona do RPM.
Powiązane kalkulatory
Najczęstsze pytania
Ile zapytań przy 60 na minutę i 15 min?
900. 60 RPM razy 15 minut. Średnia, nie kubełek tokenów.
Ile przy 10 na sekundę i 1 min?
600. 10 × 60 daje 600 RPM, razy okno 1.
Ile przy 3600 na godzinę i 60 min?
3600. 3600 / 60 to 60 RPM, razy 60 minut.
Czy 900 to token bucket?
Nie. Karta mnoży średnie RPM przez okno. Burst z kubełka tu nie schodzi.
Czy karta czyta Retry-After?
Nie. Wpisujesz limit i okno sam. Nie ma live API.
Co zmienia jednostka?
min zostawia RPM. sec mnoży przez 60. hour dzieli przez 60. Potem razy okno.
Czy przecinek w 60,5 działa?
Tak. 60,5 i 60.5 karta czyta tak samo.
Gdzie liczysz backoff po 429?
Na backoffie wykładniczym. Tu zostaje liczba zapytań w oknie.
Czy zero w oknie liczy?
Nie. Limit i okno muszą być dodatnie. To nie puste wiadro tokenów.
Co to jest rate limiting
Rate limiting to ograniczenie liczby żądań, które klient (użytkownik, IP, klucz API) może wysłać w danym oknie czasu. Chroni backend przed przeciążeniem, zapewnia sprawiedliwy podział zasobów między klientów i jest standardowym elementem publicznych API — przekroczenie limitu zwykle skutkuje odpowiedzią HTTP 429 Too Many Requests.
Algorytmy: token bucket, sliding window
- Fixed window (okno stałe) — licznik resetuje się na początku każdego okna (np. co minutę); prosty, ale pozwala na "wybuch" 2× limitu na granicy dwóch okien.
- Sliding window (okno przesuwne) — liczy żądania w ostatnich N sekundach niezależnie od granic zegarowych; bardziej sprawiedliwy, ale wymaga więcej pamięci na historię.
- Token bucket — "wiadro" wypełnia się tokenami w stałym tempie; każde żądanie zużywa token. Pozwala na krótkie wybuchy (burst) do rozmiaru wiadra, przy zachowaniu średniego tempa w czasie.
Wzory: RPS, RPM, interwał
Kalkulator normalizuje podany limit do RPM (zapytań na minutę), potem liczy: RPS = RPM / 60, Zapytania w oknie = RPM × długość okna (min), Minimalny odstęp = 60 / RPM sekund. To średnie tempo — token bucket i podobne polityki mogą pozwalać na krótkie odchylenia od tej średniej.
Nagłówki HTTP i kod 429
Dobrze zaprojektowane API informuje klienta o stanie limitu przez nagłówki, np. X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset oraz Retry-After w odpowiedzi 429 — mówiąc dokładnie, ile trzeba czekać przed kolejną próbą. Klienci powinni respektować te nagłówki i stosować backoff (najlepiej z jitterem), nie ślepe ponawianie.
Projektowanie limitów: burst vs sustained
- Limit "sustained" (średni w długim oknie) chroni backend w długim terminie, ale bywa za sztywny dla naturalnych wybuchów ruchu (np. odświeżenie strony wywołujące kilka zapytań naraz).
- Wiele API kombinuje dwa limity: krótkookresowy (np. 10/s) na wybuchy i długookresowy (np. 10000/dzień) na łączne zużycie zasobów.
- Ustalając limit dla własnego API, licz od realnych wzorców użycia klientów, nie tylko od pojemności infrastruktury — zbyt restrykcyjny limit frustruje uczciwych użytkowników.
Przykłady
- Gateway 1000 req / 15 min (publiczne API) → RPM = 1000, RPS ≈ 16,67, min. odstęp ≈ 0,06 s — klient potrzebuje kolejki, nie „ślepych” retry.
- 5 req/s sustained, okno 1 min → 300 w oknie, RPM = 300 — typowy limit webhooków / partner API.
- 10 000 req / godzinę (plan SaaS) → RPM ≈ 166,67, odstęp ≈ 0,36 s — spokojniejsze pacing; nadal respektuj Retry-After.
FAQ — limity API
- Co to jest rate limiting w kilku słowach?
- Ograniczenie liczby żądań na jednostkę czasu dla danego klienta — chroni serwer i zapewnia sprawiedliwy podział zasobów.
- Czym różni się token bucket od stałego okna?
- Stałe okno resetuje licznik na granicy czasowej (możliwy wybuch na styku okien). Token bucket pozwala na kontrolowany burst do rozmiaru wiadra, zachowując średnie tempo w dłuższym czasie.
- Co to jest "burst" i jak wpływa na retry?
- Burst to krótki skok powyżej średniego tempa (np. odświeżenie strony). Sustained limit chroni długookresowo; burst limity dopuszczają chwilowe piki. Po HTTP 429 stosuj Retry-After lub exponential backoff z jitterem — ślepe retry pogłębia przeciążenie i zużywa limit.
- Jak reagować na odpowiedź 429?
- Odczekać czas z nagłówka Retry-After (jeśli obecny) i ponowić żądanie z exponential backoff plus jitter — nigdy ślepo ponawiać natychmiast, bo to pogłębia przeciążenie.
- Limitować per IP czy per klucz API?
- Zależy od modelu — per klucz API jest precyzyjniejsze dla autoryzowanych klientów, per IP chroni przed anonimowym ruchem, ale zawodzi za NAT-em (wielu użytkowników dzieli jeden adres).
- Czy ten kalkulator liczy realne burst limity?
- Nie — liczy tylko średnie tempo (RPM/RPS/interwał) do pacingu klienta. Token bucket może chwilowo przekroczyć średnią o rozmiar „wiadra”; po 429 użyj Retry-After / backoff.
- Jakie limity mają popularne API?
- Bardzo różne — od kilku zapytań na sekundę (płatne API AI) do tysięcy na minutę (duże platformy). Zawsze sprawdź dokumentację konkretnego dostawcy, bo limity zmieniają się z planem cenowym.
- Jak długość okna wpływa na odczuwany limit?
- Krótsze okno (np. 1 sekunda) wymusza bardziej równomierny ruch. Dłuższe okno (np. 1 dzień) daje więcej swobody na wybuchy, ale mniej ochrony przed chwilowym przeciążeniem.