בדיקת רשימת פרוקסי עם מקביליות מוגבלת
הגבילו בדיקות פרוקסי מקבילות ותעדו מה כל בדיקה באמת ביססה עבור אתר היעד.
var options = new ParallelOptions
{
MaxDegreeOfParallelism = 8,
CancellationToken = cancellationToken
};
await Parallel.ForEachAsync(endpoints, options,
async (endpoint, token) =>
{
var result = await ProbeAsync(endpoint, target, token);
observations.Add(result);
});השתמשו במאגר עובדים מוגבל במקום להשיק משימה נפרדת לכל נקודת קצה. בבדיקות מול יעדים ציבוריים מורשים, רשימת הפרוקסי החינמית מספקת שורות מועמדות; שמרו על הפרוטוקול של כל רשומה בעת בניית הבדיקה. קטע התזמון הזה של .NET מניח ProbeAsync שמודע לפרוקסי ואוסף observations בטוח לתהליכונים. שמונה הוא גבול להמחשה, לא ערך אופטימלי שנמדד. הבדיקה עדיין זקוקה למגבלות לכל ניסיון ולבטול של כל העבודה.
שמרו כל תוצאה שהושלמה יחד עם הקלט שלה גם כשסדר ההשלמה שונה. תעדו פרוטוקול, נקודת קצה, יעד, שיטה, זמן שחלף ותוצאה. כשל בחיבור, דחיית התחברות לפרוקסי, CONNECT שנדחה ותגובה שהתקבלה מהאתר הם תצפיות שונות.
פתיחת פורט TCP אינה מוכיחה משא ומתן עם פרוקסי. גם שליפת כתובת הפרוקסי כאתר שונה משימוש בה כדי לבקש את היעד.
בחרו את היעד והשיטה לפי היכולת הנדרשת. HEAD יכול לחסוך בתעבורת גוף אך אינו מוכיח ש-GET מחזיר תוכן שימושי; אתר יכול לדחות אחד ולאפשר את האחר. HTTPS מוסיף CONNECT ו-TLS של היעד שאינם קיימים ב-HTTP רגיל. כתובת יציאה היא תצפית נוספת מצד היעד, נפרדת מהכניסה שהוגדרה.
עבודה מוגבלת מונעת מהבודק למצות את הסוקטים, הזיכרון או המתזמן שלו לפני שיוכל להעריך את המסלול. תוצאה מדורגת נשארת שימושית למדיניות הבחירה בלי להעמיד פנים שיעד מוצלח אחד הופך נקודת קצה לטובה בכל המקרים.