חיפוש חוסם במאגר ה-proxies יכול לתקוע את Scrapy

לזחלן יש מספיק בקשות מקבילות מוגדרות. ובכל זאת הוא נעצר בכל פעם שהוא מבקש מהמאגר כתובת נוספת. הוספת proxies נוספים אינה נוגעת בעצירה הזו.

תבנית middleware נפוצה קוראת ל-requests.get(pool_url) בתוך process_request(). מדובר בפעולת רשת סינכרונית במסלול שאמור לשתף פעולה עם המנוע האסינכרוני של Scrapy. בזמן שהקריאה ממתינה, היא עלולה לעכב עבודה לא קשורה באותו תהליך של לולאת האירועים.

יש שתי בקשות במשימה

בקשה אחת משיגה נקודת קצה משירות המאגר. האחרת משתמשת בנקודת הקצה הזו כדי לפנות ליעד. מדדו ודווחו עליהן בנפרד. API איטי של המאגר יכול לגרום לכל proxy נבחר להיראות איטי עוד לפני שהאפליקציה התחברה אליו.

השתמשו באינטגרציית גילוי אסינכרונית שהגרסה המותקנת של Scrapy תומכת בה, או השיגו ורעננו קבוצה מקומית מוגבלת של נקודות קצה מחוץ למסלול הקריטי של כל בקשה. אם יש להעביר עבודה חוסמת, תנו לאותו מבצע מגבלות משלו וטיפול בפסקי זמן; תור בלתי מוגבל רק מעביר את העיכוב ממקום.

אל תפיקו אוטומטית קריאת גילוי נוספת לכל בקשה. מטמון קצר-מועד או אצווה חכורה יכולים לצמצם את התלות בשירות המאגר, בתנאי שתוחלת החיים שלהם מתאימה למדיניות נקודות הקצה האמיתית של השירות.

הגדירו מה משמעותו של חיפוש כושל

תגובה ריקה או כושלת של המאגר לא אמורה להסיר בשקט את מטא-נתוני ה-proxy ולאפשר בקשה ישירה. בחרו תוצאה מפורשת: להמתין בתוך תקציב המשימה, להיכשל, או להשתמש בנקודת קצה מאושרת מהמטמון.

שמרו גם על המסלול של ה-API של המאגר עצמו פנוי. אם זהו שירות פנימי, שליחת שם המארח הפרטי שלו דרך אותו proxy שהוא עוזר לבחור עלולה ליצור תלות מעגלית.

לאחר שהגילוי יעבוד בלי לחסום עבודה לא קשורה, בדקו את עסקת ה-proxy הרגילה. אלה תיקונים נפרדים, והתזמון שלהם ראוי לשדות נפרדים ביומן.