בדיקות פרוקסי בפייתון: מדוע Future.cancel() משאיר תהליכונים פועלים
הבינו מדוע ביטול futures ממתינים אינו עוצר בדיקות רשת פעילות, והגבילו מרוץ פרוקסי בלי לטעון שהוא מוכיח את בריאות היעד.
עובד אחד מוצא פרוקסי שמיש. אתה מחזיר את כתובתו, קורא ל-cancel על שאר ה-futures, ומצפה שפעילות הרשת תיפסק. ייתכן שהיא לא תיפסק.
אפשר לבטל Future לפני שה-callable שלו מתחיל. ברגע שתהליכון כבר מבצע בקשה, ביטול ה-Future שלו אינו מפסיק את פעולת ה-socket הזו. העובד זקוק לפעולת רשת תחומה משלו ולמסלול ניקוי.
גם תוחלת החיים של ה-executor חשובה. יציאה מהקשר של ThreadPoolExecutor ממתינה לסיום העבודה שלו. מציאת תוצאה מהירה אחת ואז המתנה לכמה עובדים איטיים יכולה לגרום לעיכוב הכולל של הקורא להיראות שונה לחלוטין מהשהיה המדווחת של המנצח.
תחמו את המרוץ לפני שהוא מתחיל
- הגבילו את מספר הבדיקות בו-זמנית במקום להגיש רשימה ציבורית בלתי מוגבלת. רשימת הפרוקסי החינמית מספקת מועמדים לקלט הבודק, כאשר הפרוטוקול של כל נקודת קצה נשמר לעובד.
- תנו לכל בקשה מדיניות חיבור וקריאה מתאימה.
- תנו לקורא תקציב החלטה כולל.
- הגדירו מי מרוקן או סוגר תוצאות מעובדים ששורדים את ההחלטה.
המתנה קצרה יותר ל-Future אינה זהה לקיצור הבקשה הבסיסית שלו. באופן דומה, נטישת התוצאה אינה משחררת מיד כל משאב רשת.
התוצאה המוצלחת הראשונה היא גם רק הבדיקה המוצלחת הראשונה. היא עשויה להיות תלויה בתזמון, בחיבורים שמורים במטמון וביעד הבדיקה המסוים. היא אינה קובעת שנקודת הקצה היא המהירה ביותר באופן גלובלי או שהמשימה האמיתית תצליח.
לעיתים קרובות מאגר קטן שנשמר עם תצפיות אחרונות פשוט יותר מאשר מרוץ מול כל הרשימה לפני כל הורדה. השתמשו בתוצאה של הפעולה האמיתית כדי לעדכן את הרשומה, עם מדיניות התאוששות מבוקרת לכשלים. הבדיקה המוקדמת צריכה להצדיק את עלותה במקום להכפיל כל משימה מתוך הרגל.