בקשת Guzzle עלולה לפוג בזמן המתנה לחיבור פנוי

הגדירו את תקציבי החיבורים הפעילים של cURL multi ב-handler המשותף והבדילו אותם מקיבולת המטמון הלא פעיל.

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

עבור ה-cURL multi handler המשותף של Guzzle 7:

use GuzzleHttp\Client;
use GuzzleHttp\HandlerStack;
use GuzzleHttp\Handler\CurlMultiHandler;

$multi = new CurlMultiHandler([
    'options' => [
        CURLMOPT_MAX_TOTAL_CONNECTIONS => 24,
        CURLMOPT_MAX_HOST_CONNECTIONS => 4,
    ],
]);
$client = new Client([
    'handler' => HandlerStack::create($multi),
]);

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

אפשרותתקציב
MAX_TOTAL_CONNECTIONSחיבורים פתוחים בו-זמנית תחת ה-handler המרובה
MAX_HOST_CONNECTIONSחיבורים למארח/פורט אחד; חיבורי proxy נספרים כנגד נקודת הקצה של ה-proxy
MAXCONNECTSחיבורים שנשמרים במטמון לאחר שימוש

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

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

מאמרים קשורים