بلاک کرنے والی پراکسی پول تلاش Scrapy کو روک سکتی ہے

کرالر میں کافی ہم وقت درخواستیں ترتیب دی گئی ہیں۔ پھر بھی وہ ہر بار رک جاتا ہے جب پراکسی پول سے کوئی اور پتہ مانگتا ہے۔ مزید پراکسی شامل کرنا اس رکاوٹ کو نہیں چھوتا۔

ایک عام مڈل ویئر نمونہ requests.get(pool_url) کو process_request() کے اندر کال کرتا ہے۔ یہ ایسے راستے پر ہم وقت نیٹ ورک آپریشن ہے جسے Scrapy کے غیر ہم وقت انجن کے ساتھ تعاون کرنا چاہیے۔ جب کال انتظار کر رہی ہوتی ہے، یہ اسی ایونٹ لوپ تھریڈ پر غیر متعلقہ کام روک سکتی ہے۔

کام میں دو درخواستیں ہیں

ایک درخواست پول سروس سے اینڈ پوائنٹ حاصل کرتی ہے۔ دوسری اس اینڈ پوائنٹ کو منزل سے رابطے کے لیے استعمال کرتی ہے۔ دونوں کو الگ الگ ناپیں اور رپورٹ کریں۔ سست پول API ہر منتخب پراکسی کو اس سے جڑنے سے پہلے ہی سست دکھا سکتی ہے۔

نصب شدہ Scrapy ورژن کی معاونت کردہ غیر ہم وقت دریافت یکجہتی استعمال کریں، یا ہر درخواست کے نازک راستے سے باہر محدود مقامی اینڈ پوائنٹ سیٹ حاصل کر کے تازہ کریں۔ اگر بلاک کرنے والا کام ہٹانا پڑے تو اس ایگزیکیوٹر کو اپنی حدیں اور ٹائم آؤٹ ہینڈلنگ دیں؛ لامحدود قطار صرف تاخیر کی جگہ بدلتی ہے۔

ہر درخواست کے لیے خودکار طور پر ایک اور دریافت کال جاری نہ کریں۔ مختصر مدت کا کیش یا کرائے پر لیا گیا بیچ پول سروس پر انحصار کم کر سکتا ہے، بشرطیکہ اس کی زندگی سروس کی اصل اینڈ پوائنٹ پالیسی سے ہم آہنگ ہو۔

ناکام تلاش کا مطلب متعین کریں

خالی یا ناکام پول جواب کو خاموشی سے پراکسی میٹاڈیٹا ہٹا کر براہ راست درخواست کی اجازت نہیں دینی چاہیے۔ واضح نتیجہ منتخب کریں: کام کے بجٹ کے اندر انتظار، ناکامی، یا منظور شدہ کیش شدہ اینڈ پوائنٹ کا استعمال۔

پول API کا اپنا راستہ بھی کھلا رکھیں۔ اگر یہ اندرونی سروس ہے تو اس کا نجی ہوسٹ نام اسی پراکسی کے ذریعے بھیجنا جو اسے منتخب کرنے میں مدد دیتی ہے، چکری انحصار پیدا کر سکتا ہے۔

جب دریافت غیر متعلقہ کام کو روکے بغیر کام کرے، تو عام پراکسی لین دین کا جائزہ لیں۔ وہ الگ مرمتیں ہیں، اور ان کا وقت لاگ میں الگ فیلڈز کا حقدار ہے۔