Parser'ı ölçeklendirirken yapılan klasik hata — proxy'leri "göz kararı" almak: 100 IP aldık, parser'ı başlattık, yarım saat içinde yasaklandık. Sorun, adres sayısında değil, her IP üzerindeki gerçek yükü kimsenin hesaplamamasında. RPS (saniye başına istek), gecikmeler ve hedef sitenin limitlerine dayanan proxy havuzunun hesaplama formülünü inceleyelim — somut rakamlar ve Python kodu ile.
Neden havuzu IP sayısına göre hesaplamak bir hatadır
Parsing'deki tipik bir yeni başlayan yaklaşımı: "50.000 ürün kartı toplamalıyız, bu yüzden 500 proxy alalım ve yükü dağıtalım". Mantık makul görünüyor, ancak en önemli şeyi göz ardı ediyor — Wildberries ve Ozon gibi siteler, isteklerin mutlak sayısına göre yasaklamaz, bir IP'den gelen isteklerin yoğunluğuna göre yasaklar. Yani, her biri saniyede 20 istek atan 500 proxy anında yasaklanır — anti-bot sistemleri DDoS'a benzer bir kalıp görür.
Öte yandan, eğer 50 proxy'niz varsa, ancak her biri 5-10 saniyede bir rastgele aralıklarla 1 istek yapıyorsa, insan davranışını taklit ederek, haftalarca tek bir yasak almadan parsing yapabilirsiniz. IP sayısı, istikrarın nedeni değil, doğru hesaplanmış yükün sonucudur. Bu nedenle, formül "kaç IP almalı" yerine "kaç RPS'ye ulaşmalıyım ve bir IP için güvenli yük ne" üzerinden hesaplanmalıdır.
Bir diğer nokta: farklı proxy türleri, bir IP için farklı "dayanıklılık" seviyelerine sahiptir. Veri merkezi proxy'leri yüksek istek sıklığında daha hızlı yasaklanır, çünkü alt ağları kolayca barındırma hizmeti olarak tanınır. Konut ve mobil IP'ler, normal kullanıcılar gibi görünür ve biraz daha yüksek bir sıklığa izin verilebilir — ancak bu, limitlerin tamamen göz ardı edilebileceği anlamına gelmez.
Proxy havuzunun hesaplanması için temel formül
Proxy havuzundaki proxy sayısının hesaplama formülü şöyle görünür:
N = (RPS_target × Delay_per_ip) / Concurrency_per_ip
Burada:
- N — havuzdaki gerekli proxy sayısı;
- RPS_target — hedef parsing hızı (sistem genelinde saniyede istek sayısı);
- Delay_per_ip — bir IP'den gelen istekler arasındaki minimum güvenli bekleme süresi (saniye cinsinden);
- Concurrency_per_ip — bir IP için kaç paralel akışa izin veriyorsunuz (genellikle 1, konut proxy'leri için maksimum 2).
Mantık basit: eğer toplamda 10 istek/saniye tutmak istiyorsanız ve bir IP'den gelen istekler arasındaki güvenli bekleme süresi 8 saniye ise, bir IP fiziksel olarak sadece 8 saniyede 1 istek verebilir, yani 0.125 RPS. Toplamda 10 RPS elde etmek için 10 / 0.125 = 80 proxy gerekir. İşte bu, "her ihtimale karşı 500 IP" tahminini değiştiren hesaplamadır.
Parsing için hedef RPS nasıl hesaplanır
Havuzun hesaplanmasından önce RPS_target'ı belirlemek gerekir — verileri makul bir sürede toplamak için gerçekten ne kadar istek/saniye gerektiğini. Burada formül tersidir:
RPS_target = Total_requests / Time_budget_seconds
Örnek: Wildberries'den 8 saat içinde 100.000 ürün kartı toplamak gerekiyor (28.800 saniye). Her ürün kartı için 1 istek gerekiyorsa, RPS_target = 100.000 / 28.800 ≈ 3.47 istek/saniye. İlk bakışta bu kadar fazla değil — birçok kişi gereken hızı abartır ve fazla sayıda proxy satın alır.
Eğer görev birden fazla istek türünü içeriyorsa (örneğin, önce kategori listesini almak, sonra ürün kartlarını, sonra yorumları), her aşama için RPS'yi ayrı ayrı hesaplayın — bunlar farklı proxy havuzları ile paralel gidebilir ve toplam yük, farklı uç noktalara dağıtılacaktır.
Bir IP için limitler: dakikada kaç istek güvenlidir
Delay_per_ip — formüldeki en önemli parametre ve her site için ampirik olarak belirlenmelidir. Marketplace'lerdeki parsing pratiğine dayanan genel kılavuzlar:
| Platform | 1 IP'den gelen istekler arasındaki güvenli bekleme süresi | 1 IP ile maksimum istek/dakika |
|---|---|---|
| Wildberries (Ürün kartları API'si) | 4-6 saniye | 10-15 |
| Ozon (Ürün sayfaları) | 5-8 saniye | 8-12 |
| Avito (İlanlar) | 6-10 saniye | 6-10 |
| Yandex.Market | 5-7 saniye | 8-12 |
Bu rakamlar başlangıç noktasıdır, kesin bir kural değildir. Koruyucu değerlerden (bekleme süresinin üst sınırı) başlayın, 429 ve 403 hata oranını izleyin ve yasaklar artmadığı sürece bekleme süresini yavaşça azaltın. RPS'yi aniden artırmak, tüm proxy havuzunu bir günde yakmanın en yaygın yoludur.
Pratik hesaplamalar: Wildberries, Ozon, Avito
Formül üzerinden üç gerçek senaryoyu inceleyelim.
Senaryo 1: Wildberries'de fiyat izleme. 20.000 ürünün fiyatlarını her 2 saatte bir güncellemek gerekiyor. RPS_target = 20.000 / (2 × 3600) ≈ 2.78 RPS. 1 IP için 5 saniye bekleme süresi ve Concurrency = 1 ile: N = (2.78 × 5) / 1 ≈ 14 proxy. Yasaklanan IP'lerin bir kısmı için yedek olarak 1.5-2 katı bir havuz almak önerilir, yani 21-28 proxy.
Senaryo 2: Ozon kataloğunun bir kerelik toplanması. 500.000 kartı 24 saatte toplamak. RPS_target = 500.000 / 86.400 ≈ 5.79 RPS. 6 saniye bekleme süresi ile: N = (5.79 × 6) / 1 ≈ 35 proxy. Yedek ile — 50-60 proxy.
Senaryo 3: Avito'da rakiplerin gerçek zamanlı izlenmesi. 5.000 ilan, her 15 dakikada bir güncelleme. RPS_target = 5.000 / 900 ≈ 5.56 RPS. 8 saniye bekleme süresi ile: N = (5.56 × 8) / 1 ≈ 45 proxy. Burada önemli olan, Avito'nun veri merkezi alt ağlarını aktif olarak yasakladığını göz önünde bulundurarak, böyle bir görev için konut veya mobil IP'leri hemen hesaba katmaktır.
Formülde konut, mobil ve veri merkezi proxy'leri
Proxy türü, Delay_per_ip'yi ve dolayısıyla formüldeki N'yi doğrudan etkiler. Veri merkezi proxy'leri daha ucuz ve daha hızlıdır, ancak istekler arasında daha uzun bekleme süreleri gerektirir ve yüksek sıklıkta daha sık yasaklanır — aslında, aynı 5 RPS için konut proxy'lerinden 2-3 kat daha fazla veri merkezi IP'sine ihtiyacınız olabilir.
| Proxy Türü | Ortalama Delay_per_ip | Ne zaman kullanılmalı |
|---|---|---|
| Veri merkezi proxy'leri | 8-15 saniye | Açık API'ler, katı anti-bot olmayan siteler |
| Konut proxy'leri | 4-8 saniye | Wildberries, Ozon, Avito ve diğer anti-botlu marketplace'ler |
| Mobil proxy'ler | 3-6 saniye | En agresif korumalar, sosyal medya, mobil API'ler |
Wildberries ve Ozon gibi marketplace'lerde parsing için genellikle en iyi seçim konut proxy'leridir — fiyat ve istikrarı dengeleyerek, yasakların ani artış riski olmadan daha kısa bekleme süreleri tutmanıza olanak tanır. Veri merkezi proxy'lerini yalnızca agresif anti-bot olmayan platformlar için veya düşük RPS ile bir kerelik görevler için düşünmek gerekir.
Python'da havuzun uygulanması: döngü ile kod
Aşağıda, her IP için istek sıklığını kontrol eden basitleştirilmiş bir proxy havuzu uygulaması bulunmaktadır. Mantık: her proxy, son kullanım zamanını saklar ve planlayıcı, son isteğin üzerinden yeterince zaman geçmiş olan IP'leri seçer.
import time
import random
from dataclasses import dataclass, field
from typing import List, Optional
@dataclass
class ProxyNode:
address: str
delay_per_ip: float # güvenli bekleme süresi (saniye cinsinden)
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
# sıradaki kalıbı önlemek için mevcutlardan rastgele birini seçiyoruz
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:
"""Formül: N = (RPS_target * Delay_per_ip) / Concurrency_per_ip"""
return max(1, int((rps_target * delay_per_ip) / concurrency))
# Kullanım örneği
rps_target = 5.79 # görev hacmi ve zamanından hesaplandı
delay_per_ip = 6.0 # Ozon için güvenli bekleme süresi
n_proxies = calculate_pool_size(rps_target, delay_per_ip)
print(f"Havuzda gerekli proxy sayısı: {n_proxies}") # ~35, yedek ile 50-60
Gerçek bir parser'da bu mantığı görev kuyruğu ile tamamlamak gerekir (örneğin, asyncio veya multiprocessing ile), böylece işçiler, boş bir proxy'nin ortaya çıkmasını bekler, yoksa yoksa hata ile sonlanır. Ayrıca, 429/403 alındığında üstel bir geri dönüş eklemek de önemlidir — bu, belirli bir IP için yasaklama belirtileri olduğunda bekleme süresini otomatik olarak artırır.
Havuzun izlenmesi ve dinamik olarak düzeltilmesi
Formül üzerinden yapılan statik hesaplama, bir başlangıç noktasıdır, nihai bir çözüm değildir. Gerçek kullanımda üç ana metriği izlemek gerekir:
- Başarı oranı — toplam istek sayısına göre başarılı isteklerin (kod 200) yüzdesi. %90-95'in altına düşmesi, Delay_per_ip'yi artırmanız veya havuza proxy eklemeniz gerektiğini gösterir;
- Yasak oranı — son bir saat içinde yasaklama belirtileri gösteren proxy'lerin oranı (captcha, 403, doğrulama formuna yönlendirme);
- Gerçek RPS — zaman aşımı ve tekrar denemeler nedeniyle hesaplanan RPS'den farklı olabilecek gerçek istek işleme hızı.
Pratik bir kural: eğer yasak oranı saatte %5-7'yi geçerse, Delay_per_ip'yi %20-30 artırın ve N'yi formüle göre yeniden hesaplayın. Eğer başarı oranı birkaç saat boyunca %98'in üzerinde kalıyorsa, bekleme süresini yavaşça azaltabilir ve havuzun boyutunu küçültebilirsiniz — bu, yasaklama riski olmadan proxy bütçesinin doğrudan tasarrufudur.
İyi bir uygulama, her IP için ayrı bir günlük tutmaktır: son başarılı isteğin zamanı, ardışık hata sayısı, ortalama yanıt süresi. Bu, "bozuk" proxy'leri 30-60 dakika boyunca döngüden otomatik olarak hariç tutmanızı sağlar, böylece onlardan istek göndermeye devam etmez ve her adımda captcha almazsınız.
Proxy havuzunun hesaplanmasında sık yapılan hatalar
Formülü bilseniz bile, hesaplama detaylarında hata yapmak kolaydır. İşte tipik hataların bir listesi:
- Yasaklar için yedek göz ardı etmek. Mükemmel bir hesaplama yapsanız bile, %5-10 proxy geçici olarak yasaklamalar veya ağ sorunları nedeniyle kullanılamaz. Her zaman temel N'ye 1.3-2 katı bir çarpan ekleyin;
- Tüm uç noktalar için aynı Delay_per_ip. Kategori sayfası ve ürün kartı sayfası farklı limitlere sahip olabilir — ayrı ayrı hesaplayın;
- Test etmeden 1'den fazla Concurrency. Bir IP'den gelen paralel istekler yasaklama riskini artırır, özellikle konut proxy'lerinde — Concurrency = 1 ile başlayın;
- User-Agent ve başlıkların döngüsünün olmaması. Doğru hesaplanmış bir proxy havuzu bile, tüm isteklerin aynı tarayıcı parmak iziyle gitmesi durumunda kurtaramaz;
- Jitter olmadan sabit bekleme süresi. İstekler arasındaki kesin aynı aralık (örneğin, tam 5.0 saniye) — bu, anti-bot tarafından kolayca tanınan bir kalıptır. Rastgele bir sapma ekleyin ±%20-30.
Sonuç
N = (RPS_target × Delay_per_ip) / Concurrency_per_ip formülü, proxy havuzunun hesaplanmasını tahminden mühendislik görevine dönüştürüyor. Öncelikle veri hacmi ve zamanına göre hedef parsing hızını belirleyin, ardından belirli bir platform için güvenli bekleme süresini ampirik olarak bulun ve ancak ondan sonra gerekli IP sayısını hesaplayın — yasaklar ve hatalar için %30-100 yedek ile.
Bu yaklaşım bütçeyi tasarruf ettirir: "her ihtimale karşı" fazla sayıda IP satın almak yerine, hedef RPS'ye ulaşmak için gereken proxy hacmi için tam olarak ödeme yaparsınız, yasaklama riski olmadan. Marketplace'ler ve diğer korumalı siteler için, konut proxy'leri ile başlamanızı öneririz — bunlar, Wildberries, Ozon ve Avito'nun anti-bot sistemleriyle çalışırken istikrar ve maliyet arasında en iyi dengeyi sağlar.