استدعاء متزامن لبروكسي بول قد يوقف Scrapy

الزاحف لديه عدد كافٍ من الطلبات المتزامنة المهيّأة. ومع ذلك يتوقف كلما طلب من بروكسي بول عنوانًا آخر. وإضافة المزيد من البروكسيات لا تغيّر ذلك التوقف.

ثمة نمط وسيط شائع يستدعي requests.get(pool_url) داخل process_request(). هذه عملية شبكة متزامنة في مسار يُفترض أن يتعاون مع محرك Scrapy غير المتزامن. وبينما ينتظر الاستدعاء، قد يعطّل عملًا غير مرتبط على الخيط نفسه لحلقة الأحداث.

هناك طلبان في المهمة

أحد الطلبين يحصل على نقطة نهاية من خدمة البروكسي بول. والآخر يستخدم تلك النقطة للاتصال بالوجهة. قِس وأبلغ عنهما منفصلين. فبطء واجهة البروكسي بول قد يجعل كل بروكسي مختار يبدو بطيئًا قبل أن يتصل التطبيق به أصلًا.

استخدم تكامل اكتشاف غير متزامن تدعمه نسخة Scrapy المثبتة، أو احصل على مجموعة نقاط نهاية محلية محدودة وحدّثها خارج المسار الحرج لكل طلب. وإذا لزم إنزال العمل الحاجب، فأعطِ ذلك المنفّذ حدوده ومعالجة المهلة الخاصة به؛ فالطابور غير المحدود ينقل التأخير فقط.

لا تُصدر استدعاء اكتشاف آخر تلقائيًا لكل طلب. فذاكرة مؤقتة قصيرة العمر أو دفعة مستأجرة يمكن أن تقلّل الاعتماد على خدمة البروكسي بول، بشرط أن تتوافق مدة صلاحيتها مع سياسة نقاط النهاية الفعلية للخدمة.

حدّد معنى فشل البحث

لا ينبغي لاستجابة فارغة أو فاشلة من البروكسي بول أن تحذف بيانات البروكسي الوصفية بصمت وتسمح بطلب مباشر. اختر نتيجة صريحة: الانتظار ضمن ميزانية المهمة، أو الفشل، أو استخدام نقطة نهاية مخزّنة معتمدة.

أبقِ مسار واجهة البروكسي بول نفسه واضحًا أيضًا. فإن كانت خدمة داخلية، فإن تمرير اسم مضيفها الخاص عبر البروكسي الذي تساعد في اختياره قد ينشئ اعتمادًا دائريًا.

وبعد أن يعمل الاكتشاف دون حجب عمل غير مرتبط، افحص معاملة البروكسي العادية. فهذه إصلاحات منفصلة، وتوقيتها يستحق حقولًا منفصلة في السجل.