Apa Sebenarnya Arti Cara Menghitung Batas Kecepatan API?
Jika Anda mencari cara menghitung batas kecepatan API, inilah jawaban langsungnya: Anda harus menjalankan dua perhitungan yang berbeda. Pertama, jika Anda mengoperasikan API, turunkan batas permintaan per detik (RPS) yang berkelanjutan dari metrik lalu lintas bisnis seperti pengguna aktif harian (DAU) dan faktor lonjakan puncak. Kedua, jika Anda menggunakan API pihak ketiga, hitung interval pengaturan kecepatan sisi klien yang menjaga tingkat permintaan Anda tetap di bawah batas yang dipublikasikan. Batas kecepatan API adalah jumlah maksimum permintaan yang diizinkan dalam jendela berjalan—biasanya per detik, menit, atau jam. Frasa varian batas peringkat API yang muncul di beberapa log pencarian hanyalah salah ketik untuk mekanisme yang sama; tidak ada metrik kualitas peringkat terpisah dalam standar HTTP.
Kebanyakan panduan yang ada menunjukkan header X-RateLimit-Limit dan berhenti di situ. Itu memberi tahu Anda bahwa batas itu ada, bukan cara menghitungnya secara matematis. Ketika saya membangun proxy multi-penyewa pertama saya pada tahun 2018, saya menyalin pengaturan 1.000 permintaan/menit dari pesaing. Enam minggu kemudian, lonjakan lalu lintas mengungkapkan bahwa backend kami hanya mampu menangani 400 permintaan/menit, dan batas yang dikodekan keras itu memberi rasa aman yang palsu. Metodologi di bawah ini adalah yang saya harap saya miliki: persamaan nyata, bukan tebakan.
Cara Menemukan Batas Kecepatan API yang Anda Andalkan
Menemukan batas API eksternal adalah langkah nol untuk perhitungan sisi klien. Cara terbersih adalah membaca header X-RateLimit-Limit, X-RateLimit-Remaining, dan X-RateLimit-Reset pada setiap respons. Status 429 dan header ini diformalkan dalam RFC 6585. Misalnya, REST API GitHub mempublikasikan batas terautentikasi 5.000 permintaan/jam di dokumentasi resmi mereka.
Tetapi header bukanlah kebenaran mutlak. Dalam sistem terdistribusi, header sering dihitung pada node dengan penghitung yang basi. Hal yang tidak diberitahukan siapa pun: penyedia dapat memberlakukan kuota per-IP, per-token, atau per-region yang tidak diungkapkan oleh header. Saya pernah menggunakan API logistik di mana header mengatakan sisa 999, tetapi saya mendapat 429 karena batas sebenarnya adalah per-IP dan penyeimbang beban saya memutar IP. Selalu gabungkan pemeriksaan header dengan uji coba terkontrol: naikkan permintaan dari satu klien dengan kenaikan 10% sampai Anda melihat 429, lalu mundur 20%.
Batas REST vs GraphQL dan WebSocket
Endpoint REST biasanya mengekspos batas per-rute yang jelas. Gateway GraphQL sering memberlakukan skor kompleksitas daripada jumlah permintaan mentah—batas kecepatan Anda menjadi anggaran poin, misalnya, 1.000 poin/menit di mana kueri bersarang memakan biaya 15. WebSocket mungkin memiliki batas kecepatan pesan (misalnya, 30 pesan/detik) yang diukur pada tingkat bingkai, bukan header HTTP. Dalam semua kasus, metode penemuan sama: baca dokumen, periksa respons, lalu uji coba.
Prosedur Uji Coba Manual yang Aman
- Mulai dengan 1 permintaan setiap 5 detik dari satu IP.
- Kurangi interval sebesar 10% setiap 2 menit sambil mencatat kode status.
- Saat 429 muncul, catat jumlah permintaan dan stempel waktu.
- Mundur ke 80% dari tingkat itu dan konfirmasi stabilitas selama 10 menit.
Ini memberi Anda angka yang sebenarnya ditegakkan, yang kemudian Anda gunakan dalam rumus pengaturan kecepatan nanti. curl -i https://api.example.com/v1/ping yang cepat dan grep untuk header RateLimit sudah cukup untuk memulai dasar sebelum kenaikan.
Persamaan Metrik Bisnis ke RPS: Menentukan Ukuran Batas API Anda Sendiri
Untuk menghitung batas untuk layanan Anda sendiri, mulailah dengan analitik produk. Rumus dasarnya adalah:
RPS_base = (DAU × rata-rata_panggilan_per_pengguna_per_hari) / 86400
Ini menghasilkan rata-rata permintaan per detik. Tetapi rata-rata menyembunyikan lonjakan. Kalikan dengan faktor puncak P (3–5× untuk aplikasi konsumen, 1,5–2× untuk B2B) untuk mendapatkan RPS_peak = RPS_base × P. Atur tingkat pengisian ulang token bucket Anda ke RPS_peak × 1,2 untuk margin keamanan.
Ketika saya pertama kali mencoba ini di fintech, saya keliru menggunakan MAU (2 juta) alih-alih DAU (120 ribu). Perhitungan MAU menyiratkan 230 RPS yang dibutuhkan; rata-rata berbasis DAU yang sebenarnya adalah 14 RPS dengan puncak 60 RPS. Ukuran yang terlalu besar berarti kami menyediakan kluster Redis yang tidak perlu, membuang sekitar $400 per bulan. Gunakan jendela aktif yang cocok dengan ritme permintaan—DAU untuk aplikasi penggunaan harian, jumlah sesi untuk sistem berbasis peristiwa.
Mengonversi MAU ke DAU dengan Faktor Retensi
Jika Anda hanya memiliki pengguna aktif bulanan, perkirakan DAU melalui DAU ≈ MAU × DAI di mana DAI adalah indeks aktif harian (0,05–0,3 untuk kebanyakan SaaS). Untuk produk 2 juta MAU dengan DAI 10%, DAU = 200 ribu. Kemudian lanjutkan dengan rumus dasar. Ini mencegah kesalahan yang saya buat. Validasi DAI dengan analitik; jangan berasumsi.
Trade-off Biaya Ukuran Berlebih dan Kurang
Atur batas terlalu rendah dan pengguna yang sah akan terkena 429, meningkatkan tiket dukungan. Atur terlalu tinggi dan kumpulan koneksi database atau CPU Anda menjadi hambatan sebenarnya, menyebabkan 500. Saya melacak aturan sederhana: batas kecepatan harus 20% di bawah throughput maksimum terverifikasi infrastruktur dari uji beban. 20% itu adalah margin pemutus sirkuit Anda.
Hukum Little untuk API Berbasis Antrian
Jika API Anda mengantrekan pekerjaan, terapkan Hukum Little L = λ × W (item dalam sistem = tingkat kedatangan × waktu pemrosesan). Jika memproses permintaan membutuhkan 200ms, dan Anda mengizinkan 100 konkuren, kedatangan aman maksimum λ = 100 / 0,2 = 500 RPS. Batas kecepatan Anda harus ≤ 500 dikurangi margin. Ini menghubungkan matematika batas dengan realitas latensi.
Memilih Algoritma Pembatas: Token Bucket, Leaky Bucket, atau Window
Token bucket memiliki dua angka: tingkat pengisian ulang (token/detik) dan kapasitas lonjakan (token maksimum). Jika RPS_peak = 50, atur pengisian ulang = 60. Kapasitas lonjakan harus mencakup batch klien sah terbesar—misalnya 200 permintaan dalam 2 detik—jadi lonjakan = 200. Perbandingan di bawah ini menunjukkan kapan setiap algoritma cocok:
| Algoritma | Terbaik Saat | Kompleksitas Matematika | Biaya Memori |
|---|---|---|---|
| Token Bucket | Lalu lintas melonjak tetapi rata-rata terbatas | Sedang | Rendah |
| Leaky Bucket | Output konstan yang ketat diperlukan | Rendah | Rendah |
| Fixed Window | Kuota sederhana, tanpa kontrol lonjakan | Sangat Rendah | Rendah |
| Sliding Window Log | Akurat di dekat batas, presisi tinggi | Tinggi | Tinggi |
Untuk 90% API, token bucket adalah pilihan yang tepat. Leaky bucket untuk perataan hilir; fixed window untuk kuota penagihan; sliding log untuk akurasi tingkat kepatuhan di mana biaya tidak relevan.
Pengaturan Kecepatan Sisi Klien: Rumus Interval Tidur untuk Menghindari 429
Saat Anda menggunakan API pihak ketiga dengan batas yang diketahui (misalnya, 1.200 permintaan/jam dari contoh header umum), hitung interval pengaturan kecepatan. Rumus naif: interval = 3600 / batas. Untuk 1.200/jam itu 3,0 detik. Tambahkan buffer 10% untuk jitter: interval_buffer = (3600 / batas) × 1,1 = 3,3 detik. Terapkan token bucket lokal: ukuran bucket = batas, pengisian ulang = batas/jendela, dan hanya kirim saat token ≥ 1.
Kesalahpahaman bahwa tidur interval yang tepat aman mengabaikan konkurensi. Jika 4 utas pekerja berbagi bucket, masing-masing harus menggunakan interval_per_pekerja = interval_buffer / konkurensi. Dalam proyek sinkronisasi CRM 2022 yang dibatasi 100 permintaan/menit, kami lupa membagi; empat utas tidur 0,6 detik masing-masing, efektif 400 permintaan/menit, dan diblokir IP selama 30 menit, menunda 8 impor perusahaan. Hitung pengaturan kecepatan per pekerja, bukan per proses.
Pseudo-Code Token Bucket Klien
Implementasi minimal dalam bahasa apa pun mengikuti: inisialisasi tokens = limit, last = now(). Sebelum setiap permintaan: delta = (now-last)/window × limit; tokens = min(limit, tokens+delta); last = now; if tokens≥1: tokens--; send; else: sleep( (1-delta)/refill ). Ini menjamin Anda tidak pernah melebihi batas remote bahkan dengan jitter.
Mengelola Beberapa API dengan Batas Berbeda
Sistem nyata memanggil puluhan API. Pertahankan peta konfigurasi batas dan penjadwal bersama. Gunakan antrian adil berbobot sehingga satu batas ketat (misalnya, 10 req/menit API pembayaran) tidak membuat yang longgar (5.000/jam API pencarian) kelaparan. Saya menggunakan bucket prioritas dengan pengisian ulang per-layanan; matematikanya hanyalah bucket token independen yang berbagi kumpulan thread.
Perhitungan Lanjutan: Batas Laju untuk Webhook dan Streaming
Webhook membalik model: Anda adalah penerima, tetapi pengirim dapat membanjiri Anda. Hitung batas ingest Anda dengan max_webhook_RPS = consumer_throughput × 0.8. Jika pekerja Anda memproses 50 msg/detik, tetapkan batas terima 40 RPS dan kembalikan 429 ke pengirim (sebagian besar mencoba lagi dengan backoff). Untuk streaming (SSE/Kafka), batasi berdasarkan byte/detik: byte_rate = (avg_payload × RPS) × 1.2. Pantau itu, bukan hanya jumlah permintaan.
Contoh Kerja: Menentukan Ukuran API Publik untuk 500k DAU
Asumsikan aplikasi sosial dengan 500k DAU, setiap pengguna membuat 40 panggilan API/hari. RPS dasar = (500.000 × 40)/86400 = 231,5. Faktor puncak 4× = 926 RPS. Pengisian ulang = 1111, burst = 1500 (mencakup peristiwa viral). Jendela batas 60 detik: efektif ~66k/menit. Validasi dengan uji beban.
Di sisi klien, jika tim yang sama mengonsumsi API pencarian yang dibatasi 10.000 permintaan/hari, interval = 86400/10000 ×1,1 = 9,5 detik per permintaan. Dengan 5 pekerja bersamaan, interval per-pekerja = 1,9 detik. Bucket token lokal berukuran 10000 yang diisi ulang pada 0,116 token/detik memberlakukannya secara global di seluruh proses.
Kasus Tepi: Skew Jam, Penghitung Terdistribusi, dan Throttling Senyap
Kebanyakan orang tidak menyadari bahwa pembatasan laju di seluruh cluster global menggunakan penghitung perkiraan. Jika API Anda berjalan di dua wilayah, batasnya mungkin per-wilayah, bukan global. Saya belajar ini ketika cluster UE menunjukkan 500 token tersisa sementara AS memiliki 0; penyeimbang beban menjumlahkan secara salah dan membiarkan UE membebani database bersama. Selalu tanyakan: apakah batasnya per-node, per-wilayah, atau global?
Kasus tepi lain: X-RateLimit-Remaining bisa tetap di 0 selama satu detik ekstra karena jeda GC, atau menjadi negatif di middleware kustom. Perlakukan nilai apa pun ≤ 1 sebagai berhenti. Juga, dokumen lama kadang menyebut batas peringkat API; itu sama dengan batas laju, abaikan frasa tersebut. Throttling senyap—di mana API mengembalikan 200 tetapi menjatuhkan pekerjaan latar belakang—lebih buruk daripada 429; instrumentasi histogram latensi untuk menangkapnya.
Inkonsistensi CDN dan Gateway
Cloudflare, AWS API Gateway, dan NGINX masing-masing menghitung batas secara berbeda. Cloudflare menggunakan jendela bergulir per node tepi; API Gateway menggunakan token bucket per tahap; NGINX limit_req menggunakan leaky bucket. Jika Anda menumpuknya, batas efektif adalah tautan rantai paling ketat. Saya pernah melihat aplikasi 100 RPS di belakang Cloudflare 200 RPS dan NGINX 50 RPS sebenarnya dibatasi pada 50. Petakan rantai secara matematis: effective = min(all layer limits).
Kesalahpahaman Umum Tentang Perhitungan Batas Laju API
Kesalahpahaman 1: Header memberi tahu kapasitas tersisa yang tepat. Salah—itu adalah snapshot dengan jeda hingga 1 detik. Kesalahpahaman 2: Batas laju adalah fitur keamanan. Ini terutama pelindung kapasitas; keamanan (anti-penyalahgunaan) membutuhkan WAF dan auth. Kesalahpahaman 3: Batas peringkat API adalah faktor peringkat Google. Tidak, itu salah ketik. Kesalahpahaman 4: API tanpa batas ada. Mereka selalu memiliki batas infrastruktur implisit; tanpa batas adalah pemasaran.
Pemantauan dan Peringatan pada Kesehatan Batas Laju
Lacak metrik: rasio 429, waktu deplesi token, penyimpangan header tersisa. Gunakan Prometheus atau Datadog. Beri peringatan jika 429 melebihi 1% lalu lintas selama 5 menit. Dalam insiden 2023, kami melewatkan throttle senyap karena hanya melihat kode kesalahan, bukan latensi; p99 melonjak dari 120ms ke 2s sebelum ada yang menyadari. Sekarang kami memberi peringatan pada keduanya.
Apa yang Harus Dilakukan Saat Anda Melebihi Batas yang Dihitung
Jika Anda melebihi, terapkan degradasi anggun: buang permintaan non-kritis, kembalikan 429 dengan Retry-After, antrekan pekerjaan latar belakang. Jangan hanya menaikkan batas secara membabi buta; periksa CPU DB dulu. Saya pernah menggandakan batas untuk menghentikan 429, hanya untuk memicu 500 karena kumpulan koneksi adalah langit-langit sebenarnya. Skalakan infrastruktur, lalu tinjau matematika.
Memvalidasi Perhitungan Anda dengan Uji Beban dan Alat
Matematika adalah hipotesis; produksi adalah vonis. Setelah menurunkan angka, masukkan ke Kalkulator Batas Laju API kami untuk mengonfirmasi ukuran bucket dan interval pacing. Kemudian uji beban pada faktor puncak × 1,5 selama 10 menit. Perhatikan persentil ke-99, bukan rata-rata, untuk 429.
Dalam satu keterlibatan, kalkulasi kami mengatakan batas 80 RPS tetapi tes menunjukkan 429 pada 72 RPS karena kumpulan koneksi DB jenuh sebelum limiter. Pembatasan laju membentuk lalu lintas tepi; itu tidak dapat menutupi hambatan backend. Jujurlah tentang trade-off itu saat menyajikan batas kepada pemangku kepentingan.
Uji Kekacauan pada Limiter Anda
Perkenalkan latensi buatan dan matikan node di tengah burst. Apakah cluster yang tersisa masih menegakkan batas global? Jika menggunakan Redis, matikan master dan lihat apakah penghitung menjadi basi. Matematika hanya berlaku jika implementasinya tangguh. Dokumentasikan mode kegagalan ini.
Daftar Periksa Langkah-demi-Langkah: Hitung Batas API Apa Pun dalam 15 Menit
- Identifikasi sisi Anda: penyedia (tetapkan batas) atau konsumen (hormati batas).
- Kumpulkan DAU dan rata-rata panggilan/pengguna/hari; abaikan MAU kecuali penggunaan harian datar.
- Hitung RPS_base, terapkan faktor puncak 3–5× (konsumen) atau 1,5–2× (B2B).
- Pilih token bucket; tetapkan pengisian ulang = RPS_peak × 1,2, burst = batch terbesar.
- Untuk pihak ketiga: interval = (window/limit)×1,1 / konkurensi; implementasikan bucket lokal.
- Periksa header dan dokumen untuk mengonfirmasi batas eksternal; jalankan k6 bertahap jika senyap.
- Uji beban pada 1,5× puncak; sesuaikan bucket jika 429 muncul sebelum batas teoretis.
Ikuti itu dan Anda akan memiliki batas yang dapat dipertahankan dan didukung matematika daripada angka yang disalin. Lain kali seseorang bertanya cara menghitung batas laju API, Anda dapat memberikan persamaan ini kepada mereka.