धीमे प्रॉक्सी: गति में गिरावट के 7 कारण और तेज़ी के तरीके
प्रॉक्सी कनेक्शन की गति सीधे पार्सिंग, स्वचालन और बड़े पैमाने पर अनुरोधों से संबंधित किसी भी कार्य की प्रभावशीलता को प्रभावित करती है। जब प्रॉक्सी धीमी होती है, तो इससे स्क्रिप्ट के निष्पादन का समय बढ़ता है, टाइमआउट और डेटा हानि होती है। इस लेख में, हम कम गति के तकनीकी कारणों का विश्लेषण करेंगे और कोड के उदाहरणों और परीक्षण परिणामों के साथ अनुकूलन के विशिष्ट तरीके दिखाएंगे।
सर्वर की भौगोलिक दूरी
आपके सर्वर, प्रॉक्सी और लक्ष्य संसाधन के बीच भौतिक दूरी देरी (latency) का मुख्य कारक है। श्रृंखला में प्रत्येक अतिरिक्त नोड मिलिसेकंड जोड़ता है, जो बड़े पैमाने पर अनुरोधों के दौरान जमा होता है।
प्रॉक्सी के माध्यम से अनुरोध का सामान्य पैटर्न इस प्रकार है: आपका सर्वर → प्रॉक्सी सर्वर → लक्ष्य साइट → प्रॉक्सी सर्वर → आपका सर्वर। यदि आपका पार्सर जर्मनी में है, प्रॉक्सी अमेरिका में है, और लक्ष्य साइट जापान में है, तो डेटा हजारों किलोमीटर की यात्रा करता है।
व्यावहारिक उदाहरण: यूरोपीय साइट पर 1000 अनुरोधों का परीक्षण करने से औसत प्रतिक्रिया समय में अंतर पाया गया: यूरोप में प्रॉक्सी के माध्यम से — 180 मिलीसेकंड, एशिया में प्रॉक्सी के माध्यम से — 520 मिलीसेकंड। प्रत्येक अनुरोध पर 340 मिलीसेकंड का अंतर 1000 अनुरोधों पर 340 सेकंड (5.6 मिनट) का समय देता है।
समाधान: लक्ष्य संसाधन के निकट भौगोलिक रूप से प्रॉक्सी का चयन करें। यदि आप रूसी साइटों को पार्स कर रहे हैं — रूसी IP वाले प्रॉक्सी का उपयोग करें। वैश्विक सेवाओं (Google, Amazon) के लिए, अमेरिका या पश्चिमी यूरोप में प्रॉक्सी सबसे उपयुक्त हैं, जहां मुख्य डेटा केंद्र स्थित हैं।
रिहायशी प्रॉक्सी के लिए, किसी विशेष शहर या क्षेत्र का चयन करने की क्षमता पर ध्यान दें, न कि केवल देश पर। मास्को और व्लादिवोस्तोक से प्रॉक्सी के बीच पिंग में अंतर मास्को सर्वर को कॉल करते समय 150-200 मिलीसेकंड तक हो सकता है।
गति पर प्रोटोकॉल का प्रभाव
प्रॉक्सी प्रोटोकॉल का चयन गति पर महत्वपूर्ण प्रभाव डालता है। मुख्य विकल्प: HTTP/HTTPS, SOCKS4, SOCKS5। प्रत्येक के पास डेटा प्रोसेसिंग और ओवरहेड के अपने विशेषताएँ हैं।
| प्रोटोकॉल | गति | ओवरहेड | उपयोग |
|---|---|---|---|
| HTTP | उच्च | न्यूनतम | वेब-पार्सिंग, API |
| HTTPS | मध्यम | +15-25% SSL पर | सुरक्षित कनेक्शन |
| SOCKS4 | उच्च | कम | TCP ट्रैफ़िक |
| SOCKS5 | मध्यम-उच्च | +5-10% प्रमाणीकरण पर | सार्वभौमिक ट्रैफ़िक, UDP |
HTTP प्रॉक्सी वेब स्क्रैपिंग के लिए सबसे उपयुक्त होते हैं, क्योंकि वे एप्लिकेशन स्तर पर काम करते हैं और डेटा को कैश कर सकते हैं। SOCKS5 अधिक सार्वभौमिक होते हैं, लेकिन अतिरिक्त प्रोसेसिंग लेयर जोड़ते हैं। सरल HTML पार्सिंग के लिए, HTTP और SOCKS5 के बीच गति में अंतर 10-15% हो सकता है।
Python में कॉन्फ़िगरेशन का उदाहरण (requests):
import requests
# HTTP प्रॉक्सी - वेब अनुरोधों के लिए तेज़
proxies_http = {
'http': 'http://user:pass@proxy.example.com:8080',
'https': 'http://user:pass@proxy.example.com:8080'
}
# SOCKS5 - अधिक सार्वभौमिक, लेकिन धीमा
proxies_socks = {
'http': 'socks5://user:pass@proxy.example.com:1080',
'https': 'socks5://user:pass@proxy.example.com:1080'
}
# वेब पार्सिंग के लिए HTTP का उपयोग करें
response = requests.get('https://example.com', proxies=proxies_http, timeout=10)
यदि आपका प्रदाता दोनों विकल्प प्रदान करता है, तो उन्हें वास्तविक कार्यों पर परीक्षण करें। डेटा सेंटर प्रॉक्सी के लिए, HTTP प्रोटोकॉल आमतौर पर समान लोड पर SOCKS5 की तुलना में 12-18% अधिक गति दिखाता है।
प्रॉक्सी सर्वर का ओवरलोड और IP पूल
जब एक प्रॉक्सी सर्वर बहुत सारे समवर्ती कनेक्शनों को संभालता है, तो चैनल की बैंडविड्थ और कंप्यूटिंग संसाधनों की सीमाओं के कारण गति गिर जाती है। यह विशेष रूप से सामान्य (shared) प्रॉक्सी के लिए महत्वपूर्ण है, जहां एक IP कई ग्राहकों द्वारा उपयोग किया जाता है।
ओवरलोड की सामान्य तस्वीर: स्क्रिप्ट के काम शुरू करने पर गति सामान्य होती है (50-100 अनुरोध प्रति मिनट), फिर अचानक 10-15 अनुरोधों तक गिर जाती है। यह तब होता है जब सर्वर खुले कनेक्शनों या बैंडविड्थ की सीमा तक पहुँच जाता है।
ओवरलोड के संकेत: 200%+ पर प्रतिक्रिया समय में वृद्धि, समय-समय पर टाइमआउट, "Connection reset by peer" त्रुटियाँ, तेज़ झटके के साथ अस्थिर गति।
समाधान:
- एक IP के बजाय प्रॉक्सी का पूल उपयोग करें। 10-20 प्रॉक्सी के बीच रोटेशन लोड को वितरित करता है और ब्लॉक होने की संभावना को कम करता है।
- एक प्रॉक्सी के माध्यम से समवर्ती कनेक्शनों की संख्या को सीमित करें (5-10 समानांतर थ्रेड्स से अधिक नहीं)।
- उच्च लोड वाले कार्यों के लिए प्राइवेट (dedicated) प्रॉक्सी का चयन करें, जहां संसाधन अन्य उपयोगकर्ताओं के साथ साझा नहीं होते हैं।
- वास्तविक समय में गति की निगरानी करें और धीमे प्रॉक्सी को रोटेशन से स्वचालित रूप से बाहर करें।
गति की निगरानी के साथ पूल का कार्यान्वयन का उदाहरण:
import time
import requests
from collections import deque
class ProxyPool:
def __init__(self, proxies, max_response_time=5.0):
self.proxies = deque(proxies)
self.max_response_time = max_response_time
self.stats = {p: {'total': 0, 'slow': 0} for p in proxies}
def get_proxy(self):
"""पूल से अगला प्रॉक्सी प्राप्त करें"""
proxy = self.proxies[0]
self.proxies.rotate(-1) # अंत में स्थानांतरित करें
return proxy
def test_and_remove_slow(self, url='http://httpbin.org/ip'):
"""धीमे प्रॉक्सी का परीक्षण करें और हटा दें"""
for proxy in list(self.proxies):
try:
start = time.time()
requests.get(url, proxies={'http': proxy}, timeout=10)
response_time = time.time() - start
self.stats[proxy]['total'] += 1
if response_time > self.max_response_time:
self.stats[proxy]['slow'] += 1
# यदि 50% से अधिक अनुरोध धीमे हैं तो हटाएँ
slow_ratio = self.stats[proxy]['slow'] / self.stats[proxy]['total']
if slow_ratio > 0.5 and self.stats[proxy]['total'] > 10:
self.proxies.remove(proxy)
print(f"धीमा प्रॉक्सी हटा दिया गया: {proxy}")
except:
self.proxies.remove(proxy)
# उपयोग
proxies = [
'http://proxy1.example.com:8080',
'http://proxy2.example.com:8080',
'http://proxy3.example.com:8080'
]
pool = ProxyPool(proxies, max_response_time=3.0)
pool.test_and_remove_slow()
# पूल के साथ कार्य करना
for i in range(100):
proxy = pool.get_proxy()
# प्रॉक्सी के माध्यम से अनुरोध करें
कनेक्शन सेटिंग्स और टाइमआउट
गलत तरीके से कॉन्फ़िगर की गई कनेक्शन सेटिंग्स प्रॉक्सी की प्रतीत होने वाली सुस्ती का एक सामान्य कारण हैं। बहुत बड़े टाइमआउट स्क्रिप्ट को अनुपलब्ध प्रॉक्सी की प्रतीक्षा करने के लिए मजबूर करते हैं, बहुत छोटे सामान्य कनेक्शनों को काट देते हैं।
गति को प्रभावित करने वाले प्रमुख पैरामीटर:
- कनेक्शन टाइमआउट — कनेक्शन स्थापित करने के लिए प्रतीक्षा करने का समय। अनुकूल: रिहायशी प्रॉक्सी के लिए 5-10 सेकंड, डेटा सेंटर के लिए 3-5।
- रीड टाइमआउट — कनेक्शन स्थापित करने के बाद प्रतिक्रिया की प्रतीक्षा करने का समय। कार्य के आधार पर: पार्सिंग के लिए 10-15 सेकंड, बड़े फ़ाइलों को डाउनलोड करने के लिए 30+।
- कीप-एलाइव — TCP कनेक्शनों का पुन: उपयोग। उसी डोमेन के लिए प्रत्येक बाद के अनुरोध पर 200-300 मिलीसेकंड की बचत करता है।
- कनेक्शन पूलिंग — खुले कनेक्शनों का पूल। बड़े पैमाने पर अनुरोधों के लिए उच्च प्रदर्शन के लिए महत्वपूर्ण।
अनुकूलित कॉन्फ़िगरेशन के लिए requests:
import requests
from requests.adapters import HTTPAdapter
from urllib3.util.retry import Retry
# अनुकूलित सेटिंग्स के साथ सत्र बनाएँ
session = requests.Session()
# पुनः प्रयास सेटिंग
retry_strategy = Retry(
total=3, # अधिकतम 3 प्रयास
backoff_factor=0.5, # प्रयासों के बीच देरी: 0.5, 1, 2 सेकंड
status_forcelist=[429, 500, 502, 503, 504],
allowed_methods=["GET", "POST"]
)
# कनेक्शन पूल के साथ अडैप्टर
adapter = HTTPAdapter(
max_retries=retry_strategy,
pool_connections=10, # 10 होस्ट के लिए पूल
pool_maxsize=20 # अधिकतम 20 कनेक्शन
)
session.mount("http://", adapter)
session.mount("https://", adapter)
# प्रॉक्सी सेटिंग
session.proxies = {
'http': 'http://user:pass@proxy.example.com:8080',
'https': 'http://user:pass@proxy.example.com:8080'
}
# अनुकूलित टाइमआउट के साथ अनुरोध
# (connection_timeout, read_timeout)
response = session.get(
'https://example.com',
timeout=(5, 15), # 5 सेकंड कनेक्शन के लिए, 15 पढ़ने के लिए
headers={'Connection': 'keep-alive'} # कनेक्शन का पुन: उपयोग
)
1000 पृष्ठों को पार्स करते समय कीप-एलाइव के साथ सत्रों का उपयोग करने से प्रत्येक अनुरोध के लिए नए कनेक्शन बनाने की तुलना में 30-40% तेजी आती है। TCP कनेक्शन और SSL हैंडशेक की स्थापना में समय की बचत बड़े पैमाने पर संचालन के दौरान महत्वपूर्ण होती है।
एन्क्रिप्शन और SSL/TLS ओवरहेड
HTTPS कनेक्शन डेटा के एन्क्रिप्शन/डिक्रिप्शन और SSL/TLS हैंडशेक को पूरा करने के लिए अतिरिक्त कंप्यूटिंग संसाधनों की आवश्यकता होती है। प्रॉक्सी के माध्यम से काम करते समय, यह दो बार होता है: आपके और प्रॉक्सी के बीच, प्रॉक्सी और लक्ष्य सर्वर के बीच।
सामान्य SSL/TLS ओवरहेड:
- प्रारंभिक हैंडशेक: 150-300 मिलीसेकंड (एल्गोरिदम और दूरी पर निर्भर करता है)
- डेटा का एन्क्रिप्शन/डिक्रिप्शन: ट्रांसमिशन समय में +10-20%
- उच्च ट्रैफ़िक पर प्रॉक्सी सर्वर पर CPU पर अतिरिक्त लोड
अनुकूलन के तरीके:
1. TLS सत्र पुनः उपयोग का उपयोग करें
SSL सत्र के पैरामीटर को पुनः उपयोग करने की अनुमति देता है और पूर्ण हैंडशेक को छोड़ देता है। प्रत्येक बाद के कनेक्शन पर 200 मिलीसेकंड तक की बचत।
Python में, यह requests.Session() का उपयोग करते समय स्वचालित रूप से काम करता है, लेकिन सुनिश्चित करें कि आप प्रत्येक अनुरोध के लिए एक नई सत्र नहीं बना रहे हैं।
2. TLS 1.3 को प्राथमिकता दें
TLS 1.3 हैंडशेक के लिए केवल एक राउंड-ट्रिप की आवश्यकता होती है जबकि TLS 1.2 में दो की आवश्यकता होती है। यह कनेक्शन की स्थापना के समय को 30-50% तक कम करता है।
सुनिश्चित करें कि आपकी लाइब्रेरी (OpenSSL, urllib3) TLS 1.3 का समर्थन करती है और यह सेटिंग्स में बंद नहीं है।
3. आंतरिक कार्यों के लिए HTTP पर विचार करें
यदि आप सार्वजनिक डेटा को पार्स कर रहे हैं जिसमें संवेदनशील जानकारी नहीं है, और साइट HTTP पर उपलब्ध है, तो असुरक्षित कनेक्शन का उपयोग करें। यह गति में 15-25% की वृद्धि देगा।
मोबाइल प्रॉक्सी के साथ काम करते समय, जहां संचार चैनल धीमा हो सकता है, SSL ओवरहेड और भी अधिक स्पष्ट हो जाता है। परीक्षणों में, 4G प्रॉक्सी के माध्यम से HTTP और HTTPS अनुरोधों के बीच औसत में 280 मिलीसेकंड का अंतर पाया गया।
DNS-रिज़ॉल्विंग और कैशिंग
नए डोमेन के लिए प्रत्येक अनुरोध DNS रिज़ॉल्विंग की आवश्यकता होती है — डोमेन नाम को IP पते में परिवर्तित करना। बिना कैशिंग के, यह प्रत्येक अनुरोध में 20-100 मिलीसेकंड जोड़ता है, और धीमे DNS सर्वर के साथ, देरी 500+ मिलीसेकंड तक पहुँच सकती है।
जब आप प्रॉक्सी के माध्यम से काम कर रहे होते हैं, तो DNS अनुरोध तीन स्थानों पर किए जा सकते हैं:
- आपकी ओर (क्लाइंट डोमेन को रिज़ॉल्व करता है और प्रॉक्सी को IP भेजता है)
- प्रॉक्सी सर्वर पर (SOCKS5, HTTP CONNECT — प्रॉक्सी डोमेन प्राप्त करता है और इसे स्वयं रिज़ॉल्व करता है)
- लक्ष्य सर्वर पर (दुर्लभ, विशिष्ट कॉन्फ़िगरेशन में)
SOCKS5 प्रॉक्सी के लिए, DNS रिज़ॉल्विंग आमतौर पर प्रॉक्सी सर्वर की ओर होती है, जो धीमी हो सकती है यदि प्रदाता के पास खराब DNS सर्वर हैं। HTTP प्रॉक्सी अक्सर क्लाइंट साइड पर रिज़ॉल्व करते हैं।
DNS तेज़ करने के तरीके:
import socket
from functools import lru_cache
# क्लाइंट साइड पर DNS रिज़ॉल्विंग कैशिंग
@lru_cache(maxsize=256)
def cached_resolve(hostname):
"""DNS अनुरोधों के परिणामों को कैश करें"""
try:
return socket.gethostbyname(hostname)
except socket.gaierror:
return None
# उपयोग
hostname = 'example.com'
ip = cached_resolve(hostname)
if ip:
# अनुरोधों में सीधे IP का उपयोग करें
url = f'http://{ip}/path'
headers = {'Host': hostname} # हेडर में मूल होस्ट निर्दिष्ट करें
एक वैकल्पिक दृष्टिकोण — सिस्टम स्तर पर तेज़ सार्वजनिक DNS सर्वरों का उपयोग करें:
- Google DNS: 8.8.8.8, 8.8.4.4
- Cloudflare DNS: 1.1.1.1, 1.0.0.1
- Quad9: 9.9.9.9
Linux में सेटिंग /etc/resolv.conf के माध्यम से की जाती है:
nameserver 1.1.1.1
nameserver 8.8.8.8
options timeout:2 attempts:2
कई डोमेन वाले Python स्क्रिप्ट के लिए DNS कैश को पहले से गर्म करने की सिफारिश की जाती है:
import concurrent.futures
import socket
def warmup_dns_cache(domains):
"""डोमेन की सूची को पहले से रिज़ॉल्व करें"""
def resolve(domain):
try:
socket.gethostbyname(domain)
except:
pass
with concurrent.futures.ThreadPoolExecutor(max_workers=20) as executor:
executor.map(resolve, domains)
# पार्सिंग के लिए डोमेन की सूची
domains = ['site1.com', 'site2.com', 'site3.com']
warmup_dns_cache(domains)
# अब DNS पहले से कैश में है, अनुरोध तेजी से होंगे
प्रदाता की बुनियादी ढांचे की गुणवत्ता
प्रॉक्सी की गति सीधे प्रदाता के उपकरण और संचार चैनलों की गुणवत्ता पर निर्भर करती है। सस्ते प्रॉक्सी अक्सर धीमे नेटवर्क इंटरफेस और पुराने हार्डवेयर के साथ ओवरलोडेड सर्वरों पर काम करते हैं।
बुनियादी ढांचे के महत्वपूर्ण पैरामीटर:
| पैरामीटर | खराब | अच्छा | गति पर प्रभाव |
|---|---|---|---|
| चैनल की बैंडविड्थ | 100 एमबीपीएस | 1+ जीबीपीएस | फाइलों को डाउनलोड करते समय महत्वपूर्ण |
| सर्वर का प्रोसेसर | 2-4 कोर | 8+ कोर | SSL/TLS प्रोसेसिंग पर प्रभाव डालता है |
| RAM | 4-8 जीबी | 16+ जीबी | कैशिंग और बफरिंग |
| Uptime | <95% | 99%+ | कनेक्शनों की स्थिरता |
| रूटिंग | मानक | अनुकूलित BGP | Latency और पैकेट हानि |
अपने बुनियादी ढांचे (न कि पुनर्विक्रेताओं) के साथ प्रदाता आमतौर पर स्थिर रूप से उच्च गति प्रदान करते हैं। वे पूरे स्टैक पर नियंत्रण रखते हैं: हार्डवेयर से लेकर नेटवर्क उपकरणों की सेटिंग्स तक।
गुणवत्ता बुनियादी ढांचे के संकेत:
- दिन के दौरान स्थिर गति (औसत से 15-20% से अधिक भिन्नता नहीं)
- कम जिटर (देरी में भिन्नता) — 10 मिलीसेकंड से कम
- पैकेट हानि न्यूनतम (<0.1%)
- समस्याओं पर तकनीकी सहायता की तेज़ प्रतिक्रिया (व्यापारिक कार्यों के लिए महत्वपूर्ण)
- सर्वरों के स्थान और चैनलों की विशेषताओं के बारे में पारदर्शी जानकारी
महत्वपूर्ण कार्यों के लिए, प्रॉक्सी का परीक्षण उन स्थितियों में करने की सिफारिश की जाती है जो वास्तविक परिस्थितियों के निकटतम हों। 1-3 दिनों के लिए परीक्षण पहुंच खरीदें और सभी मैट्रिक्स की निगरानी के साथ वास्तविक स्क्रिप्ट चलाएं।
प्रॉक्सी गति परीक्षण की विधि
सही परीक्षण संकीर्ण स्थानों की पहचान करने और विभिन्न प्रदाताओं की वस्तुनिष्ठ तुलना करने में मदद करता है। साधारण स्पीडटेस्ट पर्याप्त नहीं है — आपको उन मापदंडों को मापने की आवश्यकता है जो आपके कार्यों के लिए महत्वपूर्ण हैं।
मापने के लिए प्रमुख मैट्रिक्स:
- Latency (देरी) — पैकेट के वहां और वापस आने का समय। छोटे अनुरोधों की बड़ी संख्या वाले कार्यों के लिए महत्वपूर्ण।
- Throughput (प्रवाहित क्षमता) — समय की एक इकाई में डेटा की मात्रा। फ़ाइलों, छवियों को डाउनलोड करने के लिए महत्वपूर्ण।
- Connection time — कनेक्शन स्थापित करने का समय। एकल अनुरोधों के लिए प्रभावशीलता दिखाता है।
- Success rate — सफल अनुरोधों का प्रतिशत। 95% से कम — खराब संकेतक।
- Jitter — देरी में भिन्नता। उच्च जिटर (>50 मिलीसेकंड) चैनल की अस्थिरता को इंगित करता है।
परीक्षण के लिए समग्र स्क्रिप्ट:
import time
import requests
import statistics
from concurrent.futures import ThreadPoolExecutor, as_completed
def test_proxy_performance(proxy, test_url='https://httpbin.org/get', requests_count=50):
"""
प्रॉक्सी का समग्र परीक्षण
Args:
proxy: प्रॉक्सी का URL
test_url: परीक्षण के लिए URL
requests_count: परीक्षण अनुरोधों की संख्या
Returns:
मैट्रिक्स के साथ dict
"""
results = {
'latencies': [],
'connection_times': [],
'total_times': [],
'successes': 0,
'failures': 0,
'errors': []
}
session = requests.Session()
session.proxies = {'http': proxy, 'https': proxy}
def single_request():
try:
start = time.time()
response = session.get(
test_url,
timeout=(5, 15),
headers={'Connection': 'keep-alive'}
)
total_time = time.time() - start
if response.status_code == 200:
results['successes'] += 1
results['total_times'].append(total_time)
# देरी का अनुमानित मूल्यांकन
results['latencies'].append(total_time / 2)
else:
results['failures'] += 1
except Exception as e:
results['failures'] += 1
results['errors'].append(str(e))
# अनुरोधों का समानांतर निष्पादन
with ThreadPoolExecutor(max_workers=10) as executor:
futures = [executor.submit(single_request) for _ in range(requests_count)]
for future in as_completed(futures):
future.result()
# सांख्यिकी की गणना
if results['total_times']:
metrics = {
'proxy': proxy,
'total_requests': requests_count,
'success_rate': (results['successes'] / requests_count) * 100,
'avg_response_time': statistics.mean(results['total_times']),
'median_response_time': statistics.median(results['total_times']),
'min_response_time': min(results['total_times']),
'max_response_time': max(results['total_times']),
'stdev_response_time': statistics.stdev(results['total_times']) if len(results['total_times']) > 1 else 0,
'jitter': statistics.stdev(results['latencies']) if len(results['latencies']) > 1 else 0,
'failures': results['failures']
}
return metrics
else:
return {'proxy': proxy, 'error': 'सभी अनुरोध विफल रहे'}
# परीक्षण
proxy = 'http://user:pass@proxy.example.com:8080'
metrics = test_proxy_performance(proxy, requests_count=100)
print(f"प्रॉक्सी: {metrics['proxy']}")
print(f"सफलता दर: {metrics['success_rate']:.1f}%")
print(f"औसत प्रतिक्रिया समय: {metrics['avg_response_time']*1000:.0f} मिलीसेकंड")
print(f"मेडियन: {metrics['median_response_time']*1000:.0f} मिलीसेकंड")
print(f"जिटर: {metrics['jitter']*1000:.0f} मिलीसेकंड")
print(f"मानक विचलन: {metrics['stdev_response_time']*1000:.0f} मिलीसेकंड")
अधिक सटीक परिणामों के लिए, विभिन्न समय (सुबह, दिन, शाम) और विभिन्न लक्षित साइटों पर परीक्षण करें। गति भूगोल और नेटवर्क पर लोड के आधार पर काफी भिन्न हो सकती है।
सलाह: एक बेसलाइन (baseline) बनाएं — बिना प्रॉक्सी के सीधे कनेक्शन का परीक्षण करें। यह प्रॉक्सी के ओवरहेड का मूल्यांकन करने के लिए एक संदर्भ बिंदु देगा। सामान्य ओवरहेड: गुणवत्ता प्रॉक्सी के लिए 50-150 मिलीसेकंड।
समग्र अनुकूलन: चेकलिस्ट
सभी वर्णित विधियों का समग्र उपयोग संचित प्रभाव देता है। यहाँ प्रॉक्सी के माध्यम से गति के अनुकूलन के लिए चरण-दर-चरण योजना है:
चरण 1: प्रॉक्सी का चयन और सेटिंग
- लक्षित संसाधनों के निकट भौगोलिक रूप से प्रॉक्सी का चयन करें
- वेब पार्सिंग के लिए SOCKS5 के बजाय HTTP प्रोटोकॉल का उपयोग करें
- उच्च लोड वाले कार्यों के लिए प्राइवेट प्रॉक्सी को प्राथमिकता दें
- सुनिश्चित करें कि प्रदाता TLS 1.3 का समर्थन करता है
चरण 2: कोड का अनुकूलन
requests.Session()का उपयोग करें कीप-एलाइव के साथ- कनेक्शन पूलिंग (10-20 कनेक्शन) सेट करें
- अनुकूलित टाइमआउट सेट करें: कनेक्शन के लिए 5-10 सेकंड, पढ़ने के लिए 15-30
- एक्सपोनेंशियल बैकऑफ के साथ पुनः प्रयास लॉजिक लागू करें
- DNS रिज़ॉल्विंग को कैश करें
चरण 3: प्रॉक्सी पूल का प्रबंधन
- रोटेशन के लिए 10-50 प्रॉक्सी का पूल बनाएं
- एक प्रॉक्सी के माध्यम से समवर्ती अनुरोधों की संख्या को सीमित करें (5-10 थ्रेड्स)
- गति की निगरानी करें और धीमे प्रॉक्सी को स्वचालित रूप से बाहर करें
- IP को बनाए रखने की आवश्यकता वाले कार्यों के लिए स्टिकी सत्रों का उपयोग करें
चरण 4: सिस्टम का अनुकूलन
- तेज़ DNS सर्वरों को सेट करें (1.1.1.1, 8.8.8.8)
- OS में खोले गए फ़ाइलों की सीमाओं को बढ़ाएँ (ulimit -n 65535)
- Linux के लिए: कर्नेल के TCP पैरामीटर को अनुकूलित करें
- यदि आप बड़े डेटा वॉल्यूम के साथ काम कर रहे हैं तो कैशिंग के लिए SSD का उपयोग करें
चरण 5: निगरानी और परीक्षण
- नियमित रूप से प्रॉक्सी की गति का परीक्षण करें (कम से कम सप्ताह में एक बार)
- मैट्रिक्स को लॉग करें: प्रतिक्रिया समय, सफलता दर, त्रुटियाँ
- विभिन्न प्रदाताओं की प्रदर्शन की तुलना करें
- गति गिरने पर अलर्ट सेट करें
उत्पादन के लिए अनुकूलित कॉन्फ़िगरेशन का उदाहरण:
import requests
from requests.adapters import HTTPAdapter
from urllib3.util.retry import Retry
from collections import deque
import time
class OptimizedProxyPool:
def __init__(self, proxies_list):
self.proxies = deque(proxies_list)
self.session = self._create_optimized_session()
self.stats = {p: {'requests': 0, 'avg_time': 0} for p in proxies_list}
def _create_optimized_session(self):
"""अनुकूलित सत्र बनाएँ"""
session = requests.Session()
# पुनः प्रयास रणनीति
retry = Retry(
total=3,
backoff_factor=0.3,
status_forcelist=[429, 500, 502, 503, 504],
allowed_methods=["GET", "POST", "PUT"]
)
# कनेक्शन पूल के साथ अडैप्टर
adapter = HTTPAdapter(
max_retries=retry,
pool_connections=20,
pool_maxsize=50,
pool_block=False
)
session.mount("http://", adapter)
session.mount("https://", adapter)
# कीप-एलाइव हेडर
session.headers.update({
'Connection': 'keep-alive',
'Keep-Alive': 'timeout=60, max=100'
})
return session
def get_best_proxy(self):
"""सर्वश्रेष्ठ प्रदर्शन वाले प्रॉक्सी प्राप्त करें"""
# औसत गति के अनुसार क्रमबद्ध करें
sorted_proxies = sorted(
self.stats.items(),
key=lambda x: x[1]['avg_time'] if x[1]['requests'] > 0 else float('inf')
)
return sorted_proxies[0][0] if sorted_proxies else self.proxies[0]
def request(self, url, method='GET', **kwargs):
"""अनुकूल प्रॉक्सी के माध्यम से अनुरोध करें"""
proxy = self.get_best_proxy()
self.session.proxies = {'http': proxy, 'https': proxy}
start = time.time()
try:
response = self.session.request(
method,
url,
timeout=(5, 15), # कनेक्शन, पढ़ना
**kwargs
)
# सांख्यिकी अपडेट करें
elapsed = time.time() - start
stats = self.stats[proxy]
stats['avg_time'] = (
(stats['avg_time'] * stats['requests'] + elapsed) /
(stats['requests'] + 1)
)
stats['requests'] += 1
return response
except Exception as e:
# त्रुटि होने पर प्रॉक्सी को कतार के अंत में स्थानांतरित करें
self.proxies.remove(proxy)
self.proxies.append(proxy)
raise e
# उपयोग
proxies = [
'http://user:pass@proxy1.example.com:8080',
'http://user:pass@proxy2.example.com:8080',
'http://user:pass@proxy3.example.com:8080'
]
pool = OptimizedProxyPool(proxies)
# अनुरोधों का निष्पादन
for url in ['https://example.com', 'https://example.org']:
try:
response = pool.request(url)
print(f"सफल: {url}, स्थिति: {response.status_code}")
except Exception as e:
print(f"त्रुटि: {url}, {e}")
इस चेकलिस्ट का उपयोग करने से प्रॉक्सी के माध्यम से गति को मूल सेटिंग्स की तुलना में 2-3 गुना बढ़ाने में मदद मिलती है। वास्तविक पार्सिंग परियोजनाओं में, यह कार्यों के निष्पादन के समय को घंटों से मिनटों में कम करता है।
निष्कर्ष
धीमी प्रॉक्सी की समस्या एक हल करने योग्य समस्या है, यदि तकनीकी कारणों को समझा जाए और सही अनुकूलन विधियों को लागू किया जाए। गति के मुख्य कारक: भौगोलिक निकटता, प्रोटोकॉल का चयन, प्रदाता की बुनियादी ढांचे की गुणवत्ता और ग्राहक कोड की सही सेटिंग।
अनुकूलन के लिए समग्र दृष्टिकोण लागू करने से गति में महत्वपूर्ण सुधार हो सकता है, जिससे कार्यों का निष्पादन अधिक प्रभावी और कुशल हो जाता है।