Guzzle Pool: העברת ה-proxy של כל משימה אל requestAsync

שימו את ה-proxy של כל משימת Guzzle על הפעולה האסינכרונית שהמאגר (pool) מתחיל. בתוך הגדרת לקוח קיימת, השתמשו במפעלי הבטחות:

$operations = function () use ($client, $jobs) {
    foreach ($jobs as $id => $job) {
        yield $id => function () use ($client, $job) {
            return $client->requestAsync('GET', $job['url'], [
                'proxy' => $job['proxy'],
                'timeout' => 20,
            ]);
        };
    }
};

$pool = new GuzzleHttp\Pool($client, $operations(), [
    'concurrency' => 4,
]);
$pool->promise()->wait();

כל משימה מאומתת מספקת יעד ו-proxy. עבור בקשה ציבורית מותרת, מועמד HTTP מרשימת ה-proxy של HTTP יכול לספק את כתובת ה-proxy של אותה משימה בלי אישורים; הבחירה מתרחשת לפני שהמפעל שלה רץ. בקשת PSR-7 מתארת את הודעת ה-HTTP, ואילו אפשרויות השליחה האלה שולטות בהובלה. הדפסה או אחסון של ערך proxy לצד ההודעה אינם יכולים להגדיר פעולה ששולחת אותו בדרך אחרת.

החזירו requestAsync() מהמפעל. קריאה ל-request() סינכרוני שם עלולה לחסום בזמן שהמאגר מנסה להתחיל עבודה במקביל.

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

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

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