אַ Guzzle בקשה קען אויסגיין די צייט בשעתן וואַרטן אויף אַ פֿאַרבינדונג־פּלאַץ
שטעלט די אַקטיווע פֿאַרבינדונג־בודזשעטן פֿון cURL multi אויפֿן געמיינזאַמען handler און פֿונאַנדערקלײַבט זיי פֿון דער קאַפּאַציטעט פֿון דעם ליידיקן קאַש.
אויב אַן אַסינכראָנע בקשה גייט אויס די צייט פֿאַר זי עפֿנט אַ פֿאַרבינדונג, פּרוּווט די אַקטיווע לימיטן פֿון דער טראַנספּאָרטירן אויך די נעץ־צײַטן. libcurl שטעלט איבערפֿירונגען אין ריי ווען די לימיטן זענען פֿאַרנומען, און זייערע צײַט־בודזשעטן גייען ווײַטער בשעתן וואַרטן אין ריי.
פֿאַר Guzzle 7 ס געמיינזאַמען cURL multi handler:
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),
]);ניצט דעם קליענט פֿאַר דער אַסינכראָנער אַרבעט און גיט זײַן געפּלאַנטן פּראָקסי אָפּציע אויף די אָפּעראַציעס. די ווערטן זענען בײַשפּילן. פֿאַר עפנטלעכע בקשות וואָס זענען דערלויבט דורך אַן עפנטלעכן מיטלער, גיט די HTTP פּראָקסי ליסטע קאַנדידאַטן פֿאַר די פּראָקסי URL־ן פֿון די אָפּעראַציעס.
| אָפּציע | בודזשעט |
|---|---|
| MAX_TOTAL_CONNECTIONS | פֿאַרבינדונגען געעפֿנט אין איין צײַט אונטער דעם multi handler |
| MAX_HOST_CONNECTIONS | פֿאַרבינדונגען צו איין האָסט/פּאָרט; פּראָקסי־פֿאַרבינדונגען ווערן געציילט קעגן דעם פּראָקסי־ענדפּונקט |
| MAXCONNECTS | פֿאַרבינדונגען וואָס בלײַבן אין קאַש נאָך דעם באַניץ |
עטלעכע וועבזײַטן וואָס ניצן דעם זעלבן פּראָקסי באַקומען נישט אויטאָמאַטיש באַזונדערע פּראָקסי־פֿאַרבינדונג־קוואָטן. די קאַפּאַציטעט פֿון דעם ליידיקן קאַש עפֿנט נישט קיין פֿאַרבינדונגען פֿאַרויס און מאַכט זיי נישט אויסטײַטבאַר: ווידערבאַניץ הענגט אָפּ פֿון רוטע, ציל, פּראָטאָקאָל און אויטענטיפֿיקאַציע.
האַלט דעם אַרבעט־בודזשעט פֿון דער אַפּליקאַציע און יעדער סאַפּלייער־קוואָטע אין איין מיט די דאָזיקע טראַנספּאָרט־בודזשעטן. זיי ציילן פֿאַרבינדונגען, נישט בקשות פּער סעקונדע. העכערן אַ socket־צײַט קען נישט באַשטימען צי אַ ריי אָדער אַ נעץ־וואַרטן האָט פֿאַרניצט די צײַט.