Kaç Proxy'ye İhtiyacınız Var

Gereken optimum proxy sayısı; kullanım senaryosuna, hedef sitenin anti-bot önlemlerine, istenen istek hacmine, eşzamanlı bağlantı sayısına ve gerekli IP rotasyon sıklığına göre belirlenir.

Temel faktörleri anlamak

Gerekli proxy sayısını belirlemek, birbiriyle bağlantılı birkaç değişkeni değerlendirmeyi gerektirir. Kesin hesap genellikle yinelemelidir ve testlerle iyileştirilir; ancak aşağıdakileri analiz ederek bir başlangıç tahmini yapılabilir:

Hedef sitenin anti-bot önlemleri

Siteler, otomatik istekleri tespit edip engellemek için çeşitli teknikler kullanır. Bu önlemlerin sertliği doğrudan proxy ihtiyacını etkiler.
* Düşük güvenlik: temel hız sınırlaması, aşırı istek sonrası IP engelleme.
* Orta güvenlik: daha gelişmiş hız limitleri, CAPTCHA doğrulamaları, temel tarayıcı parmak izi çıkarma.
* Yüksek güvenlik: gelişmiş bot tespiti, ayrıntılı tarayıcı parmak izi, davranış analizi, kapsamlı IP kara listeleme, sık CAPTCHA, honeypot tuzakları.

Yüksek korumalı hedefler daha büyük ve daha çeşitli bir proxy havuzu gerektirir; genellikle sık rotasyonlu residential veya mobil IP'ler şarttır.

İstenen istek hacmi ve hızı

Belirli bir zaman diliminde planlanan toplam istek sayısı (ör. saatlik, günlük istek) ve istenen hız (Queries Per Second - QPS) temel unsurlardır.
* Toplam istek (TR): yapılacak HTTP/S isteklerinin mutlak sayısı.
* İstenen QPS (DQPS): saniye başına hedeflenen istek oranı.

Daha yüksek bir TR veya DQPS, yükü dağıtmak ve tek tek IP'lerde hız limitlerini tetiklememek için genellikle daha fazla proxy gerektirir.

Proxy rotasyonu ve sticky oturumlar

• Rotasyon sıklığı: IP adresinin ne sıklıkla değiştiği. Hızlı rotasyon (ör. her istekte, birkaç saniyede bir) zamanla havuzdan daha fazla benzersiz IP tüketir ama bir IP'nin işaretlenme olasılığını azaltır.
• Sticky oturumlar: belirli bir süre boyunca aynı IP adresiyle kalıcı bağlantı veya ardışık istekler yapma zorunluluğu (ör. oturum açma, çok sayfalı formlarda gezinme). Sticky oturumlar bir IP'yi daha uzun süre meşgul eder ve diğer görevler için etkin havuz boyutunu düşürebilir.

Bekleme (cooldown) süresi

Bir IP kullanıldıktan sonra, özellikle yumuşak engel (soft block) veya CAPTCHA ile karşılaştıysa, o IP'yi bir "cooldown" süresi boyunca dinlendirmek akıllıcadır. Bu, hedef sitenin tespit sistemlerinin sıfırlanmasına ya da IP'nin itibarının toparlanmasına imkân verir. Daha uzun bir cooldown, herhangi bir anda aktif olarak kullanılabilir IP sayısının azalması, dolayısıyla toplam havuz ihtiyacının artması demektir.

Coğrafi ve ağ çeşitliliği

Bazı işler belirli coğrafi konumlardan (ülke, bölge, şehir) veya farklı ağ türlerinden (ör. çeşitli ISP'ler) IP gerektirir. Bu, proxy havuzunuzu bölümlere ayırır: toplam proxy sayınız büyük olsa bile belirli bir coğrafi hedef için kullanılabilir havuz daha küçük olabilir.

Proxy ihtiyacını tahmin etmek: pratik bir model

Sağlam bir tahmin modeli, gereken eşzamanlı aktif proxy sayısını ve rotasyon ile cooldown'u mümkün kılan ek proxy'leri birlikte hesaba katar.

Değişkenler:

• DQPS: Desired Queries Per Second (hedeflenen saniyelik istek).
• APQPS: Tek bir proxy'nin rotasyona girmeden veya engellenme riskine girmeden sürdürebildiği ortalama QPS (temkinli tahmin edin, ör. 0.1 ile 1 QPS).
• AUT: Average Usage Time (saniye) — bir proxy'nin rotasyona alınmadan ya da cooldown'a konmadan önce aktif olarak istek yaptığı süre (ör. 30s - 300s).
• CDT: Cooldown Duration Time (saniye) — bir proxy'nin kullanımdan sonra yeniden kullanılmadan önce dinlenmesi gereken süre (ör. 300s - 3600s).
• BF: Buffer Factor (ör. 0.10 - 0.25) — proxy arızalarını, beklenmedik engelleri veya artan yükü karşılamak için pay.

Hesaplama adımları:

1. Eşzamanlı aktif proxy sayısını hesaplayın (CAP):
   Her proxy'nin APQPS performans verdiği varsayımıyla, DQPS hedefinize ulaşmak için aynı anda aktif olması gereken minimum proxy sayısıdır.
   CAP = DQPS / APQPS

2. Rotasyon çarpanını hesaplayın (RM):
   Bu katsayı, bir IP'nin aktif kullanımı ve ardından gelen cooldown'u nedeniyle havuzda kaç "slot" işgal ettiğini belirler.
   RM = (AUT + CDT) / AUT

   • Kendi kendini düzeltme: AUT çok kısa ve CDT çok uzunsa RM büyük çıkabilir. Bu, benzersiz IP'lere yüksek talep olduğunu gösterir. CDT 0 ise (cooldown yok) RM 1 olur.

3. Temel proxy havuzunu hesaplayın (BPP):
   AUT ve CDT hesaba katılarak CAP seviyesini sürdürmek için gereken teorik minimum proxy sayısıdır.
   BPP = CAP * RM

4. Payı uygulayın (BP):
   Proxy'lerin bir kısmının yavaşlaması, yanıt vermemesi veya beklenenden erken engellenmesi gibi öngörülemeyen durumlar için pay ekleyin.
   BP = BPP * BF

5. Tahmini toplam proxy (TEP):
   TEP = BPP + BP

Örnek hesaplama:

Aşağıdaki gereksinim ve tahminleri varsayalım:
* DQPS: saniyede 20 istek
* APQPS: saniyede 0.5 istek (yüksek güvenlikli bir hedef için temkinli tahmin)
* AUT: 60 saniye (her proxy rotasyondan önce 30 istek yapıyor)
* CDT: 900 saniye (15 dakika cooldown)
* BF: 0.20 (%20 pay)

1. CAP hesabı:
   CAP = 20 QPS / 0.5 QPS/proxy = 40 proxy
   (Herhangi bir anda aktif olarak istek yapan 40 proxy'ye ihtiyacınız var.)

2. RM hesabı:
   RM = (60 saniye + 900 saniye) / 60 saniye = 960 / 60 = 16
   (Her aktif proxy için cooldown/rotasyonda 15 ek proxy gerekir.)

3. BPP hesabı:
   BPP = 40 proxy * 16 = 640 proxy

4. BP hesabı:
   BP = 640 proxy * 0.20 = 128 proxy

5. TEP hesabı:
   TEP = 640 + 128 = 768 proxy

Bu senaryoda, 15 dakikalık cooldown ile orta düzeyde korunan bir hedefe karşı 20 QPS'i sürdürmek için yaklaşık 768 proxy gerekir.

Kod örneği (tahmin için Python fonksiyonu):

def estimate_proxies(desired_qps, avg_qps_per_proxy, avg_usage_time_sec, cooldown_time_sec, buffer_factor):
    """
    Operasyonel parametrelere göre gereken toplam proxy sayısını tahmin eder.

    Args:
        desired_qps (float): Hedeflenen saniyelik istek sayısı.
        avg_qps_per_proxy (float): Tek bir proxy'nin sürdürebildiği ortalama QPS.
        avg_usage_time_sec (float): Bir proxy'nin rotasyon/cooldown öncesi aktif kaldığı süre (saniye).
        cooldown_time_sec (float): Bir proxy'nin kullanım sonrası dinlendiği süre (saniye).
        buffer_factor (float): Ek proxy payı katsayısı (ör. %15 için 0.15).

    Returns:
        int: Tahmini toplam proxy sayısı.
    """
    if avg_qps_per_proxy <= 0 or avg_usage_time_sec <= 0:
        raise ValueError("avg_qps_per_proxy and avg_usage_time_sec must be positive.")

    # 1. Eşzamanlı aktif proxy sayısını hesapla (CAP)
    concurrent_active_proxies = desired_qps / avg_qps_per_proxy

    # 2. Rotasyon çarpanını hesapla (RM)
    rotation_multiplier = (avg_usage_time_sec + cooldown_time_sec) / avg_usage_time_sec

    # 3. Temel proxy havuzunu hesapla (BPP)
    base_proxy_pool = concurrent_active_proxies * rotation_multiplier

    # 4. Payı uygula (BP)
    buffered_proxies = base_proxy_pool * buffer_factor

    # 5. Tahmini toplam proxy (TEP)
    total_estimated_proxies = base_proxy_pool + buffered_proxies

    return int(round(total_estimated_proxies))

# Kullanım örneği:
# total_proxies = estimate_proxies(
#     desired_qps=20,
#     avg_qps_per_proxy=0.5,
#     avg_usage_time_sec=60,
#     cooldown_time_sec=900,
#     buffer_factor=0.20
# )
# print(f"Estimated proxies: {total_proxies}") # Çıktı: Estimated proxies: 768

Proxy türü önerileri

Proxy türü seçimi etkinliği ve maliyeti belirgin biçimde etkiler.

İleri düzey değerlendirmeler

Proxy sağlığının izlenmesi ve yönetimi

Proxy sağlığını (yanıt süreleri, başarı oranları, engel durumu) sürekli izleyen bir sistem kurmak kritiktir. Performansı zayıf olan veya sık engellenen proxy'ler aktif havuzdan geçici ya da kalıcı olarak çıkarılmalı ve yenileriyle değiştirilmelidir. Bu dinamik yönetim, hesaptaki pay katsayısının gerçekten işe yaramasını sağlar.

Yeniden deneme mantığı ve hata yönetimi

Sağlam yeniden deneme mekanizmaları ve akıllı hata yönetimi, yeni proxy'lere olan anlık talebi azaltır. Yumuşak bir engelde anında yeni IP'ye geçmek yerine, stratejik bir gecikmenin ardından aynı IP ile yeniden denemek — özellikle engel geçiciyse — daha verimli olabilir. Ancak agresif yeniden deneme mantığı IP'nin daha hızlı kara listeye girmesine de yol açabilir.

Dinamik ayarlama

İlk tahmin yalnızca bir başlangıç noktasıdır. Hedef sitelere karşı gerçek performans, yapılacak düzeltmeleri belirler. Başarı oranlarını, engellenme oranlarını ve QPS'i sürekli izleyin. Engellenme oranları yüksekse CDT veya TEP değerini artırın. Performans DQPS altındaysa CAP değerini artırın veya APQPS değerini iyileştirin. Bu yinelemeli süreç, kaynakların en verimli şekilde dağıtılmasını sağlar.