Kesalahan klasik saat memperbesar parser adalah membeli proxy "secara acak": membeli 100 IP, menjalankan parser, dan mendapatkan banned dalam setengah jam. Masalahnya bukan pada jumlah alamat, tetapi pada kenyataan bahwa tidak ada yang menghitung beban nyata pada setiap IP. Mari kita bahas rumus perhitungan pool proxy yang didasarkan pada RPS (requests per second), delay, dan batasan situs target — dengan angka konkret dan kode dalam Python.
Mengapa menghitung pool berdasarkan jumlah IP adalah kesalahan
Pendekatan tipikal pemula dalam parsing: "perlu mengumpulkan 50.000 kartu produk, jadi kita beli 500 proxy dan sebar beban". Logika ini tampak masuk akal, tetapi tidak mempertimbangkan hal utama — situs seperti Wildberries dan Ozon tidak memblokir berdasarkan jumlah permintaan absolut, tetapi berdasarkan intensitas permintaan dari satu IP dalam satuan waktu. Artinya, 500 proxy, masing-masing mengirimkan 20 permintaan per detik, akan diblokir dengan cepat — sistem anti-bot melihat pola yang mirip dengan DDoS.
Di sisi lain, jika Anda memiliki 50 proxy, tetapi masing-masing melakukan 1 permintaan dalam 5-10 detik dengan jeda acak, meniru perilaku manusia, Anda dapat melakukan parsing secara stabil selama berminggu-minggu tanpa satu pun pemblokiran. Jumlah IP bukanlah penyebab stabilitas, tetapi akibat dari beban yang dihitung dengan benar. Itulah sebabnya rumus harus didasarkan bukan pada "berapa banyak IP yang dibeli", tetapi pada "berapa banyak RPS yang perlu dicapai dan berapa beban aman untuk satu IP".
Satu lagi nuansa: berbagai jenis proxy memiliki "cadangan daya tahan" yang berbeda untuk satu IP. Proxy data center lebih cepat diblokir pada frekuensi permintaan yang tinggi, karena subnet mereka mudah dikenali sebagai hosting. IP residensial dan mobile terlihat seperti pengguna biasa, dan mereka dapat diizinkan sedikit lebih tinggi frekuensinya tanpa risiko pemblokiran — tetapi itu tidak berarti bahwa batasan dapat diabaikan sepenuhnya.
Rumus dasar perhitungan pool proxy
Rumus perhitungan jumlah proxy dalam pool adalah sebagai berikut:
N = (RPS_target × Delay_per_ip) / Concurrency_per_ip
Di mana:
- N — jumlah proxy yang diperlukan dalam pool;
- RPS_target — kecepatan parsing yang ditargetkan (permintaan per detik di seluruh sistem);
- Delay_per_ip — jeda aman minimum antara permintaan dari satu IP (dalam detik);
- Concurrency_per_ip — berapa banyak aliran paralel yang Anda izinkan untuk satu IP (biasanya 1, maksimum 2 untuk proxy residensial).
Logikanya sederhana: jika Anda ingin mempertahankan 10 permintaan per detik secara total, dan jeda aman antara permintaan dari satu IP adalah 8 detik, maka satu IP secara fisik hanya dapat mengeluarkan 1 permintaan dalam 8 detik, yaitu 0.125 RPS. Untuk mendapatkan 10 RPS secara total, Anda memerlukan 10 / 0.125 = 80 proxy. Inilah perhitungan yang menggantikan tebakan "500 IP untuk berjaga-jaga".
Cara menghitung RPS target untuk parsing
Sebelum menghitung pool, Anda perlu menentukan RPS_target — berapa banyak permintaan per detik yang benar-benar Anda butuhkan untuk mengumpulkan data dalam waktu yang wajar. Rumus di sini adalah kebalikannya:
RPS_target = Total_requests / Time_budget_seconds
Contoh: perlu mengumpulkan 100.000 kartu produk dari Wildberries dalam 8 jam (28.800 detik). Jika setiap kartu memerlukan 1 permintaan, RPS_target = 100.000 / 28.800 ≈ 3.47 permintaan per detik. Ini tidak sebanyak yang terlihat pada pandangan pertama — banyak yang melebih-lebihkan kecepatan yang dibutuhkan dan membeli jumlah proxy yang berlebihan.
Jika tugas mencakup beberapa jenis permintaan (misalnya, pertama mendapatkan daftar kategori, kemudian kartu, lalu ulasan), hitung RPS untuk setiap tahap secara terpisah — mereka dapat berjalan secara paralel dengan pool proxy yang berbeda, dan total beban pada platform akan dibagi di berbagai endpoint.
Batasan untuk satu IP: berapa banyak permintaan per menit yang aman
Delay_per_ip adalah parameter terpenting dalam rumus, dan harus ditentukan secara empiris untuk setiap situs. Panduan umum, berdasarkan praktik parsing marketplace:
| Platform | Jeda aman antara permintaan dari 1 IP | Maksimum permintaan/menit dari 1 IP |
|---|---|---|
| Wildberries (API kartu) | 4-6 detik | 10-15 |
| Ozon (halaman produk) | 5-8 detik | 8-12 |
| Avito (iklan) | 6-10 detik | 6-10 |
| Yandex.Market | 5-7 detik | 8-12 |
Angka-angka ini adalah titik awal, bukan dogma. Mulailah dengan nilai konservatif (batas atas jeda), pantau persentase kesalahan 429 dan 403, dan secara bertahap kurangi jeda jika pemblokiran tidak meningkat. Peningkatan RPS yang tiba-tiba tanpa pengujian bertahap adalah cara paling umum untuk membakar seluruh pool proxy dalam satu hari.
Perhitungan praktis: Wildberries, Ozon, Avito
Mari kita bahas tiga skenario nyata dengan perhitungan lengkap menggunakan rumus.
Skenario 1: monitoring harga di Wildberries. Perlu memperbarui harga 20.000 produk setiap 2 jam. RPS_target = 20.000 / (2 × 3600) ≈ 2.78 RPS. Dengan jeda 5 detik per 1 IP dan Concurrency = 1: N = (2.78 × 5) / 1 ≈ 14 proxy. Untuk cadangan jika sebagian IP diblokir, disarankan untuk mengambil pool dengan koefisien 1.5-2x, yaitu 21-28 proxy.
Skenario 2: pengumpulan katalog Ozon sekali. 500.000 kartu dalam 24 jam. RPS_target = 500.000 / 86.400 ≈ 5.79 RPS. Dengan jeda 6 detik: N = (5.79 × 6) / 1 ≈ 35 proxy. Dengan cadangan — 50-60 proxy.
Skenario 3: monitoring pesaing di Avito secara real-time. 5.000 iklan, pembaruan setiap 15 menit. RPS_target = 5.000 / 900 ≈ 5.56 RPS. Dengan jeda 8 detik: N = (5.56 × 8) / 1 ≈ 45 proxy. Di sini penting untuk mempertimbangkan bahwa Avito secara aktif memblokir subnet data center, jadi untuk tugas seperti ini lebih bijaksana untuk langsung menggunakan IP residensial atau mobile.
Proxy residensial, mobile, dan data center dalam rumus
Jenis proxy secara langsung mempengaruhi Delay_per_ip dan, sesuai dengan itu, N akhir dalam rumus. Proxy data center lebih murah dan lebih cepat, tetapi memerlukan jeda yang lebih lama antara permintaan dan lebih sering diblokir pada frekuensi yang tinggi — pada kenyataannya, untuk 5 RPS yang sama, Anda mungkin memerlukan 2-3 kali lebih banyak IP data center dibandingkan dengan residensial.
| Jenis proxy | Rata-rata Delay_per_ip | Kapan digunakan |
|---|---|---|
| Proxy data center | 8-15 detik | API terbuka, situs tanpa anti-bot yang ketat |
| Proxy residensial | 4-8 detik | Wildberries, Ozon, Avito, dan marketplace lainnya dengan anti-bot |
| Proxy mobile | 3-6 detik | Perlindungan paling agresif, media sosial, API mobile |
Untuk parsing marketplace seperti Wildberries dan Ozon, pilihan yang optimal biasanya adalah proxy residensial — mereka menyeimbangkan harga dan stabilitas, memungkinkan jeda yang lebih pendek tanpa peningkatan pemblokiran yang tajam. Proxy data center sebaiknya hanya dipertimbangkan untuk platform tanpa anti-bot yang agresif atau untuk tugas sekali dengan RPS yang rendah.
Implementasi pool dalam Python: kode dengan rotasi
Di bawah ini adalah implementasi sederhana dari pool proxy dengan kontrol frekuensi permintaan untuk setiap IP. Logikanya: setiap proxy menyimpan waktu penggunaan terakhir, dan penjadwal hanya memilih IP yang telah cukup waktu sejak permintaan terakhir.
import time
import random
from dataclasses import dataclass, field
from typing import List, Optional
@dataclass
class ProxyNode:
address: str
delay_per_ip: float # jeda aman dalam detik
last_used: float = field(default=0.0)
class ProxyPool:
def __init__(self, proxies: List[str], delay_per_ip: float):
self.nodes = [ProxyNode(address=p, delay_per_ip=delay_per_ip) for p in proxies]
def get_available_proxy(self) -> Optional[ProxyNode]:
now = time.time()
available = [
node for node in self.nodes
if now - node.last_used >= node.delay_per_ip
]
if not available:
return None
# memilih secara acak dari yang tersedia, untuk menghindari pola antrian
node = random.choice(available)
node.last_used = now
return node
def size(self) -> int:
return len(self.nodes)
def calculate_pool_size(rps_target: float, delay_per_ip: float, concurrency: int = 1) -> int:
"""Rumus: N = (RPS_target * Delay_per_ip) / Concurrency_per_ip"""
return max(1, int((rps_target * delay_per_ip) / concurrency))
# Contoh penggunaan
rps_target = 5.79 # dihitung dari volume tugas dan waktu
delay_per_ip = 6.0 # jeda aman untuk Ozon
n_proxies = calculate_pool_size(rps_target, delay_per_ip)
print(f"Proxy yang dibutuhkan dalam pool: {n_proxies}") # ~35, dengan cadangan 50-60
Dalam parser nyata, logika ini perlu dilengkapi dengan antrean tugas (misalnya, melalui asyncio atau multiprocessing), sehingga pekerja menunggu proxy yang tersedia, bukan berhenti dengan kesalahan saat tidak ada. Juga, perlu menambahkan exponential backoff saat menerima 429/403 — ini secara otomatis akan meningkatkan jeda untuk IP tertentu saat ada tanda pemblokiran.
Monitoring dan koreksi dinamis pool
Perhitungan statis berdasarkan rumus adalah titik awal, bukan solusi akhir. Dalam penggunaan nyata, Anda perlu memantau tiga metrik kunci:
- Success rate — persentase permintaan yang berhasil (kode 200) dari total permintaan. Penurunan di bawah 90-95% menunjukkan bahwa Delay_per_ip perlu ditingkatkan atau menambah proxy dalam pool;
- Ban rate — proporsi proxy yang menunjukkan tanda pemblokiran (captcha, 403, pengalihan ke formulir verifikasi) dalam satu jam terakhir;
- Real RPS — kecepatan pemrosesan permintaan yang sebenarnya, yang mungkin berbeda dari yang dihitung karena timeout dan percobaan ulang.
Aturan praktis: jika ban rate melebihi 5-7% per jam, tingkatkan Delay_per_ip sebesar 20-30% dan hitung kembali N menggunakan rumus. Jika success rate stabil di atas 98% selama beberapa jam, Anda dapat secara bertahap mengurangi jeda dan mengurangi ukuran pool — ini adalah penghematan langsung pada anggaran untuk proxy tanpa kehilangan stabilitas.
Praktik baik adalah mencatat log untuk setiap IP secara terpisah: waktu permintaan terakhir yang berhasil, jumlah kesalahan berturut-turut, waktu respons rata-rata. Ini memungkinkan secara otomatis mengecualikan proxy "rusak" dari rotasi selama 30-60 menit daripada terus mengirim permintaan melalui mereka dan mendapatkan captcha di setiap langkah.
Kesalahan umum saat menghitung pool proxy
Bahkan mengetahui rumus, mudah untuk melakukan kesalahan dalam detail perhitungan. Berikut adalah daftar kesalahan umum:
- Mengabaikan cadangan untuk pemblokiran. Bahkan dengan perhitungan yang sempurna, 5-10% proxy akan sementara tidak tersedia karena pemblokiran atau masalah jaringan. Selalu tambahkan koefisien 1.3-2x ke N dasar;
- Delay_per_ip yang sama untuk semua endpoint. Halaman kategori dan halaman kartu produk mungkin memiliki batasan yang berbeda — hitung secara terpisah;
- Concurrency lebih dari 1 tanpa pengujian. Permintaan paralel dari satu IP secara drastis meningkatkan risiko pemblokiran, terutama pada proxy residensial — mulai dengan Concurrency = 1;
- Kurangnya rotasi User-Agent dan header. Bahkan pool proxy yang dihitung dengan benar tidak akan menyelamatkan jika semua permintaan datang dengan sidik jari browser yang sama;
- Jeda tetap tanpa jitter. Interval yang persis sama antara permintaan (misalnya, tepat 5.0 detik) adalah pola yang mudah dikenali oleh anti-bot. Tambahkan deviasi acak ±20-30%.
Kesimpulan
Rumus N = (RPS_target × Delay_per_ip) / Concurrency_per_ip mengubah perhitungan pool proxy dari tebakan menjadi tugas rekayasa dengan angka konkret. Pertama, tentukan kecepatan parsing target berdasarkan volume data dan waktu, kemudian secara empiris temukan jeda aman untuk platform tertentu, dan hanya setelah itu hitung jumlah IP yang diperlukan — dengan cadangan 30-100% untuk pemblokiran dan gangguan.
Pendekatan ini menghemat anggaran: daripada membeli jumlah IP yang berlebihan "untuk berjaga-jaga", Anda membayar tepat untuk jumlah proxy yang diperlukan untuk mencapai RPS target tanpa risiko pemblokiran. Untuk parsing marketplace dan situs lain yang dilindungi, kami merekomendasikan untuk mulai dengan proxy residensial — mereka memberikan keseimbangan terbaik antara stabilitas dan biaya saat bekerja dengan sistem anti-bot Wildberries, Ozon, dan Avito.