В чем смысл Async в стиле Guzzle promises?

С помощью Guzzle do promises предоставляет любую реальную полезность? Кажется, вы должны вызвать wait(). Следующий код (из документов), кажется, ничего не делает сам по себе:

$promise = $client->requestAsync('GET', 'http://httpbin.org/get');
$promise->then(
    function (ResponseInterface $res) {
        echo $res->getStatusCode() . "\n";
    },
    function (RequestException $e) {
        echo $e->getMessage() . "\n";
        echo $e->getRequest()->getMethod();
    }
);

Если вы должны позвонить $prom- > wait(), чтобы сделать запрос, какой смысл обещания? Как это действительно отличается от:

$request = new Request('GET', 'http://httpbin.org/get');
$response = $client->send($request); 

if ($response

Лучшее, что я могу сказать, единственное преимущество - это удобный подход для определения успешности запросов и отказов. Даже в разделе doc для создания нескольких запросов есть код ниже, который, как представляется, блокирует и выполняет все запросы... возможно, в то же время. Это все, чего я должен ожидать?

// Wait on all of the requests to complete.
$results = Promise\unwrap($promises);

Ответы

Ответ 1

Я выхожу на конечность здесь, но из того, что я прочитал...

Хотя PHP не может выполнять асинхронную обработку, вы можете открывать несколько потоков и обрабатывать их вход без блокировки. Итак, в вашем примере с одним соединением, да, нет смысла/выгоды.

Но скажем, вы хотели загрузить 5 ресурсов. Использование методов async могло бы позволить этим ресурсам загружаться по существу параллельно, а не только начинать второй, когда загружается 1-й.

И Guzzle предоставляет способы обработки примеров использования, таких как "после того, как все они были загружены правильно..." или "после того, как все они были загружены или не удались...".

Поэтому я думаю, что это должно позволить ускорить обработку при обработке нескольких запросов, которые могут произойти одновременно.

Ответ 2

Async требует немного обратного мышления.

Вот сценарий, который может возникнуть, что может быть полезно: Учитывая API (http://ipsum.org/), вам необходимо получить список данных назад (по id) на ваш маршрут (или script) - Если вы делаете это процедурно, вам нужно будет пропустить каждый запрос и подождать, пока все не вернется.

С Guzzle Promise вы можете "приготовить" ответ, а затем, когда он вернется - вы можете обработать его. Преимущество этого заключается в том, что вместо N запроса x T времени запроса для выполнения вашего script, задержка теперь составляет CEIL (самое медленное время отклика всего полученного ответа), поскольку вы "ждете", чтобы ВСЕ ответы возвращались, но они отправляются в Parallel вместо этого.

Другими словами, вы отправляете запрос в Parallel вместо последовательного, чтобы ждать ответа на возврат или вы можете предварительно выполнить вызов curl сначала, а затем выполнить настройку, чтобы "ok", пока я жду возвращения, позвольте мне подготовить ответ ".

Более поздняя часть потребует некоторой реструктуризации, так как мы привыкли "искать, ждать, а затем с ответом, мы можем работать с ответом"