การค้นหา proxy pool แบบบล็อกอาจทำให้ Scrapy หยุดชะงัก
แยกการเรียก API proxy pool แบบซิงโครนัสออกจากเส้นทาง event loop ของ Scrapy และให้การค้นหา endpoint มีนโยบายความล้มเหลวของตัวเอง
ตัวรวบรวมข้อมูลมีการตั้งค่าคำขอพร้อมกันไว้เพียงพอ แต่ก็ยังหยุดทุกครั้งที่ขอที่อยู่อื่นจาก proxy pool การเพิ่ม proxy มากขึ้นไม่ส่งผลต่อการหยุดนั้น
รูปแบบมิดเดิลแวร์ทั่วไปเรียก requests.get(pool_url) ภายใน process_request() นี่คือการดำเนินการเครือข่ายแบบซิงโครนัสบนเส้นทางที่ควรทำงานร่วมกับเอนจินแบบอะซิงโครนัสของ Scrapy ขณะที่การเรียกกำลังรออยู่ มันอาจกีดขวางงานที่ไม่เกี่ยวข้องบนเธรด event loop เดียวกัน
มีสองคำขอในงานนี้
คำขอหนึ่งได้ endpoint จากบริการ pool อีกคำขอใช้ endpoint นั้นติดต่อปลายทาง วัดและรายงานแยกกัน API ของ pool ที่ช้าอาจทำให้ทุก proxy ที่เลือกดูช้าไปก่อนที่แอปพลิเคชันจะเชื่อมต่อด้วยซ้ำ
ใช้การผสานการค้นหาแบบอะซิงโครนัสที่เวอร์ชัน Scrapy ที่ติดตั้งรองรับ หรือดึงและรีเฟรชชุด endpoint ภายในที่มีขอบเขตจำกัดนอกเส้นทางวิกฤตของแต่ละคำขอ หากต้องย้ายงานที่บล็อกออกไป ให้ผู้ปฏิบัติงานนั้นมีขีดจำกัดและการจัดการหมดเวลาของตัวเอง คิวที่ไม่จำกัดเพียงย้ายความล่าช้าไปที่อื่น
อย่าออกการเรียกค้นหาอีกครั้งโดยอัตโนมัติสำหรับทุกคำขอ แคชอายุสั้นหรือชุดที่เช่าใช้สามารถลดการพึ่งพาบริการ pool ได้ หากอายุการใช้งานเข้ากับนโยบาย endpoint จริงของบริการ
กำหนดความหมายของการค้นหาที่ล้มเหลว
การตอบกลับจาก pool ที่ว่างเปล่าหรือล้มเหลวไม่ควรลบข้อมูลเมตาของ proxy อย่างเงียบ ๆ และอนุญาตคำขอโดยตรง เลือกผลลัพธ์ที่ชัดเจน: รอภายในงบประมาณของงาน ล้มเหลว หรือใช้ endpoint ที่แคชไว้ซึ่งได้รับอนุมัติ
รักษาเส้นทางของ API ของ pool เองให้โล่งด้วย หากเป็นบริการภายใน การส่งชื่อโฮสต์ส่วนตัวของมันผ่าน proxy ที่ช่วยเลือกมันอาจสร้างการพึ่งพาแบบวงกลม
เมื่อการค้นหาทำงานโดยไม่บล็อกงานที่ไม่เกี่ยวข้องแล้ว ให้ตรวจสอบธุรกรรม proxy ปกติ สิ่งเหล่านั้นเป็นการซ่อมแซมแยกต่างหาก และเวลาของมันสมควรมีฟิลด์แยกในบันทึก