یک جست‌وجوی مسدودکننده در استخر پروکسی می‌تواند Scrapy را متوقف کند

خزنده به‌اندازه کافی درخواست هم‌زمان پیکربندی کرده است. با این حال هر وقت از استخر پروکسی نشانی دیگری می‌خواهد متوقف می‌شود. افزودن پروکسی‌های بیشتر آن توقف را تغییر نمی‌دهد.

یک الگوی رایج میان‌افزار، requests.get(pool_url) را داخل process_request() فراخوانی می‌کند. این یک عملیات شبکه همگام در مسیری است که انتظار می‌رود با موتور ناهمگام Scrapy همکاری کند. تا زمانی که فراخوانی منتظر است، می‌تواند کار نامرتبط را روی همان رشته حلقه رویداد متوقف کند.

دو درخواست در کار وجود دارد

یک درخواست یک نقطه پایانی از سرویس استخر می‌گیرد. دیگری از آن نقطه پایانی برای تماس با مقصد استفاده می‌کند. آن‌ها را جداگانه اندازه‌گیری و گزارش کنید. یک API کند استخر می‌تواند هر پروکسی انتخاب‌شده را حتی پیش از آنکه برنامه به آن متصل شود کند نشان دهد.

از یکپارچه‌سازی کشف ناهمگام که نسخه نصب‌شده Scrapy پشتیبانی می‌کند استفاده کنید، یا مجموعه‌ای محدود از نقاط پایانی محلی را بیرون از مسیر بحرانی هر درخواست به‌دست آورید و تازه کنید. اگر کار مسدودکننده باید جابه‌جا شود، به آن مجری محدودیت‌ها و مدیریت مهلت خودش را بدهید؛ صف نامحدود فقط تأخیر را جابه‌جا می‌کند.

برای هر درخواست به‌طور خودکار فراخوانی کشف دیگری صادر نکنید. یک حافظه پنهان کوتاه‌مدت یا یک دسته اجاره‌ای می‌تواند وابستگی به سرویس استخر را کاهش دهد، به شرط آنکه عمر آن با سیاست واقعی نقاط پایانی سرویس سازگار باشد.

تعریف کنید جست‌وجوی ناموفق چه معنایی دارد

پاسخ خالی یا ناموفق استخر نباید بی‌صدا فراداده پروکسی را حذف کند و درخواست مستقیم را مجاز بداند. یک نتیجه صریح انتخاب کنید: انتظار در محدوده بودجه کار، شکست، یا استفاده از یک نقطه پایانی معتبر ذخیره‌شده.

مسیر خود API استخر را هم باز نگه دارید. اگر سرویس داخلی است، فرستادن نام میزبان خصوصی آن از طریق همان پروکسی‌ای که به انتخابش کمک می‌کند می‌تواند وابستگی چرخه‌ای ایجاد کند.

وقتی کشف بدون مسدودکردن کار نامرتبط کار کرد، تراکنش معمولی پروکسی را بررسی کنید. این‌ها تعمیرهای جداگانه‌اند و زمان‌بندی آن‌ها فیلدهای جداگانه در گزارش می‌خواهد.