प्रॉक्सी पूल के लिए पार्सिंग का गणना सूत्र: RPS से गणना करते हैं।

पार्सर को स्केल करते समय एक क्लासिक गलती - प्रॉक्सी "आंखों से" खरीदना: 100 IP लिए, पार्सर चलाया, आधे घंटे में बैन मिल गए। समस्या IP की संख्या में नहीं है, बल्कि इस बात में है कि कोई भी हर IP पर वास्तविक लोड की गणना नहीं करता है। हम RPS (प्रति सेकंड अनुरोध), विलंबता और लक्षित साइट के लिमिट पर आधारित प्रॉक्सी पूल की गणना के फॉर्मूले का विश्लेषण करेंगे - विशिष्ट संख्याओं और Python में कोड के साथ।

क्यों IP की संख्या के आधार पर पूल की गणना करना गलती है

पार्सिंग में नए लोगों का सामान्य दृष्टिकोण: "50,000 उत्पादों के कार्ड इकट्ठा करने हैं, तो 500 प्रॉक्सी खरीदेंगे और लोड को फैलाएंगे"। लॉजिक सही लगती है, लेकिन मुख्य बात को ध्यान में नहीं रखती - Wildberries और Ozon जैसी साइटें अनुरोधों की कुल संख्या के आधार पर नहीं, बल्कि एक IP से एक समय में अनुरोधों की तीव्रता के आधार पर बैन करती हैं। यानी 500 प्रॉक्सी, जिनमें से प्रत्येक 20 अनुरोध प्रति सेकंड करता है, तुरंत बैन हो जाएंगे - एंटी-बॉट सिस्टम पैटर्न को DDoS के समान देखता है।

दूसरी ओर, यदि आपके पास 50 प्रॉक्सी हैं, लेकिन प्रत्येक 5-10 सेकंड में 1 अनुरोध करता है, जो मानव व्यवहार की नकल करता है, तो आप बिना किसी बैन के हफ्तों तक स्थिरता से पार्स कर सकते हैं। IP की संख्या स्थिरता का कारण नहीं है, बल्कि सही ढंग से गणना की गई लोड का परिणाम है। इसलिए फॉर्मूला "कितने IP खरीदें" से नहीं, बल्कि "कितने RPS प्राप्त करने की आवश्यकता है और एक IP पर सुरक्षित लोड क्या है" से शुरू होना चाहिए।

एक और बिंदु: विभिन्न प्रकार की प्रॉक्सी एक IP पर विभिन्न "मजबूती" रखते हैं। डेटा सेंटर की प्रॉक्सी उच्च अनुरोध आवृत्ति पर तेजी से बैन होती हैं, क्योंकि उनके सबनेट को होस्टिंग के रूप में आसानी से पहचाना जा सकता है। रेजिडेंट और मोबाइल IP सामान्य उपयोगकर्ताओं के रूप में दिखाई देते हैं, और उन्हें थोड़ी अधिक आवृत्ति की अनुमति दी जा सकती है बिना ब्लॉक होने के जोखिम के - लेकिन इसका मतलब यह नहीं है कि लिमिट को पूरी तरह से नजरअंदाज किया जा सकता है।

प्रॉक्सी पूल की गणना का मूल फॉर्मूला

प्रॉक्सी की संख्या की गणना का फॉर्मूला इस प्रकार है:

N = (RPS_target × Delay_per_ip) / Concurrency_per_ip

जहाँ:

N — पूल में आवश्यक प्रॉक्सी की संख्या;
RPS_target — पार्सिंग की लक्षित गति (सिस्टम में प्रति सेकंड अनुरोध);
Delay_per_ip — एक IP से अनुरोधों के बीच न्यूनतम सुरक्षित विराम (सेकंड में);
Concurrency_per_ip — आप एक IP पर कितने समानांतर थ्रेड की अनुमति देते हैं (आमतौर पर 1, रेजिडेंट प्रॉक्सी के लिए अधिकतम 2)।

लॉजिक सरल है: यदि आप कुल 10 अनुरोध प्रति सेकंड रखना चाहते हैं, और एक IP से अनुरोधों के बीच सुरक्षित विराम 8 सेकंड है, तो एक IP केवल 8 सेकंड में 1 अनुरोध दे सकता है, यानी 0.125 RPS। कुल 10 RPS प्राप्त करने के लिए, 10 / 0.125 = 80 प्रॉक्सी की आवश्यकता होगी। यही वह गणना है जो "500 IP हर हाल में" की अटकल को बदल देती है।

पार्सिंग के लिए लक्षित RPS कैसे गणना करें

पूल की गणना से पहले आपको RPS_target निर्धारित करना होगा - प्रति सेकंड आपको वास्तव में कितने अनुरोधों की आवश्यकता है, ताकि डेटा को उचित समय में इकट्ठा किया जा सके। यहाँ फॉर्मूला उल्टा है:

RPS_target = Total_requests / Time_budget_seconds

उदाहरण: Wildberries से 8 घंटे (28,800 सेकंड) में 100,000 उत्पादों के कार्ड इकट्ठा करने हैं। यदि प्रत्येक कार्ड के लिए 1 अनुरोध की आवश्यकता होती है, तो RPS_target = 100,000 / 28,800 ≈ 3.47 अनुरोध प्रति सेकंड। यह पहली नज़र में इतना अधिक नहीं है - कई लोग आवश्यक गति का अधिक मूल्यांकन करते हैं और अत्यधिक संख्या में प्रॉक्सी खरीदते हैं।

यदि कार्य में कई प्रकार के अनुरोध शामिल हैं (जैसे, पहले श्रेणियों की सूची प्राप्त करना, फिर कार्ड, फिर समीक्षाएँ), तो प्रत्येक चरण के लिए RPS की गणना करें - वे विभिन्न प्रॉक्सी पूलों के साथ समानांतर में चल सकते हैं, और साइट पर कुल लोड विभिन्न एंडपॉइंट्स में वितरित होगा।

एक IP पर लिमिट: प्रति मिनट कितने अनुरोध सुरक्षित हैं

Delay_per_ip — फॉर्मूले में सबसे महत्वपूर्ण पैरामीटर है, और इसे प्रत्येक साइट के लिए अनुभवजन्य रूप से निर्धारित करना आवश्यक है। मार्केटप्लेस पार्सिंग पर आधारित सामान्य दिशानिर्देश:

प्लेटफ़ॉर्म	1 IP से अनुरोधों के बीच सुरक्षित विराम	1 IP से अधिकतम अनुरोध/मिनट
Wildberries (कार्ड API)	4-6 सेकंड	10-15
Ozon (उत्पाद पृष्ठ)	5-8 सेकंड	8-12
Avito (विज्ञापन)	6-10 सेकंड	6-10
Yandex.Market	5-7 सेकंड	8-12

ये आंकड़े एक प्रारंभिक बिंदु हैं, कोई धर्मग्रंथ नहीं। सतर्क मानों (विराम की ऊपरी सीमा) से शुरू करें, 429 और 403 की त्रुटियों का प्रतिशत मॉनिटर करें, और यदि बैन नहीं बढ़ते हैं तो धीरे-धीरे विराम को कम करें। बिना धीरे-धीरे परीक्षण किए RPS को अचानक बढ़ाना - एक दिन में पूरे प्रॉक्सी पूल को जलाने का सबसे सामान्य तरीका है।

व्यावहारिक गणनाएँ: Wildberries, Ozon, Avito

हम फॉर्मूले के साथ तीन वास्तविक परिदृश्यों का विश्लेषण करेंगे।

परिदृश्य 1: Wildberries पर कीमतों की निगरानी। 20,000 उत्पादों की कीमतें हर 2 घंटे में अपडेट करनी हैं। RPS_target = 20,000 / (2 × 3600) ≈ 2.78 RPS। 1 IP पर 5 सेकंड के विराम और Concurrency = 1 के साथ: N = (2.78 × 5) / 1 ≈ 14 प्रॉक्सी। IP के कुछ बैन होने की स्थिति में बैकअप के लिए 1.5-2x गुणांक के साथ पूल लेना उचित है, यानी 21-28 प्रॉक्सी।

परिदृश्य 2: Ozon के कैटलॉग का एक बार का संग्रह। 500,000 कार्ड 24 घंटे में। RPS_target = 500,000 / 86,400 ≈ 5.79 RPS। 6 सेकंड के विराम पर: N = (5.79 × 6) / 1 ≈ 35 प्रॉक्सी। बैकअप के साथ - 50-60 प्रॉक्सी।

परिदृश्य 3: Avito पर प्रतिस्पर्धियों की वास्तविक समय में निगरानी। 5000 विज्ञापन, हर 15 मिनट में अपडेट। RPS_target = 5000 / 900 ≈ 5.56 RPS। 8 सेकंड के विराम पर: N = (5.56 × 8) / 1 ≈ 45 प्रॉक्सी। यहाँ यह ध्यान में रखना महत्वपूर्ण है कि Avito सक्रिय रूप से डेटा सेंटर के सबनेट को बैन करता है, इसलिए इस कार्य के लिए रेजिडेंट या मोबाइल IP को तुरंत शामिल करना अधिक समझदारी है।

फॉर्मूले में रेजिडेंट, मोबाइल और डेटा सेंटर प्रॉक्सी

प्रॉक्सी का प्रकार Delay_per_ip पर सीधे प्रभाव डालता है और, तदनुसार, फॉर्मूले में अंतिम N पर। डेटा सेंटर की प्रॉक्सी सस्ती और तेज होती हैं, लेकिन उन्हें अनुरोधों के बीच लंबे विराम की आवश्यकता होती है और उच्च आवृत्ति पर अधिक बैन होती हैं - वास्तव में, 5 RPS के लिए आपको रेजिडेंट IP की तुलना में 2-3 गुना अधिक डेटा सेंटर IP की आवश्यकता हो सकती है।

प्रॉक्सी का प्रकार	औसत Delay_per_ip	कब उपयोग करें
डेटा सेंटर प्रॉक्सी	8-15 सेकंड	ओपन API, बिना सख्त एंटी-बॉट वाली साइटें
रेजिडेंट प्रॉक्सी	4-8 सेकंड	Wildberries, Ozon, Avito और अन्य एंटी-बॉट मार्केटप्लेस
मोबाइल प्रॉक्सी	3-6 सेकंड	सबसे आक्रामक सुरक्षा, सोशल नेटवर्क, मोबाइल API

Wildberries और Ozon जैसी मार्केटप्लेस के लिए पार्सिंग के लिए आमतौर पर रेजिडेंट प्रॉक्सी सबसे अच्छा विकल्प होता है - वे कीमत और स्थिरता के बीच संतुलन बनाते हैं, जिससे बिना बैन के तेजी से छोटे विराम बनाए रखना संभव होता है। डेटा सेंटर की प्रॉक्सी केवल बिना आक्रामक एंटी-बॉट वाली साइटों के लिए या कम RPS वाले एक बार के कार्यों के लिए विचार करने योग्य हैं।

Python में पूल का कार्यान्वयन: रोटेशन के साथ कोड

नीचे - प्रत्येक IP पर अनुरोधों की आवृत्ति को नियंत्रित करने के साथ प्रॉक्सी पूल का सरल कार्यान्वयन है। लॉजिक: प्रत्येक प्रॉक्सी अंतिम उपयोग के समय को संग्रहीत करता है, और शेड्यूलर केवल उन IP को चुनता है जिनके साथ अंतिम अनुरोध के बाद पर्याप्त समय बीत चुका है।

import time
import random
from dataclasses import dataclass, field
from typing import List, Optional

@dataclass
class ProxyNode:
    address: str
    delay_per_ip: float  # सुरक्षित विराम सेकंड में
    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
        # उपलब्ध में से एक यादृच्छिक चुनें, ताकि कतार का पैटर्न न बने
        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:
    """फॉर्मूला: N = (RPS_target * Delay_per_ip) / Concurrency_per_ip"""
    return max(1, int((rps_target * delay_per_ip) / concurrency))


# उपयोग का उदाहरण
rps_target = 5.79        # कार्य के आकार और समय से गणना की गई
delay_per_ip = 6.0        # Ozon के लिए सुरक्षित विराम
n_proxies = calculate_pool_size(rps_target, delay_per_ip)
print(f"पूल में प्रॉक्सी की आवश्यकता: {n_proxies}")  # ~35, बैकअप के साथ 50-60

वास्तविक पार्सर में इस लॉजिक को कार्यों की कतार (जैसे, asyncio या multiprocessing के माध्यम से) के साथ पूरक करना आवश्यक है, ताकि कार्यकर्ता स्वतंत्र प्रॉक्सी के आने की प्रतीक्षा करें, न कि उनकी अनुपस्थिति में त्रुटि के साथ समाप्त हों। 429/403 प्राप्त करने पर एक्सपोनेंशियल बैकऑफ भी जोड़ना उचित है - यह विशेष IP के लिए अवरोध के संकेत मिलने पर विराम को स्वचालित रूप से बढ़ा देगा।

पूल की निगरानी और गतिशील समायोजन

फॉर्मूले के अनुसार स्थिर गणना एक प्रारंभिक बिंदु है, अंतिम समाधान नहीं। वास्तविक उपयोग में तीन प्रमुख मैट्रिक्स की निगरानी करनी चाहिए:

सफलता दर - कुल संख्या में से सफल अनुरोधों (कोड 200) का प्रतिशत। 90-95% से नीचे गिरना संकेत करता है कि Delay_per_ip को बढ़ाने की आवश्यकता है या पूल में प्रॉक्सी जोड़ने की आवश्यकता है;
बैन दर - पिछले घंटे में बैन के संकेत दिखाने वाले प्रॉक्सी का अनुपात (कैप्चा, 403, सत्यापन फॉर्म पर रीडायरेक्ट);
वास्तविक RPS - अनुरोधों को संसाधित करने की वास्तविक गति, जो टाइमआउट और पुनः प्रयासों के कारण गणना की गई से भिन्न हो सकती है।

व्यावहारिक नियम: यदि बैन दर प्रति घंटे 5-7% से अधिक है, तो Delay_per_ip को 20-30% बढ़ाएँ और N को फिर से फॉर्मूले के अनुसार गणना करें। यदि सफलता दर कई घंटों तक 98% से अधिक स्थिर रहती है, तो धीरे-धीरे विराम को कम किया जा सकता है और पूल का आकार घटाया जा सकता है - यह बैन और विफलताओं के लिए 30-100% बैकअप के साथ बिना स्थिरता खोए प्रॉक्सी पर बजट की सीधी बचत है।

एक अच्छी प्रथा है कि प्रत्येक IP के लिए अलग से लॉग रखें: अंतिम सफल अनुरोध का समय, लगातार त्रुटियों की संख्या, औसत प्रतिक्रिया समय। यह "खराब" प्रॉक्सी को 30-60 मिनट के लिए रोटेशन से स्वचालित रूप से बाहर करने की अनुमति देता है, बजाय इसके कि उनके माध्यम से अनुरोध भेजते रहें और हर कदम पर कैप्चा प्राप्त करें।

प्रॉक्सी पूल की गणना में सामान्य गलतियाँ

फॉर्मूला जानने के बावजूद, गणना के विवरण में गलती करना आसान है। यहाँ सामान्य गलतियों की सूची है:

बैन के लिए बैकअप की अनदेखी। यहां तक कि आदर्श गणना के साथ भी, 5-10% प्रॉक्सी ब्लॉकों या नेटवर्क समस्याओं के कारण अस्थायी रूप से अनुपलब्ध रहेंगी। हमेशा मूल N में 1.3-2x गुणांक जोड़ें;
सभी एंडपॉइंट्स के लिए समान Delay_per_ip। श्रेणी पृष्ठ और उत्पाद कार्ड पृष्ठ के विभिन्न लिमिट हो सकते हैं - अलग से गणना करें;
बिना परीक्षण के 1 से अधिक Concurrency। एक IP से समानांतर अनुरोध बैन के जोखिम को तेजी से बढ़ाते हैं, विशेष रूप से रेजिडेंट प्रॉक्सी पर - Concurrency = 1 से शुरू करें;
User-Agent और हेडर की रोटेशन का अभाव। यहां तक कि सही ढंग से गणना किया गया प्रॉक्सी पूल भी नहीं बचाएगा, यदि सभी अनुरोध एक ही ब्राउज़र के फिंगरप्रिंट के साथ आते हैं;
जिटर के बिना निश्चित विराम। अनुरोधों के बीच बिल्कुल समान अंतराल (जैसे, ठीक 5.0 सेकंड) - यह एक पैटर्न है, जिसे एंटी-बॉट द्वारा आसानी से पहचाना जा सकता है। यादृच्छिक विचलन ±20-30% जोड़ें।

निष्कर्ष

फॉर्मूला N = (RPS_target × Delay_per_ip) / Concurrency_per_ip प्रॉक्सी पूल की गणना को अटकल से एक इंजीनियरिंग कार्य में बदल देता है जिसमें विशिष्ट संख्याएँ होती हैं। पहले डेटा के आकार और समय के आधार पर लक्षित पार्सिंग गति निर्धारित करें, फिर विशिष्ट साइट के लिए सुरक्षित विराम अनुभवजन्य रूप से खोजें, और केवल इसके बाद आवश्यक IP की संख्या की गणना करें - बैन और विफलताओं के लिए 30-100% बैकअप के साथ।

यह दृष्टिकोण बजट की बचत करता है: "हर हाल में" अत्यधिक संख्या में IP खरीदने के बजाय, आप ठीक उसी मात्रा में प्रॉक्सी के लिए भुगतान करते हैं जो लक्षित RPS को बिना बैन के जोखिम के प्राप्त करने के लिए आवश्यक है। मार्केटप्लेस और अन्य सुरक्षित साइटों के लिए पार्सिंग के लिए, हम रेजिडेंट प्रॉक्सी से शुरू करने की सिफारिश करते हैं - वे Wildberries, Ozon और Avito के एंटी-बॉट सिस्टम के साथ काम करते समय स्थिरता और लागत के बीच सबसे अच्छा संतुलन प्रदान करते हैं।